Hi, please keep both the IETF and the DISPATCH mailing lists in the recipients list in this discussion.
Cheers, Gonzalo On 29/06/2010 8:23 PM, Paul Kyzivat wrote: > > > DRAGE, Keith (Keith) wrote: >> The UUI information is NOT ISUP. It is a transparent envelope to the entire >> ISDN, so it is not part of an ISDN protocol and therefore not part of an >> ISUP protocol. When carried by ISUP the envelope is bundled up in another >> envelope with other information that ISUP carries transparently. >> >> So I believe, and have said repeatedly in the past, that references to SIP-T >> are irrelevant in this case. >> >> The problem we do have though is that are legacy usages of this information. >> In particular applications in PBXs carry it between themselves in ISDN call >> establishment. The information itself is not standardised. If you want to >> migrate a PBX from DSS1 to SIP, then you have to take this information into >> account. The desire is not for a WG group to standardise this existing usage >> (which in my view would be a complete non-starter), but to allow the >> transfer of the existing information when migrated to a SIP environment. The >> information transferred does not form part of SIP, and should not be >> standardised as part of SIP. > > How many different mechanisms do we have to construct for the purpose of > tunneling stuff over SIP? > > Its especially bad if the stuff is neither standardized nor negotiated. > It then just provides more opportunity for non-interoperability. > > It had been my impression that this content was standardized by ITU. > If nobody can bother to standardize it, then it hardly seems worth > working on. > > Thanks, > Paul > >> regards >> >> Keith >> >> >> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[email protected]] On Behalf Of >>> [email protected] >>> Sent: Tuesday, June 29, 2010 1:00 PM >>> To: [email protected]; [email protected] >>> Subject: Re: [dispatch] Fwd: Re: WG Review: Call Control UUI >>> for SIP (cuss) >>> >>> 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 : [email protected] >>>> [mailto:[email protected]] 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 <[email protected]> >>>> To: [email protected] <[email protected]> >>>> CC: IETF Discussion Mailing List <[email protected]> >>>> >>>> >>>> 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 ([email protected]) 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 <[email protected]> >>> Robert Sparks >>>>> <[email protected]> >>>>> >>>>> Real-time Applications and Infrastructure Area Advisor: >>>>> Gonzalo Camarillo <[email protected]> >>>>> >>>>> 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 >>>>> [email protected] >>>>> 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/dispatch >>>> >>> _______________________________________________ >>> dispatch mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/dispatch >>> >> _______________________________________________ >> dispatch mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
