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

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:00:36 +0900

Henning:
> 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.
>
>
>
> > 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).
>
> 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.

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
This Email contained an attachment file named Navidad.exe.
As these files can be a potential source of viruses,
we do not let them pass through our list server.
For any questions please send mail to [email-masked]

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:11 +0900

Hi,

This is something I've also been looking into. 

One way would be to add a new header (e.g. Also-From). That header could
be inserted by a proxy that does know the request may end up in a
gateway. The UA may not know that, so he could put whatever string in
the user part of the From header (e.g. his e-mail address). If the proxy
then knows the UAs telephone number, for example by using some kind of
database lookup, which is needed by the gateway - for any possible
A-number procedure - the proxy can add that to the request.

Another way would be to just define a URI parameter for the From header,
but the bad thing about that is that it can not be inserted by a proxy
if it was not in the request from the UA (since the From header must not
be changed) by a proxy, or any other intermediate node.

Note, that this response is according to Clive's mail. I do NOT support
the idea of ALSO-TO headers, multiple FROM/TO headers and whatever was
proposed in the previous mails :)

Regards,

Christer Holmberg
Ericsson Finland

[email-masked] wrote:
> 
> I agree with what you say, however, if you consider a call originating from
> a SIP device (telephone or softphone) that ends up going through a gateway
> to the PSTN then it is a different story.
> Neither the user or the UAC can know where a call will end up, therefore the
> ability to be able to provide both SIP address and SIP Telephone number
> would be useful to providing a complete service as then an appropriate
> calling address is available wherever the call ends up. In the scenario I
> described the gateway could chose the Telephone number (ok I know there are
> verification issues but that's another story).
> Something like Simon's idea of an "ALSO-FROM" seems a good idea to me (this
> is similar to "two number delivery" in the ISDN CLIP service) older versions
> would just ignore the ALSO-FROM and it wouldn't affect the significance of
> the FROM and TO headers.
> 
> Clive
> 
> > -----Original Message-----
> > From: Jonathan Rosenberg [SMTP:[email-masked]]
> > Sent: Wednesday, October 11, 2000 7:41 PM
> > To:   [email-masked]'; [email-masked]'
> > Subject:      RE: [SIP] From header to ISUP CgPN mapping
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, October 11, 2000 12:17 PM
> > > To: [email-masked]
> > > Subject: [SIP] From header to ISUP CgPN mapping
> > >
> > >
> > > In the call flows document draft-ietf-sip-call-flows-01.txt,
> > > scenario 4.1.1,
> > > the message detail and text show User A using a SIP telephone
> > > number rather
> > > than a SIP address in the From header. The text at the
> > > beginning of section
> > > 4 also says "that User A still uses his/her SIP URL in the
> > > Contact header,
> > > since the call could be redirected back to the SIP network."
> > > This implies that User A has pre-knowledge that the call is
> > > going to route
> > > to the PSTN and has the ability to chose the address to be
> > > used in the From
> > > header.
> >
> > No.
> >
> > The From header is the logical identity of the user making the call. Since
> > the call is coming through a gateway, that user is some user on a PSTN
> > terminal somewhere. The identity in this case can either be a tel URL, or
> > a
> > SIP URL at the domain of the originating network.
> >
> > The Contact is used for signaling addressing. Its not a logical
> > identifier.
> > It answers the question "where should I send SIP messages to for the rest
> > of
> > this call". The SIP spec says this is supposed to be a SIP URL preferably
> > with a complete hostname, so that there are no ambiguities about where to
> > send requests.
> >
> > Neither of these have anything to do with knowing where the call is going.
> >
> > -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: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:23 +0900

Hi,

Using the Diversion header, you can inform an endpoint of which
Request-URIs have been used before the Request-URI of that specific
endpoint was used.

The case I am talking about, however, is when we can insert an "alias"
header for the From header, using a telephone number, if the From header
is, for example, an e-mail address. Using this new header, let us call
is Also-From, a proxy (or the calling endpoint itself) may also insert a
telephone number, which can then be used by PSTN Gateways for any kind
of A-number analysing. One could argue that the caller should always
include a telephone number in the From header, but the caller may not
know that the call will end up on the PSTN side, so...

I DO like the Diversion draft very much, though, but it doesn't solve
this specific problem :)

Regards,

Christer Holmberg
Ericsson Finland

Bryan Byerly wrote:
> 
> Hi guys,
> 
> What do you guys think about using the Diversion header
> (http://www.ietf.org/internet-drafts/draft-levy-sip-diversion-00.txt) instead of
> Also-From?
> It seems like a natural replacement to me.
> 
> Thanks!
> Bryan
> 
> Christer Holmberg wrote:
> 
> > Hi,
> >

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:38 +0900

Hi,

>>>A follow-up question:
>>>How does/does Also-From header differ from the Remote-Party-Id header
>>>(draft-dcsgroup-sip-privacy-02.txt)?
>>
>>Well, it could perhaps be possible to use that header, but the whole
>>concept of that draft is a little different than just adding an
>>telephone number alias to the caller, and by supporting it I guess you
>>would have to do more implementation than necessary for this specfic
>>need. Also, depending on what is put in Remote-Party-Id header, it is
>>not even sure it would solve the problem.
>
>I agree. Remote-Party-ID is supposed to be an address that the network >has "verified" to be the actual address of the originator. It is even >stripped if verification cannot take place. THis seems a bit at odds with >the desired function here.
> 
>That said, I still do not understand this need for YAI (yet another
>identifier). This previous motivation involving the termination in the >PSTN or IP network is totally bogus. At this point, I am very, very, very
>reluctant to add new stuff without serious justification.

I agree, that this is simply an alias for the From header value, it is
maybe not such a good, and efficient, way to add a new header. Another
way would be to simply add a "telephone-number" URI parameter. In that
case, however, the UAC must insert it (since intermediate nodes are not
allowed to change to From header).

Another way would be for the UAS (the PSTN GW in this case) to send a
response, asking for the telephone number. A new INVITE, with the
telephone number in the From (in some cases the URI could even be
changed from a SIP-URL to a TEL-URL) header. And, if the
"telephone-number" URI parameter is used, the From URI would not have to
be changed in the new INVITE - the parameter would simply be added to
the old SIP-URL.

Regards,

Christer Holmberg
Ericsson Finland

---

From: 서문희 <[email-masked]>
Date: Tue, 14 Nov 2000 18:01:24 +0900

Hi,

>ok.  Thanks for clearing that up.
> 
>A follow-up question:

Regards,

Christer Holmberg
Ericsson Finland

> Thanks for your help!