Re: WG Review: Call Control UUI for SIP (cuss)

[Gonzalo Camarillo <[e-mail]>]

Hi,

please, keep the DISPATCH list in the cc: of this thread so that all
interested parties can participate in this discussion.

Thanks,

Gonzalo


On 29/06/2010 6:08 PM, Laura Liess wrote:
> Cullen,
> 
> Bruno is right.
> 
> SIP-T is used today for tunneling ISUP in SIP. In many cases  people
> don't implement SIP-T at all, because they intend to migrate the
> network to full SIP,  but still need to interwork with PSTN for a
> while. Should we require ISUP-capabilities for SIP application
> servers? We just need a way to transport a piece of data between SIP
> application servers, SIP end devices and PSTN. The solution can not be
> ISUP.
> 
>>>  However, I
>>> think this charter should be rejected by the IESG and sent
>>> back to the drawing board.
> 
> The need for UUI was recognized back in 2006,  when we had the first
> draft with this proposal see
> http://tools.ietf.org/id/draft-johnston-sipping-cc-uui-00.txt . We
> discussed the issue a number of times and people stated their need for
> this. We have now 2010.
> 
> Laura
> 
> 
> 2010/6/29  <[e-mail]>:
>> Hum, I'm a bit surprised by the comment about SIP-T. RFC3372 does state that SIP-T does not come into play when there is no PSTN involved.
>>
>> At the end of clause 2 we can read the following: "4.  IP origination - IP termination: This is a case for pure SIP. SIP-T (either encapsulation or translation of ISUP) does not come into play as there is no PSTN interworking."
>>
>> Besides, SIP-T would require encapsulating a full ISUP message (e.g. IAM) while we are interested in just one parameter of the message in the context of CUSS. This would I believe be a more severe drawback if SIP-T were used for this purpose.
>>
>> Bruno
>>
>>
>>> -----Message d'origine-----
>>> De : [e-mail]
>>> [mailto:[e-mail]] De la part de Gonzalo Camarillo
>>> Envoyé : mardi 29 juin 2010 13:03
>>> À : DISPATCH
>>> Objet : [dispatch] Fwd: Re: WG Review: Call Control UUI for SIP (cuss)
>>>
>>> Hi,
>>>
>>> FYI: note the discussion below on the IETF general list.
>>>
>>> Cheers,
>>>
>>> Gonzalo
>>>
>>> -------- Original Message --------
>>> Subject: Re: WG Review: Call Control UUI for SIP (cuss)
>>> Date: Mon, 28 Jun 2010 20:24:23 +0200
>>> From: Cullen Jennings <[e-mail]>
>>> To: [e-mail] <[e-mail]>
>>> CC: IETF Discussion Mailing List <[e-mail]>
>>>
>>>
>>> As far as I can tell, the WG says they wants to transfer some
>>> information to achieve cross vendor interoperability.
>>> However, what I believe the charter is actually going to do
>>> is exactly the opposite of that. When you get your head
>>> around what this charter is proposing, it is going to form a
>>> more or less opaque container for transporting proprietary
>>> information in a SIP header. It's hard to imagine how this
>>> will help interoperability.
>>>
>>> If we wanted to have interoperability, the charter would say
>>> what information needs to be transferred and have the WG
>>> define a way to get it between systems in an operable way.
>>> What the charter for this WG actually says they are going to
>>> do is make a special container for transfer proprietary
>>> information.  There's not even willing to say what that
>>> proprietary information is used for other than things ISDN
>>> UUI which is a  non interoperable and fairly proprietary
>>> field in ISDN.
>>> Furthermore they have asserted that  existing containers such
>>> as SIP-T or SIP bodies can't be used for reasons that are
>>> hard to describe. (I reject the idea that because the call
>>> might not involved the PSTN, it can't use SIP-T).
>>>
>>> I think the folks that want to do this should get a much
>>> clear explanation of how this results in interoperability and
>>> why exist approach such as SIP-T will not work before this is
>>> chartered.
>>>
>>> I do think there is a need to standardize some important call
>>> control information used in call centers and related places.
>>> However, the "we need a standard container to exchange secret
>>> information WG" is a bad idea and violates the sprit of the
>>> SIP change process not to mention the mission of the IETF.
>>>
>>> In summary, I'm in favor of figuring out what the problems
>>> are people hope to solve with this WG and figuring out a way
>>> to write interoperable standards to achieve that. However, I
>>> think this charter should be rejected by the IESG and sent
>>> back to the drawing board. The RAI area has things of higher
>>> priority items to work on than a SIP header for transfer
>>> proprietary data.
>>>
>>>
>>>
>>> On Jun 22, 2010, at 10:00 , IESG Secretary wrote:
>>>
>>>> A new IETF working group has been proposed in the Real-time
>>>> Applications and Infrastructure Area.  The IESG has not
>>> made any determination as yet.
>>>> The following draft charter was submitted, and is provided for
>>>> informational purposes only. Please send your comments to the IESG
>>>> mailing list ([e-mail]) by Tuesday, June 29, 2010.
>>>>
>>>> Call Control UUI for SIP  (cuss)
>>>> --------------------------------------------------
>>>> Current Status: Proposed Working Group
>>>>
>>>> Last modified: 2010-06-21
>>>>
>>>> Chair(s):
>>>>  TBD
>>>>
>>>> Real-time Applications and Infrastructure Area Director(s):
>>>>  Gonzalo Camarillo <[e-mail]>  Robert Sparks
>>>> <[e-mail]>
>>>>
>>>> Real-time Applications and Infrastructure Area Advisor:
>>>>  Gonzalo Camarillo <[e-mail]>
>>>>
>>>> Mailing Lists: TBD
>>>>
>>>> Description of Working Group:
>>>>
>>>> The Call Control UUI for SIP (CUSS) working group is chartered to
>>>> define a Session Initiation Protocol (SIP) mechanism for
>>> transporting
>>>> call-control related user-to-user information (UUI) between User
>>>> Agents.
>>>>
>>>> The mechanism developed in this working group is applicable in the
>>>> following situations:
>>>>
>>>> 1. The information is generated and consumed by an application using
>>>>   SIP during session setup but the application is not necessarily
>>>>   even SIP aware.
>>>> 2. The behavior of SIP entities that support it is not significantly
>>>>   changed (as discussed in Section 4 of RFC 5727).
>>>> 3. Generally only the User Agent Client (UAC) and User Agent Server
>>>>   (UAS) are interested in the information.
>>>> 4. The information is expected to survive retargeting, redirection,
>>>>   and transfers.
>>>> 5. SIP elements may need to apply policy about passing and screening
>>>>   the information.
>>>> 6. Multi-vendor interoperability is important.
>>>>
>>>> This mechanism is not applicable in the following situations:
>>>>
>>>> 1. The behavior of SIP entities that support it is significantly
>>>>   changed (as discussed in Section 4 of RFC 5727).
>>>> 2. The information is generated and consumed at the SIP layer by SIP
>>>>   elements.
>>>> 3. SIP elements besides the UAC and UAS might be interested in
>>>>   consuming (beyond applying policy) the information.
>>>> 4. There are specific privacy issues involved with the information
>>>>   being transported (e.g., geolocation or emergency-related
>>>>   information).
>>>>
>>>> User data of the mechanism will be clearly marked with the
>>>> application, encoding, semantics, and content type,
>>> allowing policy to
>>>> be applied by UAs.  The working group will define the
>>> information that
>>>> each application must specify to utilize the mechanism.
>>> This type of
>>>> application-specific information will be specified in
>>> standards-track
>>>> documents.
>>>>
>>>> One important application of this mechanism is interworking
>>> with the
>>>> ISDN User to User Information Service.  This application defined by
>>>> ITU-T Q.931 is extensively deployed in the PSTN today
>>> supporting such
>>>> applications as contact centers, call centers, and automatic call
>>>> distributors (ACDs).  A major barrier to the movement of these
>>>> applications to SIP is the lack of a standard mechanism to
>>> transport
>>>> this information in SIP.  For interworking with ISDN, minimal
>>>> information about the content of the UUI is available to
>>> the PSTN-SIP
>>>> gateways.  In this case only, the content will just
>>> indicate ISDN UUI
>>>> Service 1 interworking rather than the actual content.
>>>>
>>>> Call control UUI is user information conveyed between user agents
>>>> during call control operations.  As a result, the
>>> information must be
>>>> conveyed with the INVITE transaction, and must survive proxy
>>>> retargeting, redirection, and transfers.  The mechanism
>>> must utilize a
>>>> minimum of SIP extensions since it will need to be
>>> supported by many
>>>> simple SIP user agents such as PSTN gateways.  The mechanism must
>>>> interwork with the existing ISDN service but should also be
>>> extensible
>>>> for use by other applications and non-ISDN protocols.
>>>>
>>>> Even though interworking with the PSTN is an important requirement,
>>>> call control UUI can be exchanged between native SIP
>>> clients that do
>>>> not have any ISUP support. Therefore, existing SIP-T
>>>> encapsulation-based approaches defined in RFC3372 do not meet the
>>>> requirements to transport this type of information.
>>>>
>>>> Mechanisms based on the SIP INFO method, RFC2976, will not be
>>>> considered by the working group since the UUI contents carry
>>>> information that must be conveyed during session setup at the user
>>>> agent - the information must be conveyed with the INVITE
>>> transaction.
>>>> The information must be passed with the session setup request
>>>> (INVITE), responses to that INVITE, or session termination requests.
>>>> As a result, it is not possible to use INFO in these cases.
>>>>
>>>> The group will produce:
>>>>
>>>> - A problem statement and requirements document for
>>> implementing a SIP
>>>> call control UUI mechanism
>>>>
>>>> - A specification of the SIP extension to best meet those
>>> requirements.
>>>>
>>>> Goals and Milestones
>>>> ====================
>>>>
>>>> Sep 10 - Problem statement and requirements document to IESG
>>>> (Informational)
>>>> Mar 11 - SIP call control UUI specification to IESG (PS)
>>>> _______________________________________________
>>>> IETF-Announce mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/ietf-announce
>>>
>>>
>>> Cullen Jennings
>>> For corporate legal information go to:
>>> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>>>
>>>
>>>
>>> _______________________________________________
>>> dispatch mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>>>
>> _______________________________________________
>> dispatch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
> _______________________________________________
> Ietf mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf
>