[SIPForum-techwg] Question re Application Server

[Paul Kyzivat]

I agree with Chris. The problem with the current spec is that it is 
underspecified. But as such it probably doesn't hurt to leave it that 
way until some more detail can be agreed.

IMO the underspecification is a problem because the components can only 
know what to do based on proprietary knowledge about the behavior of the 
other components. Specifically, a PBX needs to know:
- must I register before I can send/receive calls?
- if so, to what must I register?
- register once, or multiple?
- what is the significance of the contact address registered?

And there are a similar set of questions on the SP side.
I think it is ok for there to be options in this, but then it must be 
clear how these options are resolved. If there are specific degrees of 
freedom that must be provisioned based on info obtained from a service 
agreement, then that ought to be clear.

The trick is to eliminate the underspecification without ending up with 
over specification. Better to leave as much implementation latitude as 
possible, within reason.

	Paul

Chris Sibley wrote:
> Paul Kyzivat wrote: 
> 
>> 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.
>>
> 
> I think Paul's comments above do a nice job of summarizing the key
> points of the registration discussion. 
> 
> I agree with Paul that this is not clear and that we should probably add
> some clarifying text to the spec that states something like:
> 
> 	- The SP performs a "translation service" between
> +E.164 at serviceproviderDomain and +E.164 at enterpriseDomain URIs
> 	- The SP upon receiving a URI of the format
> +E.164 at serviceproviderDomain will:
> 		a. Translate the URI to the associated enterprise URI
> (i.e. route the call to the enterprise)
> 		or
> 		b. Treat the URI as an E.164 address on the PSTN (i.e.
> route the call to the PSTN)
> 
> Now as far as the actual registration goes, as some of you may recall,
> we did start down the path of implicit registrations (i.e. the
> parent/child relationship) but eventually "streamlined" the text to the
> current wording we have now. 
> 
> To be honest, my first preference would be to define an implicit contact
> inheritance scheme for "groups" of enterprise URIs. As a SP this would
> allow me to offer such things as a "mobile PBX" product, provide a "hook
> message" for traversing NATs and firewalls (yeah, with an SBC), as well
> as other things. 
> 
> Of course, one could make a strong argument for specific 1:1
> SP-to-enterprise URI associations (i.e. a single registration updates a
> single SP AOR.) 
> 
> In either case, I think we should leave the "stub" text for
> registrations in the current text while we hash it out. IMO it doesn't
> affect the "functionality" of the spec since we state that no specific
> action should be triggered by the registration..
> 
> Thanks,
> 
> --Chris
> 
> 
> 
> **********************************************************************
> This email may contain confidential information. If you are not
> the intended recipient, please advise by return email and delete
> immediately without reading or forwarding to others.
>  -- Cbeyond 
> **********************************************************************
>