Subject: RE: [SIP] From header to ISUP CgPN mapping

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 12 Oct 2000 01:31:09 -0400

> -----Original Message-----
> From: Simon Barber [mailto:[email-masked]]
> Sent: Wednesday, October 11, 2000 8:07 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [SIP] From header to ISUP CgPN mapping
> 
> 
> This scenario is an excellent example of why we might want to 
> allow multiple From:
> headers, just as RFC822 allows for e-mail. A user could 
> include both his sip address,
> and a tel: url as from headers.

I don't see why thats needed. In my previous posting on this thread I have
explained why this is not a requirement for gateways at all. Even email
doesn't have such a concept.

> equally why are multiple To: lines not allowed - so users can 
> see that several people
> were invited to a particular call? 

So we are talking about multiparty conferencing... thats a different issue.
For centralized conferences using a bridge, you'll know through RTCP. For
fully distributed, you'll know since you have a point to point signaling
relationship with each.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Simon Barber" <[email-masked]>
Date: Wed, 11 Oct 2000 23:36:52 -0700

Jonathan:
> Simon:

Email does have this conecpt - go check RFC822. Even Microsoft Outlook Express
supports it (although Outlook doesn't). It's useful for indicating a message was
co-authored by 2 people, or that replies should go back to 2 people (example from
RFC822). Since many people will have 2 contact addresses (E164 + SIP) it would be a
very good way to convey both of these with messages.

> fully distributed, you'll know since you have a point to point signaling

You only know through RTCP once the connection is established - the key to headers is
that you can see them before you accept the call (just like e-mail programs show
headers before you read a message). I might choose not to accept a call from my boss,
if I see he invited a whole bunch of other people as well.

Equally if I don't take the call only the headers can be logged by my UA - I want to
know that the call I missed from my boss was a conference call including a whole
bunch of people. I also want to be able to call them all back by clicking "reply to
all" on my logfile entry.

Since this information only affects the display of call requests and reply
functionality I don't see the difficulty in implementing this. What problems can you
see? (I havn't though about the implications for comparing requests to see if they
are the same).

Simon Barber

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 12 Oct 2000 10:30:48 -0400

Since To and From are used to match call legs, they can't be replicated.
(Besides minor problems like breaking every single existing SIP
implementation...) Unlike for email, which can easily be copied, SIP
call legs need a single destination. SMTP, after all, also does two
transactions if you put in two different To fields.

> see? (I havn't though about the implications for comparing requests to see if they

That's one of the complications.

SIP is not email, so doing a plain carry-over of headers is not likely
to work well.

Adding informational headers that carry no protocol implications is
relatively harmless. For example, "Reply-To" might be a way to indicate
addresses for possible return calls.

---

From: "Simon Barber" <[email-masked]>
Date: Thu, 12 Oct 2000 12:09:48 -0700

> addresses for possible return calls.

The Also-To: header would be purely informational - it would indicate to the UAS what
other UASs had been invited. The meaning of Reply-To: is different from From: - and
this difference could be just as useful for IMs and voice calls as it is for e-mail.
IMs in particular, due to their close similarity to e-mail, should retain the same
features users are used to with e-mail. My question is why should users lose this
functionality for either IMs or voice calls?

Simon Barber