[SIPForum-techwg] Question re Application Server

[Chris Sibley]

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