Subject: [Sipping] URIs for Gateways

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Jan 2003 14:50:15 -0500

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

Enterprise gateways almost always have multiple ports/lines connected to
them.  These lines may be connected to the PSTN or they may be connected
to a PBX.  Some gateways are simple analog loops, others are digital
telephone loops, ISDN BRI, CAS or ISDN PRI trunks.  There are two ways
these gateways are deployed:
    Pool - where all the lines are in a big pool, and calls come in to
		the first available line in the pool, and go out on the
           next available line in the pool.  It's pretty close to
		impossible to have correct CallerId with pooled lines
    Mapped - a user is mapped to a particular line/port.
		All calls to that line/port go to that user, all calls from
		that user go to that line/port
When you have a shared trunk like a CAS or PRI, effectively you have
a hybrid.  Each of the "DS0s" are pooled, but the gateway can obtain/insert
phone number information to determine/assert the called/calling party.

Many, but not all, gateways implement mapped; you can provision a URI with
a line/port.  When a call arrives at the line, a SIP call is made to the
specified URI.  When a sip call comes to the gateway, the FROM line
is matched with the provisioned URIs to pick the line/port to place the
call.  For example, I might have a mapping of "[email-masked]"
to port3 on gateway2.marconi.com.  A call from 4125551212 to my phone
number,
7247426826 might result in an INVITE from the gateway like:
INVITE [email-masked]
From: [email-masked]
To: [email-masked]

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

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

Translators are pretty useful.  Many systems have them, because you
don't want UAs to know which gateway they should use.

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

Comments?

Brian

_______________________________________________
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: Henning Schulzrinne <[email-masked]>
Date: Thu, 02 Jan 2003 15:09:51 -0500

> add the header.  I'd recommend that gateways allow the number

Generalized, you want something like the Request-URI that can be 
modified or inserted. How about the NAI stuff?

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 02 Jan 2003 15:40:13 -0500

> get the correct thing to happen, especially with CallerId and multiple

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

> a B2BUA. 

I don't understand why this is not just network asserted ID.

> So, one question is whether we should indeed force the

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

> 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

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