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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 11 Oct 2000 14:40:43 -0400

> -----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: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Oct 2000 03:17:48 -0400

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Tuesday, October 17, 2000 5:00 PM
> Cc: Bryan Byerly; [email-masked]; [email-masked]
> Subject: Re: [SIP] From header to ISUP CgPN mapping
> 
> 
> 
> Hi,
> 
> >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)?
> 
> 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.

-Jonathan R.

---

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 18 Oct 2000 10:44:09 +0300

Hi,

>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.
> 
>identifier). This previous motivation involving the termination in the >PSTN or IP network is totally bogus. At this point, I am very, very, very

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: Thu, 19 Oct 2000 15:06:22 +0100

Thanks Henning,
                        Comments below.
Clive

> From:	Henning Schulzrinne [SMTP:[email-masked]]
> Sent:	Thursday, October 19, 2000 2:06 PM
> To:	[email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> [email-masked] wrote:
> > 
> > Jonathan,
> >                I understand your reluctance to add changes, however,
> IMHO I
> > do not see that it is bogus for a call originating in an IP network to
> be
> > able to provide a calling address appropriate for the terminating
> network.
> > So if the call remains in the IP environment a SIP address is provided
> but
> > if the call terminates in the PSTN an E.164 number is delivered as the
> > calling address.
> >              I would welcome suggestions on how to resolve this issue.
> 
> If this is to be meaningful, it has to be verifiable. Just having users
> stick in random telephone numbers that then pop up on caller ID boxes is
> not likely to be useful.
	[Clive Dellard BTexaCT]  I totally agree.
	 Also, if the outbound gateway is my home provider (as is likely,
due to
> billing relationships), I will have already registered with a local
> registrar, including with a tel: URL. This already provides this
> information, if desired, to the gateway. Thus, it is far from clear that
> a simple header is particularly helpful.
	[Clive Dellard BTexaCT]  OK that sounds reasonable, what mechanisms 
	are available to get this information to the gateways?

> -- 
> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>