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

From: [email-masked]
Date: Fri, 13 Oct 2000 10:46:26 +0100

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: Christer Holmberg <[email-masked]>
Date: Mon, 16 Oct 2000 23:49:07 +0300

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

---

From: Bryan Byerly <[email-masked]>
Date: Tue, 17 Oct 2000 13:18:45 -0400

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 17 Oct 2000 23:13:33 +0300

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

---

From: Bryan Byerly <[email-masked]>
Date: Tue, 17 Oct 2000 16:35:25 -0400

ok.  Thanks for clearing that up.

A follow-up question:
How does/does Also-From header differ from the Remote-Party-Id header
(draft-dcsgroup-sip-privacy-02.txt)?
Thanks for your help!
Bryan

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2000 00:00:28 +0300

Hi,

>(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.

Regards,

Christer Holmberg
Ericsson Finland