2.8.21 Session Initiation Protocol Project Investigation (sipping) BOF

Current Meeting Report

Minutes, SIPPING IETF 51
as reported by Dean Willis


Agenda accepted as proposed.

Charter discussion -- under review from IETF, further discussion postponed.

Robert Sparks discussed call transfer and related dependencies. No issues raised.

Requirements for hearing-impaired users -- Arnoud van Wijk

Reqs: 1) Automatic use of relay services 2) Transparent to end user 3) Caller ID visible 4) Support for current and legacy relay devices 5) Add/remove media streams at any point 6) one-to-many streams, efficiently (multicast or broadcast?) -- discussion on this point. Request feedback on technical means from audience.

Bottom line: hearing impaired people should be a able to communicate using ordinary phones using IM, chat, video, etc.

Work plan: Finish requirements draft by Dec01. Move example flows to later in document

Question: Do we need to consider the global text telephony efforts from 3G? Response -- maybe, let's focus on requirements for now. Comment -- really critical to consider requirements. For example, text in one way and voice in the other could be useful. Further discussion -- this probably needs to be a topic of coordination with 3GPP SA1. Further -- bidirectional streams with mixed attributes may already be solved by FID in MMUSIC, but this approach may be explicitly blocked by assumptions in 3GPP. From 3GPP Liason: There are explicit requirements to support hearing impaired users in 3GPP, especially for emergency services. It would be useful to have a commonality of requirements between the two orgs. Reminder to consider that the current solutions are extremely resource restricted.

Call Control Modeling -- Rohan Mahy

Terminology -- definition of call, conversation space, and participants as user-oriented terms. This relates to several defs from 2543 -- call, call leg, conference, and session. Debate on whether changing of media qualifies as a change of content and thereby makes the changing element a "participant" of the call. Examples given using a visual set representation (see slides) and an algebra of conversation space manipulations. Work planning briefly discussed, but due to dependency on charter (currently undefined) left for later.

Event Package for Calls -- Jonathan Rosenberg

Several components; events package, new headers (To-Join and To-Replace) to carry SIP URLS for use in joining or replacing existing call, usage of those URLs. This seems to resolve some open issues with consultation transfers. Debate on advantages of extensions vs. not adding them. Some debate on headers vs. parameters and interaction with REPLACES. Extended and very confused conversation on semantics of set operations in conversation spaces. Some discussion of whether this sort of work belongs in SIP or SIPPING and how it should be planned. No conclusion.

Conventions for Accessing Media Server Resources -- Eric Burger

Proposes encoding convention for LHS of SIP URI. Intense discussion with no clear consensus resulted during the initial presentation. Primary concerns raised by RFC3087 proponents include likelihood of bad assumptions about function being made by users.

3GPP Architecture -- Keith Drage

Review of operating assumptions from 3GPP. There was an initial consensus in the room that SIPPING group has enough background on 3GPP to start considering concrete requirements without further review. However, some of the people in the room expressed a great deal of surprise at aspects of 3GPP architecture as they were discussed, so the validity of this consensus is questionable. Material presented reviewed 3GPP architecture, various SCSFs and other elements, and introduced basic assumptions such as register-before-call. Pointers given to relevant 3GPP documents.

QoS and Why it Matters to SIP -- Johnson Oyama

Discussed absolute dependency of IMS architecture on QoS mechanism as policy enforcement for billing model, and rols of preconditions signaling (manyfolks) in set up. One likely difficulty noted by audience is that there may be lots of real cases where RSVP is only supported by part of the network, so setup signaling with preconditions is likely to fail. Pointers given to relevant 3GPP documents.

Security and Authentication -- Peter Howard

Concerns raised with 3GPP authentication policy of validing REGISTER and not INVITE. This appears to run a misattribution risk as client software cannot be considered "trusted" to not alter presented user identity. The role of the media authorization token was discussed at length. Pointers given to relevant 3GPP documents. Further discussion of the "required register" model indicated significant concern that the 3GPP semantics of REGISTER are very different from SIP's semantics. Interesting points raised are that 3GPP currently only considers singular registration (one registration per SIM card at any given time). 3GPP currently intends to use SIP-based authentication and integrity (hash based) mechanisms rather than using IPSEC or TLS at the user level. This is primarily for performance reasons. 3GPP wishes to define EAP for SIP using keying based on the AKA algorithm used in GSM. Pointers given to relevant 3GPP documents.

The Cx Interface -- Johanna Wild

Presentation on the Cx interface, which is a AAA interface in 3GPP. Questions raised on interdomain handoff of existing call (editor's note -- doesn't happen, one must register in new domain then make new call) which could not be resolved in meeting.

Dependencies on SIP and SIPPING Drafts -- Ileana Leuca

Speaker reviewed working relationship between IETF and 3GPP. The basic tenet -- that SIP be used harmoniously - -was challenged by an audience member on the principle that much if the complexity in 3GPP comes from trying to require SIP registration before making a call, and this is very different from IETF usage of registration. The responding argument is that one can't change the mindset of millions of mobile users overnight. (Editors note: registration means something very different in GSM than it does in SIP, and the unfortunate name similarity seems to have caused a vast amount of confusion).

Discussion item: it would be useful to know more about why 3GPP has selected the given IDs as critical. 3GPP has used an approach of defining call flows that sound reasonable, and when it turns out that the most reasonable looking call flow for a particular scenario has dependencies on ongoing IETF work, the draft defining that IETF work goes on the list of dependencies. This lead to a discussion of a need for more detailed requirements analysis, which has occurred in the IETF as well. Rather than hearing that 3GPP has decided to use a particular draft to solve a specific problem, it might benefit the IETF to hear a generic description of the problem and propose a solution for that problem. There appeared to be a consensus to use this sort of technique for future collaboration between 3GPP and SIPPING.

Network Announcements -- Eric Burger

Debate centered on RFC 3087 issues and advisability of making "parseable" service names. There was a significant diversion into early media issues, which appear to be quite complex when interworking with media servers and ISUP.


SIP URI Conventions for Media Servers
Network Announcements with SIP
A SIP Call Control Model
SIP Support for Hearing and Speech Impaired Users
SIP Call Package
SIP and the application of SIP as used in 3GPP
3GPP Security and Authentication
3GPP and SIP-AAA requirements
3GPP-IETF Dependencies
RFC 3113