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.chatras@xxxxxxxxxxxxxxxxxx>: > 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-bounces@xxxxxxxx >> [mailto:dispatch-bounces@xxxxxxxx] 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 <fluffy@xxxxxxxxx> >> To: iesg@xxxxxxxx <iesg@xxxxxxxx> >> CC: IETF Discussion Mailing List <ietf@xxxxxxxx> >> >> >> 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 (iesg@xxxxxxxx) 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.Camarillo@xxxxxxxxxxxx> Robert Sparks >> > <rjsparks@xxxxxxxxxxx> >> > >> > Real-time Applications and Infrastructure Area Advisor: >> > Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx> >> > >> > 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-Announce@xxxxxxxx >> > 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 >> dispatch@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/dispatch >> > _______________________________________________ > dispatch mailing list > dispatch@xxxxxxxx > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf