[SIPForum-techwg] Question re Application Server

Hadriel Kaplan HKaplan at acmepacket.com
Mon Sep 11 22:57:58 EDT 2006



> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> 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.

Yes, but I was commenting on your statement that it would be bad if the PBX
registered the SP equivalent of one of the enterprise's phone numbers.  My
only point was if the PBX did this it wouldn't hurt for the AoR it
registered, it just wouldn't do much for all the other AoRs, unless the
registrar was aware of this and updated the other AoR's contact-uri
addresses (but not usernames).  I agreed with your general comment that
registration is underspecified.  The original draft had the concept of
"parent" accounts which would register all the children numbers implicitly,
but my impression is that was deprecated in later versions and
de-emphasized, to what we have now.  


> 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 the current draft tells you the SP will format it that way:
regardless of what was registered, the SP will format the req-URI the same
way, namely to the specific/individual e164 at enterprise.  How it does that
internally is up to it.  All the registration may do is update the hostname
address.

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

Yup.

-hadriel



More information about the techwg mailing list