Subject: [martini] Numbers and private networks

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Feb 2010 19:39:37 +0100

I just want to assert a couple of things that I have not seen in the ongoing discussions so far.

1)	PBXs already have a custom and practice on assigning URIs to their extensions already. Some of that conforms to what RFCs say, and some of it is questionable. Any solution we come up with to a Martini problem is not going to change the set of URIs that are used within the PBX. So I would point out that for private numbers we can see all of the following:

sip:[email-masked]
sip:[email-masked];user=phone
tel:XXXX;phone-context=subregion.region.enterprise.com
sip:XXXX;phone-context=[email-masked]/user=phone
sip:XXXX;phone-context=[email-masked]/user=phone
sip:XXXX;phone-context=[email-masked]/user=phone

where XXXX are digits. Ignore the subdomains, I pulled these from a document I drafted some time ago. The one you will probably not see is tel:...

The first one is probably one of the most common!

E.164 numbers are just a subset of the above usages. 

For support of private numbers within VPN type scenarios, PBXs are not going to map these numbers, just because the trunking is provided by a SSP. Nor are they going to suddenly define a whole new set of identities in their DNS. 

2)	Business trunking is in some ways a replacement for direct PBX connections or tie lines between those PBXs. Yes there is a certain quantity of traffic destined for, or received from, users outside the private network, but we also need to deal with the case of replacing existing direct connections with support from the SSP. That means that what may originally have been configured as a SIP peering link between two PBXs has to be easily replaced by whatever solution the SSP provides, and therefore with minimal reconfiguration. And remember that historically, different countries have had significant differences in the customs and practice of private networking, based on tariff structures and regulatory restrictions. Therefore consider the deployments in a couple of other countries rather than just your own.

regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Feb 2010 17:51:34 -0500

> sip:[email-masked]

Totally ambiguous. There is no way to distinguish if this is a number or 
a (numeric) name. Perhaps it doesn't matter, as long as it is treated as 
a numeric name. But you will need the "stirred" approach to route this I 
think. That assumes that subregion.region.enterprise.com resolves vis 
3263 to a reachable server.

> sip:[email-masked];user=phone

This is just plain wrong! From the user=phone it is to conform with tel 
format. But it has neither a leading + nor a phone context.

> tel:XXXX;phone-context=subregion.region.enterprise.com

This is syntactically correct. But AFAIK there are no standard rules for 
routing such a thing. You must have configured information about how to 
deal with this phone context. If this gets to an SSP other than one 
servicing enterprise.com, it probably will get no further.

Once it gets to the Martini SSP for the target pbx, do you want the 
phone context to be delivered to the pbx? Will it know what to do with 
it? I'm thinking Adam's wildcard mapping for the user part into the 
contact might barf on this.

> sip:XXXX;phone-context=[email-masked]/user=phone

Pretty much the same as the tel case. But if this URI falls in the hands 
of somebody outside enterprise.com's SSP then presumably 3263 routing 
will deal with it.

> sip:XXXX;phone-context=[email-masked]/user=phone

The new issue presented by this one is that ngn-operator.com had better 
have information about the phone context.

> sip:XXXX;phone-context=[email-masked]/user=phone

This is just like the case two up. The server identified by 
enterprise.com had better know what to do with this phone context.

> 2)	Business trunking is in some ways a replacement for direct PBX connections or tie lines between those PBXs. Yes there is a certain quantity of traffic destined for, or received from, users outsi…

Do you assume that the SSP knows the phone contexts, and the valid 
values for XXXX?

If not, then you are mostly talking about stirred.

	Thanks,
	Paul