[SIPForum-techwg] Urgent questions on SIPconnect 1.1registration mode
Bernard Aboba
bernard_aboba at hotmail.com
Sun Jul 12 14:24:07 EDT 2009
Using the term "Registration AOR" would be more clear, I think.
EMAILING FOR THE GREATER GOOD
Join me
> Date: Sun, 12 Jul 2009 11:19:10 +0100
> From: john.elwell at siemens-enterprise.com
> To: bernard_aboba at hotmail.com; blindsay at nortel.com; hkaplan at acmepacket.com; techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Urgent questions on SIPconnect 1.1registration mode
>
> So there seems to be agreement in principle on decoupling the
> registration URI from the "default" URI. I think this then leaves us
> with the following questions:
>
> 1) What is an appropriate name for the registration URI? My feeling is
> that this is not a "public identity", and that we should adopt a term
> such as "registration AoR" or "SIP-PBX AoR".
>
> 2) Do we need to distinguish between "main public identity" and
> "alternate public identity"? There does not seem to be a compelling
> need, based on the current content of the spec, to have this
> distinction.
>
> John
>
>
> > -----Original Message-----
> > From: Bernard Aboba [mailto:bernard_aboba at hotmail.com]
> > Sent: 10 July 2009 20:54
> > To: blindsay at nortel.com; hkaplan at acmepacket.com; Elwell,
> > John; techwg at sipforum.org
> > Subject: RE: [SIPForum-techwg] Urgent questions on SIPconnect
> > 1.1registration mode
> >
> > John Elwell said:
> >
> > "have a different AOR (not the Main Public Identity) for
> > registration purposes."
> >
> > I agree that the Main Public Identity is being used for
> > multiple different purposes and that they need to be
> > decoupled. For example, the AOR used for registration
> > purposes need not represent the main public DID of the enterprise.
> >
> > A question: Why isn't the main public DID of the enterprise
> > just another "Alternate public Identity"? Does it really
> > matter whether there is an attendant or receptionist
> > reachable via this particular DID? If not, then the
> > defiinition of 'Alternate Public Identity' can be expanded to
> > include all publicly reachable identities: "individual
> > enterprise users" as well as attendants, receptionists, etc.
> >
> > If we redefine 'Alternate Public Identity' that way, then we
> > can narrow the use of the term 'Main Public Identity' to be
> > solely the AOR utilized in registration. This avoids having
> > to define yet another term. If we define the terms that way,
> > then wouldn't it be valid to say that the SP-SSE is
> > responsible for the 'Main Public Identity' and the SIP-PBX is
> > responsible for the 'Alternate Public Identities'?
> >
> >
> >
> >
> > > Date: Thu, 9 Jul 2009 15:10:00 -0400
> > > From: blindsay at nortel.com
> > > To: HKaplan at acmepacket.com;
> > john.elwell at siemens-enterprise.com; techwg at sipforum.org
> > > Subject: Re: [SIPForum-techwg] Urgent questions on
> > SIPconnect 1.1 registration mode
> > >
> > > Hi,
> > >
> > > Since we're discussing this section:
> > >
> > > Reading the latest text in v14 for the Registration model,
> > in section
> > > 17.1.2, it's not clear how this applies for the case where
> > an SP domain
> > > used for the SIP PBX public id's, as described later in
> > section 17 (e.g
> > > 17.1.4 & 17.1.5.1). (Note this would still be a mode where
> > services are
> > > provided by the SIP PBX). It seems like the text in 17.1.2
> > only covers
> > > the case where there a per-PBX enterprise domain is used?
> > >
> > > Would it not be simpler if we identify that there is an AoR used for
> > > registration, distinct from the "Main Public Identity", and
> > the bound
> > > contact is used for loose routing to all of the implicitly
> > registered
> > > AoRs, regardless of the domain of those AoRs?
> > >
> > > Thanks
> > > Brian
> > >
> > > -----Original Message-----
> > > From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org]
> > > On Behalf Of Hadriel Kaplan
> > > Sent: Thursday, July 09, 2009 1:17 PM
> > > To: Elwell, John; techwg at sipforum.org
> > > Subject: Re: [SIPForum-techwg] Urgent questions on SIPconnect 1.1
> > > registration mode
> > >
> > > Good catch. The wording of "Main Public Identity" and such
> > needs to be
> > > changed.
> > >
> > > Based on the last change for how the Registration model
> > works, the AoR
> > > being registered (the one in the To-URI of the REGISTER), is an AoR
> > > belonging to the SP, within the SP's domain and scope of
> > > authority/responsibility. It is likely to be a private identity, and
> > > not publicly reachable/usable for anything else; however, if it is
> > > usable, any routing by the SP for the AoR would follow 3261
> > and replace
> > > the request-uri with the registered contact.
> > >
> > > -hadriel
> > >
> > > > -----Original Message-----
> > > > From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org]
> > >
> > > > On Behalf Of Elwell, John
> > > > Sent: Thursday, July 09, 2009 6:11 AM
> > > > To: techwg at sipforum.org
> > > > Subject: [SIPForum-techwg] Urgent questions on SIPconnect 1.1
> > > > registration mode
> > > >
> > > > Reading section 17 I now am totally confused about the
> > role of the
> > > > Main Public Identity. I need to have opinions on what we
> > should be
> > > > saying before I can propose text to address my concerns.
> > > >
> > > > 1. The Main Public Identity is used for registration
> > (i.e., in the To
> > > > header field of the REGISTER request). It is unclear
> > whether the SP or
> > >
> > > > the Enterprise is responsible for this AOR in
> > registration mode. For
> > > > static mode, clearly the SIP-PBX has responsibility.
> > > >
> > > > Section 5 seems to suggest SIP-PBX responsibility ("SIP PBX has
> > > > responsibility for the AORs"), although it doesn't
> > explicitly mention
> > > > the Main Public Identity.
> > > >
> > > > Section 10.1 also seems to suggest SIP-PBX responsibility
> > ("Typically,
> > >
> > > > calls sent to the Main Public Identity are terminated by an auto
> > > > attendant or front desk operator on the SIP-PBX and then
> > transferred
> > > > within the enterprise to a private extension."). If the
> > SIP-PBX is not
> > >
> > > > responsible, calls to the auto attendant from within the
> > SIP-PBX would
> > >
> > > > need to be routed via the SP, which is not stated anywhere.
> > > >
> > > > Section 17.1.1 seems to suggest SIP-PBX responsibility
> > ("This document
> > >
> > > > specifies support for only the first of the above models,
> > where the
> > > > SIP-PBX is responsible for providing services to the
> > enterprise Public
> > >
> > > > Identities" - this does not limit it to Alternative
> > Public Identities,
> > >
> > > > so presumably it includes the Main Public Identity).
> > > >
> > > > But in 17.1.2 it states: "Note that the AoR used for the
> > Registration
> > > > is within the authoritative domain of the SP-SSE, and
> > thus if that AoR
> > >
> > > > itself is a publicly reachable AoR, the SP-SSE is responsible for
> > > > providing services for it, rather than the IP-PBX."
> > > >
> > > > Examples in 17.1.5 seem to suggest either can apply,
> > which presumably
> > > > means that it is a matter of agreement between the
> > Enterprise and SP.
> > > > But this is not stated anywhere else.
> > > >
> > > > In the past we have talked about the SP using the Main Public
> > > > Identifier as the default for populating the PAI header field for
> > > > onward transmission within the SP network (although that is not
> > > > written down, since it was considered outside scope).
> > However, a Main
> > > > Public Identifier of the form sip:xyz-corpsp at sp.net (as given in
> > > > Example 1) would not be very suitable for this purpose.
> > Do SP's indeed
> > >
> > > > need to use the Main Public Identifier for default PAI purposes?
> > > >
> > > >
> > > > 2. Related to this, how is an inbound request to the Main Public
> > > > Identifier routed in registration mode. In 17.1.3 it states:
> > > > "When the SP-SSE receives an out-of-dialog request containing a
> > > > Request-URI that identifies either the Main or an
> > Alternate Public
> > > > Identity assigned to the SIP-PBX, it routes the request
> > to the SIP-PBX
> > >
> > > > using the location binding that was established when the SIP-PBX
> > > > registered. The SP-SSE does this following the normal
> > procedures for
> > > > routing requests to registered SIP endpoints, except that
> > it skips the
> > >
> > > > request-retargeting step; i.e. based on locally
> > configured data, the
> > > > SP-SSE does not overwrite the enterprise Public Identity
> > contained in
> > > > the Request-URI with the SIP signaling address of the
> > SIP-PBX. The
> > > > Route header field, as described in Section 17.8, identifies the
> > > > SIP-signaling address of the SIP-PBX in an out-of-dialog request"
> > > >
> > > > In other words, Main Public Identifiers are treated the same as
> > > > Alternate Public Identifiers.
> > > >
> > > > Then in 17.8 it states:
> > > > "When routing any out-of-dialog request to a registered SIP-PBX
> > > > signaling address, the SP-SSE MUST include a Route header
> > containing
> > > > that registered address. A registered SIP-PBX signaling
> > address is the
> > >
> > > > Contact URI (including any associated URI parameters)
> > that was bound
> > > > to the called Main Public Identity when the SIP-PBX
> > registered, as
> > > > described in Section 17.5."
> > > >
> > > > This does not allow for requests to the Main Public
> > Identity to be
> > > > treated any differently.
> > > >
> > > > But in 17.1.2 it seems to contradict this:
> > > > "Note that the AoR used for the Registration is within the
> > > > authoritative domain of the SP-SSE, and thus if that AoR
> > itself is a
> > > > publicly reachable AoR, the SP-SSE is responsible for providing
> > > > services for it, rather than the IP-PBX. In such a case,
> > the AoR is
> > > > resolved and routed to the SIP-PBX using normal [RFC 3261
> > procedures],
> > >
> > > > replacing the request-URI with the Registered Contact-URI
> > instead of
> > > > inserting a Route header, etc."
> > > >
> > > > Opinions?
> > > >
> > > > My opinion on both issues is that we have overloaded Main Public
> > > > Identity to be both the default AoR (e.g., that of
> > auto-attendant) and
> > >
> > > > the AoR with which the PBX registers. For the first use,
> > it seems it
> > > > should be the responsibility of the SIP-PBX, and thus all inbound
> > > > requests to that AoR would be treated the same as inbound
> > requests to
> > > > Alternate Public Identities. For the second use, it makes
> > sense for
> > > > the SP to be responsible. So I think we have 3 possible
> > ways out of
> > > this:
> > > >
> > > > 1. Decouple the two functions, so that we have a
> > different AOR (not
> > > > the Main Public Identity) for registration purposes. In
> > that case, I
> > > > would say that the AoR used for registration purposes is the
> > > > responsibility of the SP.
> > > >
> > > > 2. Be clear that the Main Public Identity is always the
> > responsibility
> > >
> > > > of the SIP-PBX (and eliminate any statements that suggest
> > otherwise).
> > > >
> > > > 3. Be clear that the Main Public Identity is always the
> > responsibility
> > >
> > > > of the SP. However, I don't like this option, because a)
> > it does not
> > > > make sense for static mode and b) it means internal
> > requests within
> > > > the SIP-PBX to the Main Public Identity have to go via the SP.
> > > >
> > > > So I think we have to go with 1 or 2, and I tend to favour 1.
> > > >
> > > > John
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > _______________________________________________
> > > > techwg mailing list
> > > > Send mail to: techwg at sipforum.org
> > > > Unsubscribe or edit options at:
> > > > http://sipforum.org/mailman/listinfo/techwg
> > >
> > > _______________________________________________
> > > techwg mailing list
> > > Send mail to: techwg at sipforum.org
> > > Unsubscribe or edit options at:
> > > http://sipforum.org/mailman/listinfo/techwg
> > >
> > > _______________________________________________
> > > techwg mailing list
> > > Send mail to: techwg at sipforum.org
> > > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> >
> >
> >
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090712/3f4fb314/attachment-0001.html
More information about the techwg
mailing list