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 <bruno.chat...@orange-ftgroup.com>: >> 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 : dispatch-boun...@ietf.org >>> [mailto:dispatch-boun...@ietf.org] 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 <flu...@cisco.com> >>> To: i...@ietf.org <i...@ietf.org> >>> CC: IETF Discussion Mailing List <ietf@ietf.org> >>> >>> >>> 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 (i...@ietf.org) 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 <gonzalo.camari...@ericsson.com> Robert Sparks >>>> <rjspa...@nostrum.com> >>>> >>>> Real-time Applications and Infrastructure Area Advisor: >>>> Gonzalo Camarillo <gonzalo.camari...@ericsson.com> >>>> >>>> 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 >>>> ietf-annou...@ietf.org >>>> 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 >>> dispa...@ietf.org >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> dispa...@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
