[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cuss] Interim meeting minutes



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.