[SIPForum-techwg] Proposal for Action Item 8 from SIPconnectface-to-face
Paul Kyzivat
pkyzivat at cisco.com
Fri Oct 24 18:29:05 EDT 2008
Am I confused?
I thought in registration mode, the PBX was registering to an AOR in the
domain of the SP. I posted an example of how I thought it worked back on
17-oct, with subject of " Re: SIPConnect PBX Registration".
The association of that AOR to the domain name for the pbx is then a
matter of configuration at the SP. I've attached a copy for reference.
I think there is no guarantee that the SP is responsible for the domain
the enterprise uses. The registration allows the SP to route to the PBX
without dereferencing the domain name assigned to the pbx. If it happens
that the DNS mapping of the pbx domain name actually maps to an SP
server, then it can route any requests addressed to that domain name to
the pbx. But if that domain name isn't assigned to the SP, then that
won't happen, and only things addressed to the SP's domain will ever get
there.
Am I misunderstanding?
Thanks,
Paul
David Hancock wrote:
> John,
>
> I agree with most of your comments, and will work on updating the text to address them.
>
> I'd like to discuss how best to address your first comment regarding the phrase "responsible for the domain" in the flowing text...
>
> "Registration mode: in this case the Service Provider Network is responsible for the domain of the Public Identity, and therefore queries the location service Public-Identity-to-location mapping established at registration time."
>
> In this case I was using "responsible for domain" as described in RFC3261 section 16.5. My reading of section 16.5 is that if a proxy receives a request with a Request-URI containing a domain that the proxy is responsible for, then the proxy accesses the location service (which in our case is the registration bindings) to determine the target(s) for the request. If the proxy is not responsible for the domain, then it forwards the request using DNS, hopefully toward a proxy that is responsible for the domain.
>
> I agree that in general the enterprise is responsible for its own domain. But for the Registration mode case where the SIP-PBX is assigned SIP URIs containing the domain "enterprise.com", I assume the enterprise configures DNS so that it points to the SP network for SIP. So in a sense the Enterprise has delegated the responsibility for its domain for SIP requests to the SP network, at least from the perspective of peer networks placing calls to the SIP-PBX. Does this line up with your view of how this works? If yes, I could use some help in coming up with the right terminology that clearly describes what's going on.
>
> You also made a comment about the SP network not needing to look at what's left of the "@" sign when doing the location query. I guess this could be true, but couldn't the service provider also configure things so that the user part of the SIP URI has significance?
>
> For example, say I have a SIP-PBX serving 10 users, and the Service Provider and Enterprise agree on the following Public Identities for the SIP-PBX...
> - main Public Identity
> SIP:+13035551100 at enterprise.com
> - alternate Public Identities
> SIP:13035551101 at enterprise.com
> SIP:13035551102 at enterprise.com
> SIP:13035551103 at enterprise.com
> ...
> SIP:13035551109 at enterprise.com
> SIP:13035551110 at enterprise.com
>
> The SIP-PBX registers the main Public Identity with the Service Provider network, which implicitly registers the 10 alternate Public Identities. The location service now has 11 bindings; one per Public Identity that maps that Pubic Identity to the SIP-PBX contact address. Now, if an incoming call arrives at the Service home network addressed to...
>
> SIP:13035551234 at enterprise.com
>
> ... it would not be delivered to the SIP-PBX because it is not bound to the SIP-PBX contact address.
>
> Alternatively, the Service Provider could do as you suggest -- ignore everything left of the "@" sign, and deliver any incoming SIP request addressed to "enterprise.com" to the SIP-PBX. How the SP Network does this is out-of-scope w.r.t. SIPconnect 1.1 (IMO), but one way to do this is to configure the wildcard identity <SIP:*.enterprise.com> in the implicit registration set of the main Public Identity of the SIP-PBX.
>
> Another form of Enterprise Public Identity that isn't explicitly spelled out in SIPconnect 1.1 but that I think is supported is the case where the Enterprise Public Identity contains the domain of the operator (not a sub-domain), like this:
>
> SIP-PBX-1
> - main Public Identity
> SIP:+13035551100 at operator.com
> - alternate Public Identities
> SIP:13035551101 at operator.com
> SIP:13035551102 at operator.com
> SIP:13035551103 at operator.com
> ...
> SIP:13035551109 at operator.com
> SIP:13035551110 at operator.com
>
> SIP-PBX-2
> - main Public Identity
> SIP:+13035552200 at operator.com
> - alternate Public Identities
> SIP:13035551201 at operator.com
> SIP:13035551202 at operator.com
> SIP:13035551203 at operator.com
> ...
> SIP:13035551209 at operator.com
> SIP:13035551210 at operator.com
>
> Plus Public Identities hosted directly by SP network
> SIP:13035552000 at operator.com
> SIP:13035552001 at operator.com
> SIP:13035552002 at operator.com
> ...
> SIP:13035559998 at operator.com
> SIP:13035559999 at operator.com
>
> Do you agree this is a valid option, and should we call it out in SIPconnect 1.1?
>
> Thanks
>
> David
>
>> -----Original Message-----
>> From: Elwell, John [mailto:john.elwell at siemens.com]
>> Sent: Wednesday, October 22, 2008 10:11 AM
>> To: David Hancock; techwg at sipforum.org
>> Subject: RE: [SIPForum-techwg] Proposal for Action Item 8 from
>> SIPconnectface-to-face
>>
>> David,
>>
>> I think this is heading in the right direction, but I have quite a few
>> detailed comments that should be addressed.
>>
>> 1. In section 9: "Registration mode: in this case the Service Provider
>> Network is responsible for the domain of the Public Identity, and
>> therefore queries the location service Public-Identity-to-location mapping
>> established at registration time."
>> I think we need to be more precise about what is meant by "responsible for
>> the domain". In the examples of public identities (or should it be "public
>> identifiers"?) given in the preceding text, sometimes the domain part is
>> enterprise.com, and sometimes it is pbx1.operator.com. In the first case,
>> clearly the enterprise is responsible. Any request to sip:*.enterprise.com
>> does indeed need to query the location service, but in so doing does not
>> need to take account of anything to the left of "@".
>> In the second case, I assume operator.com is the SP. In this case the SP
>> is responsible for operator.com, but has delegated responsibility for
>> pbx1.operator.com to the enterprise. So once again, any request to
>> sip:*.pbx1.operator.com" does need to query the location service, but in
>> so doing does not need to take account of anything to the left of "@".
>>
>> 2. In section 10.1.1: "The Service Provider Network MUST populate the
>> Request-URI of the INVITE with the identity of the actual destination for
>> the call; i.e. either the main Enterprise Public Identity, or one of the
>> alternate Enterprise Public Identities assigned to the SIP-PBX."
>> How does the SP know what alternative enterprise public identities are
>> assigned to the SIP-PBX? In the case of E.164 (with user=phone), of course
>> it knows. But for email-style, it does not know - anything that fits
>> sip:*. at enterprise.com or sip:*@pbx1.operator.com (without ;user=phone) is
>> a valid alternate public identity.
>>
>> 3. In section 10.1.3: "The Service Provider Network MUST populate the
>> topmost Router header with a URI identifying the SIP signaling address of
>> the SIP-PBX. If the SIP-PBX is operating in the Registration Mode, then
>> the Service Provider Network MUST use the SIP signaling address (i.e. the
>> contact address) that was bound to the called Enterprise Public Identity
>> when the SIP-PBX registered, as described in section 7.1.4."
>> Does this need to be a MUST in the first sentence? In other words, will
>> the SIP PBX be upset by the absence of such a Route header field? I doubt
>> it. The Route header field might be useful for routing through any edge
>> proxies within the SP domain, but whether it survives across the
>> SIPconnect interface to the PBX hardly seems important. So should it be a
>> MAY in the first sentence?
>>
>> 4. "If the SIP-PBX is operating in the Static Mode, then the Service
>> Provider Network MUST use the SIP signaling address that was obtained
>> using DNS as described in section 7.2.1."
>> This too is talking about the Route header field, but this time for static
>> mode. For static mode, we should be using RFC 3263 procedures, and these
>> do not involve use of the Route header field.
>> Also the wording "the SIP signaling address that was obtained using DNS as
>> described in section 7.2.1." is strange, because 7.2.1 does not tell you
>> how an SP obtains information from DNS, but merely how the enterprise
>> populates DNS.
>>
>> 5. "From: "Anonymous" <anonymous at invalid.anonymous.com> ;tag=0728361"
>> The domain part should be "anonymous.invalid".
>>
>> 6. In 10.1.4: "For calls incoming to the Service Provider Network from the
>> PSTN, if the PSTN supplied an E.164 calling number",
>> and then in 10.1.5: "If the P-Asserted-Identity header is to be included,
>> then for calls where the Service Provider Network asserts the identity of
>> the calling user (e.g., for PSTN-based originations, or IP-based
>> originations where the calling user belongs to the Service Provider
>> Network)"
>> Why the difference between 10.1.4 and 10.1.5? Also, given that the two
>> examples shown are essentially the same, why not also align the display
>> names?
>>
>> 7. In 10.2.1 ". If the called user identity is based on an E.164 address,
>> then the SIP-PBX MUST populate the Request-URI with a SIP URI that adheres
>> to one of the three forms shown below."
>> The third form (option 3) is not E.164 - it is a dial string.
>>
>> 8. 10.2.4 - I don't see any need to specify P-Preferred-Identity.
>>
>> 9. In 10.2.5: "The SIP-PBX MUST populate the From header as specified for
>> the P-Asserted-Identity header in section 10.2.3".
>> Or an anonymous value.
>>
>> 10. In 10.2.6: "If the SIP-PBX is inside the Service Provider's trust
>> domain, then the SIP-PBX MUST include a P-Asserted-Identity header in
>> dialog-initiating INVITE requests sent to the Service Provider Network,
>> containing the Public Identity of the originating Enterprise user. In this
>> case the Service Provider Network uses the provided P-Asserted-Identity
>> header as the asserted identity for the call."
>> I see a problem complying with this if the call has arrived from elsewhere
>> without a PAI header field (e.g., retargeting case).
>>
>> 11. "If the SIP-PBX is outside the Service Provider's trust domain, then
>> the Service Provider Network MUST assert the identity of the originating
>> user by adding a P-Asserted-Identity header populated with the Public
>> Identity of the originating user."
>> This seems to be outside scope of SIPconnect.
>>
>> 12. "The SIP-PBX MAY provide a hint of the originating user's identity to
>> the Service Provider Network in the P-Preferred-Identity or P-Asserted-
>> Identity header."
>> Why give the PBX the option? Why not just stick to PAI. In fact, it is not
>> a hint, it really is an asserted identity. Its just that the SP may choose
>> to disregard the assertion.
>>
>> 13. "The Service Provider Network checks if the "hint" provided matches an
>> identity configured within the Service Provider Network for the SIP-PBX."
>> For email-style, the only thing configured should be
>> "sip:*@enterprise.com" or similar. It is misleading to talk about a
>> configured identity in that case.
>>
>> 14. "the Service Provider Network asserts a default identity for the SIP
>> PBX"
>> Is this the default public identifier?
>>
>> 15. "The Service Provider Network uses the asserted identity to apply the
>> appropriate calling restrictions and other originating services to the
>> call."
>> This seems a bit dangerous if the call has been retargeted from elsewhere,
>> e.g., from someone who is not a customer of the SP.
>>
>> 16. "On receiving an INVITE from the SIP-PBX, the Service Provider Network
>> MUST use the identity asserted in the P-Asserted-Identity header as the
>> Calling Line ID and Calling Name (aka calling name and number) for
>> presentation to the remote user, unless privacy or a specific Calling
>> Line ID and Calling Name Presentation is being requested by the Enterprise
>> Network as described in the sections that follow."
>> This is very strange, because in the case where the PBX is outside the
>> trust domain the PAI is not supplied or can be disregarded by the SP. So
>> only From can be used as caller ID.
>>
>> John
>>
>>> -----Original Message-----
>>> From: techwg-bounces at sipforum.org
>>> [mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock
>>> Sent: 21 October 2008 18:17
>>> To: David Hancock; techwg at sipforum.org
>>> Subject: Re: [SIPForum-techwg] Proposal for Action Item 8
>>> from SIPconnectface-to-face
>>>
>>> The attached ZIP contains a tracked-changed and clean version
>>> of the proposed resolution of action-item 8, for your review
>>> and comments.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: David Hancock
>>> Sent: Tuesday, October 21, 2008 10:21 AM
>>> To: 'techwg at sipforum.org'
>>> Subject: RE: Proposal for Action Item 8 from SIPconnect face-to-face
>>>
>>>
>>>
>>> Late yesterday I submitted to Spencer the output of our
>>> action item 8 from the Denver meeting to align sections
>>> 10,11,12,13. We extended this to include section-9, since it
>>> is closely coupled to these other sections.
>>>
>>>
>>>
>>> Here is a summary of the changes...
>>>
>>> 1. Updated Section 9 "Public Identity" to resolve comments.
>>>
>>> 2. Combined sections 10/11/12/13 under a new section 10
>>> "Establishing Basic 2-way Calls". Also repurposed this
>>> section slightly, so it only covers basic calls, and not
>>> Retargeting or Emergency Services, which are covered in
>>> section 11. We attempted to resolve all the comments against
>>> these sections, and line them up with the agreements from the
>>> face-to-face.
>>>
>>> 3. Moved the other "call signaling related" sections under
>>> a new section 11 "Service Interactions".
>>>
>>> 4. Moved the media-related procedures under a new section
>>> 12 "Media and Session Interactions"
>>>
>>>
>>>
>>> This action item updated text in the new sections 9 & 10
>>> only. The remaining text was moved, but not changed. For
>>> example, there are still open action items against the
>>> Retargeting and Emergency sections that this AI does not address.
>>>
>>>
>>>
>>> Here's the TOC for the affected sections.
>>>
>>>
>>>
>>> 9 Enterprise Public Identities
>>>
>>> 10 Establishing Basic 2-Way Calls
>>>
>>> 10.1 Incoming Calls from the Service Provider to the Enterprise
>>>
>>> 10.1.1 Populating the Request-URI header
>>>
>>> 10.1.2 Populating the To header
>>>
>>> 10.1.3 Populating the Route header
>>>
>>> 10.1.4 Populating the From Header
>>>
>>> 10.1.5 Populating the P-Asserted-Identity Header
>>>
>>> 10.2 Outgoing Calls from the Enterprise to the Service Provider
>>>
>>> 10.2.1 Populating the Request-URI
>>>
>>> 10.2.2 Populating the To Header
>>>
>>> 10.2.3 Populating the P-Asserted-Identity header
>>>
>>> 10.2.4 Populating the P-Preferred-Identity header
>>>
>>> 10.2.5 Populating the From header
>>>
>>> 10.2.6 Identifying the Originating User
>>>
>>> 10.2.7 Controlling the Calling Line ID and Calling Name
>>> Presentation
>>>
>>>
>>>
>>> 11 Service Interactions
>>>
>>> 11.1 Retargeting Related Services
>>>
>>> 11.1.1 Simple 302 Redirection
>>>
>>> 11.1.2 Retargeting via In-Dialog REFER
>>>
>>> 11.1.3 Retargeting via Out-of-Dialog INVITE
>>>
>>> 11.2 Emergency Services
>>>
>>> 11.2.1 Considerations for Emergency Services Destinations
>>>
>>> 11.2.2 Request URI - Emergency Services Destinations
>>>
>>> 11.3 Session Limits
>>>
>>>
>>>
>>> 12 Media and Session Interactions
>>>
>>> 12.1 Media Capability Negotiation
>>>
>>> 12.2 Codec Support and Media Transport
>>>
>>> 12.3 Transport of DTMF Tones
>>>
>>> 12.4 Echo Cancellation
>>>
>>> 12.5 Fax and Modem Calls
>>>
>>> 12.6 Call Progress Tones
>>>
>>> 12.7 Ringback Tone and Early Media
>>>
>>> 12.8 Putting a Session on Hold
>>>
>>>
>>>
>>> I also changed the following -- s/Subscription
>>> mode/Registration mode/ and s/Peering mode/Static mode/ (I
>>> believe this is the terminology we agreed to at the face-to-face).
>>>
>>>
>>>
>>> Comments on the re-org are welcome. I'll work on getting the
>>> proposed update put somewhere where you can read/review it.
>>>
>>>
>>>
>>> Thanks
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>>
>>> From: David Hancock
>>> Sent: Wednesday, October 15, 2008 4:13 PM
>>> To: techwg at sipforum.org
>>> Subject: Proposal for Action Item 8 from SIPconnect face-to-face
>>>
>>>
>>>
>>> Regarding action-item 8 from SIPconnect face-to-face...
>>>
>>>
>>>
>>> 8. Action Item to integrate/align sections 10,11,12,13.
>>> Dave Hancock
>>>
>>> and Jamie Palmer of Broadsoft to lead.
>>>
>>>
>>>
>>> Jamie and I reviewed these sections and the various technical
>>> comments against them, and propose that the 4 existing
>>> sections be collapsed into 2 sections. The organization of
>>> the two new sections will follow the organization of the
>>> existing 12 & 13, so that the new/combined section 10 covers
>>> SP Network à SIP-PBX calls, and the new 11 covers calls from
>>> the SIP-PBX à SP Network calls.
>>>
>>>
>>>
>>> One of the v00 review comments noted that the procedures in
>>> the existing 10/11/12/13 don't account for the use-case where
>>> the SIP-PBX forwards an incoming call from the SP network
>>> back to the SP network in a new INVITE. For example, the
>>> procedures don't support the case where the PAI of the new
>>> INVITE sent from SIP-PBX identifies a user external to the
>>> SIP-PBX. Another comment noted that the procedures don't
>>> align w.r.t., handling of emergency calls. We decided to
>>> resolve these issues by limiting the scope of the new section
>>> 11 to basic 2-way calls originated by a user in the SIP-PBX.
>>> Calls incoming to the SIP-PBX that are forwarded back to the
>>> SP network will be described in the subsequent "Retargeting"
>>> section (currently 15.5). Emergency calls will be covered in
>>> a subsequent separate chapter dedicated to emergency calls
>>> (currently 15.6.1).
>>>
>>>
>>>
>>> Another review comment noted that existing section 15.3
>>> "Basic 2-way Calling" contained duplicate material to
>>> existing sections 10/11/12/13. We decided to move any unique
>>> text from 15.3 into the new sections 10/11, and delete 15.3.
>>>
>>>
>>>
>>> With this (proposed) re-org, sections 10 and beyond describe
>>> call signaling for different call types, such as
>>>
>>> - basic 2-way calls originating from or terminating to SIP-PBX,
>>>
>>> - calls retargeted by SIP-PBX,
>>>
>>> - emergency calls originated by SIP-PBX
>>>
>>> - etc
>>>
>>>
>>>
>>> Existing section 14 "Media Attributes and Minimum
>>> Requirements" seems like an odd-man-out in this series.
>>> Therefore, we propose that this media-centric section 14 be
>>> moved to later in the document, so that all the sections
>>> related to call signaling can be grouped together.
>>>
>>>
>>>
>>> The new proposed document organization would then look like this...
>>>
>>>
>>>
>>> 10 Incoming Calls from the Service Provider to the Enterprise
>>>
>>> {covers basic 2-way DOD calls originated locally by SIP-PBX user}
>>>
>>>
>>>
>>> 11 Outgoing Calls from the Enterprise to the Service Provider
>>>
>>> {covers basic 2-way DID calls into SIP-PBX}
>>>
>>>
>>>
>>> 12 Service Interactions
>>>
>>> 12.1 Call Hold
>>>
>>> 12.2 Retargeting Related Services
>>>
>>> {includes call-fwding & xfer, and redirect to SP-based
>>> voice message server}
>>>
>>> 12.3 Regulatory Services
>>>
>>> {Describes everything related to emergency calls}
>>>
>>> 12.4 Message Waiting Indication
>>>
>>> {Describes how to signal the signal message-waiting info
>>> to the SIP-PBX when
>>>
>>> the SP network provides the voice-mail service. This
>>> wasn't in the v00 version -
>>>
>>> did we miss it, or agree to leave it out?)
>>>
>>>
>>>
>>> 13. Media Requirements
>>>
>>>
>>>
>>> I'll submit the proposed text for new sections 10 & 11 in a
>>> subsequent email. Once we see how that looks, we may want to
>>> make additional changes (such as moving 10 and 11 into
>>> level-2 subsections of section 12, and change the level-1
>>> name to something like "Call Signaling Requirements").
>>>
>>>
>>>
>>> Comments welcome.
>>>
>>>
>>>
>>> David
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techwg
>
-------------- next part --------------
An embedded message was scrubbed...
From: Paul Kyzivat <pkyzivat at cisco.com>
Subject: Re: SIPConnect PBX Registration
Date: Fri, 17 Oct 2008 10:12:34 -0400
Size: 6598
Url: http://sipforum.org/pipermail/techwg/attachments/20081024/35fc433c/attachment-0001.mht
More information about the techwg
mailing list