[SIPForum-techwg] Proposal for Action Item 8 from SIPconnectface-to-face

[Elwell, John]

> -----Original Message-----
> From: David Hancock [mailto:D.Hancock at CableLabs.com] 
> Sent: 24 October 2008 21:38
> To: Elwell, John; techwg at sipforum.org
> Subject: RE: [SIPForum-techwg] Proposal for Action Item 8 
> from SIPconnectface-to-face
> 
> 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. 
[JRE] I guess it would have to, but this is something we don't yet have in the spec.

> 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. 
[JRE] Yes, I think we view it similarly. Concerning terminology, we could still keep the words "responsible for" but qualify them along the lines that responsibility is limited to being able to forward requests to the SIP PBX.
 
> 
> 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. 
[JRE] I am not sure I agree. I certainly agree that if a call arrives addressed to TEL:13035551234 it would not be delivered to the enterprise, because presumably it would resolve to somewhere else. I also agree that if a call arrives addressed to SIP:13035551234 at someOtherDomain.com, it would not be delivered to enterprise.com. However, for SIP:13035551234 at enterprise.com, it is explicitly addressed to enterprise.com, and only enterprise.com can interpret the digit string. I believe what I say is true even for SIP:+13035551234 at enterprise.com;user=phone, although I am prepared to hear counter arguments in that particular case.

> 
> 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.
[JRE] Yes.

> 
> 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?
[JRE] If I understand correctly, the PBX also would need to be responsible for the domain operator.com to the following extent. For inbound calls, it will receive calls addressed to SIP:13035551101 at operator.com, say, and would need to perform look-up on the user part. For outbound calls addressed to sip:*@operator.com, the PBX would need to see whether it is responsible for the particular user part, and if not, forward to the SP. The problem I see is, what if the PBX needs some other identifiers for users who are not reachable via DDI? It can't really define new identifiers based on the operator.com domain, because it might introduce conflicts.

John

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