All: The interim meeting minutes are summarized here. Please go through them and let me and Enrico know if we missed anything. Thanks. CUSS WG Interim meeting (virtual) Thursday, Sept. 30, 2010 1500 GMT - 1700 GMT Raw note takers: James Rafferty, Vijay K. Gurbani This was the kick-off meeting of the newly formed CUSS WG held over WebEx. There were about 18-20 participants on WebEx. Chairs presented the agenda. No changes. In the Open Discussion period following the presentations, the following were agreed to: - Need a face-to-face meeting in Beijing. - Before Beijing, the chairs will determine consensus for adopting drafts to address the problem statement and requirement document deliverable and a UUI specification deliverable. Discussion on the candidate drafts to be held on the list. Alan Johnston presented problem statement and requirement draft.Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim/problem-statement-reqs.pdf
Draft: http://tools.ietf.org/html/draft-johnston-cuss-sip-uui-reqs-00 Fair amount of discussion on various parts of the draft: - ISDN user-to-user data has a maximum byte length of 128. May want to relax this for the SIP UUI service. Challenge is knowing under which services this restriction can be relaxed and which services will absolutely need this restriction to be in place. - It was pointed out that in ISDN, it is the originator that adds the UUI, but in SIP, it was an intermediary (see slides for call flow 3) that added the UUI. Need to reconcile whether or not SIP intermediaries can add UUI. - If intermediaries can add/remove UUI, do we need a H-I sort of mechanism to track the addition/removal of the UUI entries? - Discussion around Requirement 6 --- a solution that includes multi-part MIME should not be taken off the table. - Discussion on Requirement 8-9 on whether the option tag means that the recipient understands the UUI mechanism or whether the recipient understands a particular UUI format. Suggested to remove the phrase beyond the comma in Req-9. Alan presented the mechanism for transporting the UUI information in SIP. Discussion ensued on alternative mechanisms and the suggested mechanism of carrying it as a header.Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim/transporting-uui.pdf
Draft: http://tools.ietf.org/html/draft-johnston-cuss-sip-uui-00 Keith Drage presented a draft that defines a usage of the UUI header field to enable interworking with an ISDN device. There were a handful of open issues, but we did not get the time to cover all of them. The working group participants are urged to read the usage document and post to the list more complex scenarios that need to be studied for interworking.Slides: http://www.standardstrack.com/ietf/cuss/cuss-interim/interworking-UUI.pdf
Draft: http://tools.ietf.org/html/draft-drage-cuss-sip-uui-isdn-00 ------- Raw notes from James Rafferty Notes on CUSS Interim Call Rqmts Draft: - Drage: ISDN model does not support the Re-direct server case; Alan believes we need to support scenarios like this. Concern is who the source of the UUI information is, vs. ISDN case where this is better known. Drage: refer scenario: in ISDN, all UUI information is eliminated when the call is transferred; in our case, UUI is passed through. Alan: if there are multiple UUIs on referred calls, only one of the them gets passed through; somebody suggested history info might be the best way to track who inserted the UUI Drage: Feature tags are an example of a SIP facility that would do some of the things that UUI might do in a pure SIP environment. Consider adopting docs as CUSS docs in a couple of weeks; discuss on the list Meet at Beijing meeting and subsequently in interim meetings via conference call ------- Raw notes from Vijay K. Gurbani Alan went through the history, etc. Janet Byron: Length of the data is only 128 bytes. May want to relax it for SIP UUI service. Alan agrees that we may want to restrict the length at some times, but not others. Paul: Challenge is knowing which situation we are in. And whether interworking will occur at all. Alan went through the call flows on various usages of UUI. Keith: Call flow 3 may break the ISDN model. ISDN knows who the source is, if the UUI is passed in F2, then ISDN does not know who the source is. Paul: No negotiation in UUI between sender and receiver. Discussion ensued on the fact that ISDN originator adds UUI and in here, some intermediary is adding the UUI. This needs to be reconciled in Requirement 3. It was suggested to use HI as a mechanism for carrying multiple UUIs. Req 6: What is "uncommon SIP"? Multi-part MIME. But this is getting more common now, maybe even in gateways. A solution that includes Multi-part should not be taken off the table. Discussion on Requirement 8-9 on whether the option tag means that the recipient understands the UUI mechanism or whether the recipient understands a particular UUI format. Suggested to remove the phrase beyond the comma in Req-9. Mechanism draft, Alan Alan went through why INFO and other mechanisms are not used. Keith Drage went through the "Interworking ISDN call control UUI with SIP" draft to determine whether it can serve as a work item for the third deliverable in the charter. Several open issues, no time to discuss all. Most of all want to make sure that the working group participants think of more complex solutions that should be looked at. End of draft discussion. Open discussion for next steps on the drafts. Chairs decide not to hum on the virtual meeting for adoption of any drafts, but rather take it to the list to have some drafts adopted before Beijing. Seems to be consensus for a f2f meeting in Beijing. Keith indicated that after Beijing, most of the work can be done in virtual meetings. 1645 Meeting adjourned.
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.