[SIPForum-techwg] Urgent questions on SIPconnect 1.1 registrationmode

[Brian Lindsay]

Hi John,

   I was a bit concerned about overloading as well when read through
this week. I think your Option 1 below makes sence. Section 17.1.2
already suggests that the registration AoR "may be an AoR strictly for
the purpose of performing this mechanism, and not used for actual
service".

   Perhaps section 17.1 could state that there is a Registation AoR,
configured in the SP-SSE and SIP-PBX, and the subsequent text in 17.1.x
that uses the Main Public Identity, for registration purposes, could be
changed to use Registation AoR. 

  Thanks
      Brian

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

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