Subject: RE: [Sipping] URIs for Gateways

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Jan 2003 16:02:01 -0500

Yes, it's a SIP based enterprise communication system with
a gateway to a PSTN or PBX.

I'm not really happy with the display name trick, but there are
lots and lots of gateways that do this.  It works because, as we
know, To: and From: are never modified.  It's up to normal
SIP routing to get the INVITE to the right gateway.  When it gets there,
the display name on the To: should be intact.  

However, overloading the display name with the number to dial is
not a great idea, even if a lot of stuff in the field does it.

In a prior message, I did agree that P-Asserted-Identity with
a tel URI could be used for a proxy asserting the translation, 
but not the "real" NAI stuff (Jon's signed headers).  Do you
want a BCP to say that P-Asserted-Identity is what translators
use to get the phone number in the message?  The "P-" is a
problem.  P-Asserted-Identity should go away once the
signed header idea is fully baked, but this problem stays for
a very long time.

I guess I think putting a gateway in the category of a service
component and designing a new framework for service invocation
on it is a bit heavy handed given the problem, but I agree that a
brand new thing can be made to solve any problem.

Brian

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Thursday, January 02, 2003 3:40 PM
> To: Rosen, Brian
> Cc: [email-masked]'
> Subject: Re: [Sipping] URIs for Gateways
> 
> 
> 
> 
> Rosen, Brian wrote:
> > On an enterprise type gateway, it's a problem to construct 
> headers to
> > get the correct thing to happen, especially with CallerId 
> and multiple
> > "lines".
> 
> Let me just make sure I have your network diagram right. You 
> are worried 
> about a SIP-based enterprise that has a gateway for communicating to 
> outside PSTN users, right?
> 
> > To place a call on the gateway, some gateways use the user 
> part of a URI
> > as a phone number.  So:
> > INVITE [email-masked]
> > From: [email-masked]
> > To: [email-masked]
> > 
> > Not all gateways work like this.  Some use the display name 
> for the number,
> > and the username as the port:
> > INVITE [email-masked]
> > From: [email-masked]
> > To: "4125551212" <[email-masked]>
> 
> This is a big no-no, since the To field cannot be used as an 
> identifier 
> for the desired target. It only specifies the original 
> intended target. 
> Had their been proxying inbetween, the wrong number would be dialed.
> 
> > 
> > Now, we add the complication of CallerId. 
> > For gateways that maintain mappings, some gateways send 
> called party number
> > for terminating calls in the display name of the From:
> > INVITE [email-masked]
> >>From "4125551212" <[email-masked]
> > To: "7247426826" <[email-masked]>
> > 
> > I have not seen a gateway that actually accepts a calling party
> > number in the display name of a From on an originating call, but
> > it might be useful if more than one number mapped to the same
> > user. 
> > 
> > Many of the PRI/CAS gateways don't have full tables for the 
> hundreds of
> > numbers per trunk that they can handle.  For these 
> gateways, you tell
> > them what number to use for the outgoing CallerId, and they report
> > what called number they got on an incoming call.
> > If there is no mapping table, then you need some intermediary
> > to translate the called party to a sip URI.  So, the 
> gateway might send
> > INVITE [email-masked]
> > From: "4125551212" <[email-masked]>
> > To: "7247426826" <[email-masked]> 
> > 
> > The translator would have to redirect the call to the correct party
> > INVITE [email-masked]
> > From: "4125551212" <[email-masked]>
> > To: "7247426826" <[email-masked]> 
> > 
> > Similarly, the outgoing call would start as:
> > INVITE [email-masked]
> > From: [email-masked]
> > To: "[email-masked]"
> > 
> > and the translator would send
> > INVITE [email-masked]
> > From: "7247426826" <[email-masked]>
> > To: "[email-masked]"
> > 
> > This is a no-no if the translator is a proxy.  It would have to be
> > a B2BUA. 
> 
> I don't understand why this is not just network asserted ID.
> 
> > So, one question is whether we should indeed force the
> > UAS to know its phone number, so it can construct the From:
> > correctly.  If a UA has multiple "lines", then it actually needs
> > a way to tell the gateway which "line" it wants to use for an
> > outgoing call.  Most systems don't do this, so it's a big deal
> > to make this assumption.
> 
> There is another issue you have been touching on. It relates 
> back to the 
> app components ID that I wrote some time ago 
> (http://www.jdrosen.net/papers/draft-rosenberg-sip-app-compone
> nts-01.txt). 
> Really, a gateway is an application-independent component, 
> just like a 
> conference server or a voicexml server. All of them have the same 
> general problem of how you invoke services on them. For a 
> vxml server, 
> its how to pass the vxml script. For a conference serevr, its how to 
> identify the conference to join. For a gateway, its how to 
> identify the 
> user to call, along with other invocation parameters, such as 
> what port 
> to join.
> 
> What I think you are talking about is that a gateway has several 
> parameters needed for "service invocation" on it, and these need to 
> somehow been standardized. I still believe we are in need of 
> a framework 
> for service invocation in sip, presenting a generic way to name 
> services, discover capabilities, pass parameters, register 
> new services, 
> and so on. That work was discussed in sipping but never took off....
> 
> > I would prefer to make the rules such that the username was
> > the port name.  That allows the port name to be registered, 
> and checked.  
> > That implies the numbers go in the display name.  
> 
> As I point out above, you cannot use the To field display name.
> 
> > We might actually
> > want to specify how tel URIs are used instead of sip URIs.
> > I'm not sure I know what the right thing to do is, because some
> > gateways need that port number.
> > 
> > I'd like to get a new header for the calling party number on
> > an outbound call.  That way, the translator can be a proxy and
> > add the header.  I'd recommend that gateways allow the number
> > to be in the From.   
> 
> As I asked above, why is this bit not the network asserted ID?
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.jdrosen.net                      PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 02 Jan 2003 16:33:35 -0500

> the display name on the To: should be intact.  

You miss the point. You may have called sip:alice. That call is then 
proxied to a pstn number "1234567890" sip:port@gateway. The proxy can't 
change the To address to put the phone number in. It can't even solve 
the problem with a redirect, because your UAC will probably just change 
the request id and reissue the invite with the old To value.

> use to get the phone number in the message? 

What you are suggesting seems backward. The P-Asserted-Identity is only 
useful for the calling number, not the called number. Assuming the 
gateway can trust the callerid info it gets from the PSTN, it should be 
inserting a P-Asserted-Identity header with that value for inbound 
calls. And it ought to be using it to generate callerid on outbound 
calls. The kind of translator you describe seems useless for this.

I think the best choice right now for outbound calls is a tel: uri. You 
can pack all sorts of info into it. This can also be represented as a 
sip uri with user=phone. If you want to use a translator, start by 
generating a tel: uri, then route it to the translator, which can turn 
it into a sip uri with user=phone, using the domain name to select the 
actual gateway. It can also fill in extra parameters (defined in the 
tel: uri) in the user part of the sip uri to help the gateway do the 
right thing.

 > The "P-" is a

I don't think the signed header is a replacement for the 
P-Asserted-Identity. Which to use depends on whether you have trusted 
servers in the network that are responsible for some aspects of 
identity. As long as you are interoperating with the PSTN this will 
probably remain as a requirement.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 03 Jan 2003 01:29:24 -0500

inline.

> the display name on the To: should be intact.  

Right, but it will be WRONG if the call has been forwarded before 
reaching the gateway. That is, I call you, Brian, and you forward the 
call to a PSTN number. The To display name is YOUR number, when the 
number that the gateway needs to use is the forwarded number.

> but not the "real" NAI stuff (Jon's signed headers). 

Why not? They both support assertion of identity; the difference is in 
whether its done through transitive trust or digital signatures.

> brand new thing can be made to solve any problem.

I think that, as a framework, this particular one can be looked at as 
amazingly complicated or quite simple, depending on how you scope it. 
THe main thing it needs to tackle is to simply declare that these are 
really all the same problem, and to give some general guidelines, 
whether its to use the r-uri for passing parameters (as in rfc3087) or 
whether its in a soap body in the INVITE request.

Anyway, it is our job here in sipping to look at the broader issues with 
any problem, is it not? I think that viewing these as the same is at 
least worthy of discussion.

-Jonathan R.