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

From: [email-masked]
Date: Thu, 19 Oct 2000 10:27:53 +0100

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.

Regards,

Clive

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Wednesday, October 18, 2000 8:18 AM
> To:	Christer Holmberg; [email-masked]
> Cc:	Bryan Byerly; [email-masked]; [email-masked]
> Subject:	RE: [SIP] From header to ISUP CgPN mapping
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Christer Holmberg [mailto:[email-masked]]
> > Sent: Tuesday, October 17, 2000 5:00 PM
> > To: [email-masked]
> > 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.
> 
> ---
> 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

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 19 Oct 2000 09:06:18 -0400

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

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.

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

---

From: "Adam B. Roach" <[email-masked]>
Date: Tue, 24 Oct 2000 09:43:50 -0500 (CDT)

>registrar, including with a tel: URL. 

I think this is an unnecessarily restrictive assumption, and one
that propigates a narrowminded, old-school way of thinking about
billing.

Consider the relationships between me, AT&T (internet access 
provider), and the Wall Street Journal online (content provider). 

There is an excellent parallel between this situation and, for example, 
SBC ("home provider" i.e. network access provider), and Worldcom
(PSTN gateway provider).

Currently, when I access WSJ online, they ask me for a password to
verify that I am who I claim to be -- then, they provide me the service
that I have agreed to be billed for. There is no relationship between
WSJ and AT&T.

Similarly, this model works flawlessly when applies to my second example,
wherein SBC and Worldcom (for the purposes of this transaction) have
no billing relationship. When I use Worldcom's PSTN gateway, it requests
authentication from me (or, more likely, my terminal device, which should
save me the trouble of typing in a password each time) to verify that
it can bill me for the services I'm requesting.

When trying to solve problems, *please* don't make simplifying
assumptions that break this model.

-- 
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA