[SIPForum-techwg] Proposal for Action Item 8 from SIPconnectface-to-face
Jamie Palmer
jamie at broadsoft.com
Wed Oct 22 10:10:13 EDT 2008
I like regrouping those sections to the top-level as well. How about
renaming ³Retargeting² to ³Transfer and Forwarding Service Interactions².
Also ‹ what about message-summary (MWI)? Should we have a top level section
just to cover that interface?
JBP
On 22/10/08 9:41 AM, "Elwell, John" <john.elwell at siemens.com> wrote:
> David,
>
> Looks good, except that the contents of section 11 are rather mixed, and I am
> not sure that the heading "Service interactions" is very helpful. For example,
> 11.1, "retargeting-related services", seems to describe services rather than
> interaction of services. Likewise, 11.2, "emergency services", seems to
> describe services (or more precisely a single service), rather than
> interaction of services. 11.3 "Session limits" seems to have little to do with
> interaction of services, although possibly it could be construed as
> interaction between calls. Also I don't like the word "services", which seems
> to cause problems in the IETF.
>
> Why can't we have three top-level sections with the titles "Retargeting",
> "Emergency calls" and "Session limits"?
>
> Also I am not convinced about "retargeting", because some of the retargeting
> features involve redirection or call transfer, rather than what is known in
> SIP as retargeting. Unfortunately I don't have a proposed alternative.
>
> John
>
>
>>
>>
>>
>> From: techwg-bounces at sipforum.org [mailto:techwg-bounces at sipforum.org] On
>> Behalf Of David Hancock
>> Sent: 21 October 2008 17:21
>> To: techwg at sipforum.org
>> Subject: Re: [SIPForum-techwg] Proposal for Action Item 8 from
>> SIPconnectface-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 HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20081022/f9fbeb9c/attachment-0001.html
More information about the techwg
mailing list