[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

Hadriel - more inline

Hadriel Kaplan wrote:
> Hey Paul,
> Comments inline...
> 
>> -----Original Message-----
>> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
>>
>> Then there is the address that is the registration target. It must be an
>> address in the domain of the SP. But it would be very bad if it was the
>> SP equivalent of one of the enterprise's phone numbers. (E.g.
>> sip:++12125551234 at service-provider.net;user=phone) It would be bad
>> because once registration is accepted to that it will be *extremely*
>> surprising if a request targeted to that address isn't routed to the
>> registered contact. (It is *legal* but surprising and misleading.) And
>> it would be equally bad if it was a phone number assigned to somebody
>> else. So I guess maybe it shouldn't be a phone number at all. Perhaps it
>> would be best if it were something like sip:acme.com at service-provider.net.
> 
> Not that I disagree with your general point, but why can't acme-pbx register
> the AoR 12125551234 at service-provider.net with a contact of
> 12125551234 at acme.com?  The SP will be getting that registered AoR in
> requests from other Enterprises and its PSTN GW for the number, and can set
> the req-uri to the contact, and it should work.  The To-uri the PBX receives
> won't be what the spec says, but those rules should be relaxed anyway as per
> your other email. (or am I missing your example?)

This is a whole different approach than what currently seems to be intended.

I have no problem with this, if it is specified as in-scope behavior. 
But it doesn't scale very well for PBXx that are responsible for many 
lines. So it isn't a sufficient solution.

The problem comes in mixing solutions. Suppose the PBX is responsible 
for 1000 numbers (+1-978-555-1nnn), and it registers to one of them. 
What happens to calls to the other 999?

I would expect that the SP will consider 
sip:+1-978-555-1nnn at serviceprovider.net to be valid numbers in its 
domain, though I don't believe the spec currently states this. If it 
does, then presumably when it receives a request at an R-URI that 
matches one of those then it will normally translate it to a URI 
belonging to the enterprise. It could simply lookup which enterprise 
owns the number and then replace the domain name with that of the 
enterprise.

But if it were to allow explicit registration to some of the numbers, 
then it must do something different in that case. I guess the rule could 
be: if there is a registration, translate to that, else just replace the 
domain name. But without some agreement to that effect I don't know how 
the PBX would know that to be the case.

>> The mechanism of implicit registration sets introduced by IMS blends
>> more harmoniously with SIP. (Not that I love the mechanism.) With it,
>> you register to one of your AORs, and a bunch of associated ones are
>> *implicitly* registered with the same contact. Requests addressed to any
>> of those AORs are routed using normal registrar/home proxy methods,
>> replacing the R-URI with the registered contact. Because the same
>> contact is shared by many AORs, a new P-Called-Party-ID header is added
>> that contains the untranslated value of the R-URI. I think that might
>> have been a better mechanism to use here, but perhaps it is too late for
>> that.
> 
> Indeed implicit registration is the mechanism some people use today for PBX
> cases that need registration. (not that it's very common for PBX's to
> register, mind you)  The only downside with that is the URIs come back in
> the P-Associated-URI header and it gets mighty big for reasonable-sized
> PBXs.  

Yes, the P-Associated-URI could be a problem in that case. Perhaps it 
could simply be omitted for SIPConnect usage. This of course is all 
hypothetical - its not covered by the current document.

	Paul

> -hadriel
>