by Tom Taylor
The SIP Working Group met in two sessions, on Monday afternoon and Tuesday morning. In addition, informal meetings were held on some open issues from the list particularly including early media, on conferencing, on networking appliances, and on security. The Working Group sessions were chaired by Dean Willis [dean.willis@softarmor.com], Brian Rosen [Brian.Rosen@MARCONI.COM], and Joerg Ott [jo@tzi.uni-bremen.de].
First Session =============
1. BOF Announcements
The chairs drew the meeting's attention to the PRIM/SIMPLE BOFs scheduled for Monday afternoon, and announced the other BOFs mentioned above (except for the meeting on open issues, which was arranged later).
2. Agenda bashing
The agenda presented by Dean Willis was accepted.
3. Open Issues On the List
Jonathan Rosenberg [jdrosen@dynamicsoft.com] presented.
(a) Record-Routing
Problem: RFC 2543 contains no information on how to route in the reverse direction.
A meeting of interested parties was held at the bakeoff. A consensus was reached as indicated in the list: -- proxies can only use SIP URLs -- a proxy MAY insert any SIP URL it wishes so long as the URL routes back to that proxy -- the proxy SHOULD insert a URL that routes to the correct user in each direction -- the UAS reflects Record-Route including parameters in the 200 OK -- the methods by which the UAC and UAS build routes was specified -- a proxy may modify a Record-Route URL in a response -- there will be no transport param in the Record-Route URL: preferences obtained by SRV or similar means -- there will be no special handling for RFC 2543 clients not inserting Contact.
Robert Sparks [rsparks@dynamicsoft.com] commented that he had had concern during discussion about the transport issue, because it relies on SRV environment which is mot yet deployed to get transport preferences. It would be nice to have an interim solution. Henning Schulzrinne [hgs@cs.columbia.edu] responded that it is possible to issue a hint, but he worried that the interim method, too, may fail because of lack of awareness that it has to be configured.
(b) Meaning of Call-ID
What is meaning of a call with an existing Call-Id but a new From? It could indicate -- a new party to an existing call -- the new party replaces the existing party -- no special meaning. There is an issue with the first position: it uses Call-Id as a conference identifier. This is not always workable (e.g. in the merge case, where two separate calls are joined).
Proposal: Call-Id has neither conference nor replacement semantics. Define formal ways for conference, replacement.
Henning was concerned that we thereby lose the distinction between call-leg and call, which could be useful in future. Rohan Mahy [rohan@cisco.com] was concerned that we need more than the call/call-leg distinction gives us, and replaces isn't enough. There was further discussion, but the issue was not resolved.
(c) Tag issues
How is the tag computed? With what scope of uniqueness? The tag is used to: - reject incoming requests for a previously rejected call - differentiate multiple 200 OK responses to INVITE - identify a new call as re-INVITE for a pre-crash call.
Solutions: make tag unique to the UA instance (for crash protection) or unique within a call (otherwise). However, there is a problem when a call made by a UA returns to it. For crash recovery, we need two tags, each a function of the UA identity, to go into the To and the From header respectively. Incoming calls with an apparently new Call-Id but containing either tag are old calls.
Henning was concerned about over-specification within the standard. Further discussion resulted in agreed text, which will describe construction of the tag if crash-survival is not a requirement, plus a "MAY" clause for crash-survival.
More problems: what happens if there was no tag to start with, but the evolution of the call results in one being needed later. One possible solution is to make From: tags mandatory.
However, the consensus as recommended by Jonathan was that the tag should not be mandatory. If a problem comes up, the UAC should handle it pragmatically. Text should be added to 2543bis discussing the issue.
[NOTE: Per Jonathan, 3Jan01: This is not what I said. From tags are mandatory in rfc2543bis, as are To tags in the response. The issue is that there can be problems with older rfc2543 clients, and that these need to be handled gracefully ]
Another question: suppose the UAC receives a BYE after a crash and reboot. This will have an apparently new Call-Id, but a familiar tag. Should the response be 200 OK or 481? Jonathan suggested that the UAC issue a 200 OK to ensure that the call is cleared. Christian Huitema [huitema@microsoft.com] said to use 481 -- admit you don't know about the call and let the far end recover. Adam Roach [Adam.Roach@Ericsson.com] cited a need to distinguish methods in choosing the response. The basic concern is that 481 doesn't necessarily clear the call. Jonathan argued that, based on the principle of transaction independence, a 481 response on a re-INVITE fails that transaction but not the complete call. Despite this argument, the general view was that 481 means the call is dead. Jonathan's concern was that we are breaking a general model: call state shouldn't be determined by 400-class response. However this interpretation of 481 has already been implemented. The final consensus: 481 means the call is dead.
(d) SDP semantics
Which messages must SDP appear in, which must it not appear in? Jonathan looked to establish a general (probably complicated) procedure or restrict SDP to a finite set of possibilities. Henning asked that the meeting deal with 183 in a separate discussion. He proposed a "latest SDP prevails" model.
Itamar Gilad [ItamarG@tlv.radvision.com] urged that the WG get rid of SDP in ACK. Jonathan replied that some people depend on it for H.323 interworking. Christian Huitema suggested that the standard distinguish between acknowledged and unacknowledged messages. He proposed a rule that SDP can only be sent in messages which can be acknowledged. Robert Sparks noted some cases where re-INVITE does not work (e.g.) third party call control, especially with preconditions. Henning proposed that third party call control be handled as a special case, that it shouldn't shape the core specification. He had no issue with SDP in ACK for special cases. Gonzalo Camarillo [Gonzalo.Camarillo@lmf.ericsson.se] was concerned with ther effect on the transaction state machine if ACK is delayed waiting for SDP from the other side. Henning argued that 200 OK retransmissions are not such a big deal. Against Christian's insistence that it should be possible to acknowledge SDP, Henning pointed out that SDP in the ACK can be acknowledged negatively by issuing a BYE if it is unacceptable. The issues remained unresolved.
(e) Early Media
Many issues - can't change once started -- re-INVITE can't be issued while INVITE is in progress - can't easily get transferred while on hold - can't put early media on hold - difficult to reconcile with forking - the actual early media transmitted may not match the response code - requires PRACK - eliminates possibility of sequential searches.
However, we need some kind of indication for ISUP mappings. Possibilities: - live with it based on current wide deployment - deprecate, define separate billing-related signalling.
Itamar Gilad [missed his point] Adam Roach pointed out requirements beyond the PSTN e.g. resource reservation. Henning argued that early media breaks the session model, hence will continually break new methods and our material assuming that model. It is really desirable to preserve that model. He proposed a 283 response. Further discussion was deferred because of lack of time.
(f) mid-Call Redirect
Is a 302 response to re-INVITE allowed? What does it mean? What to do with Route headers?
The UAC can abandon the route set completely or partly reuse it. Abandoning could confuse proxies not in the original path. There is a problem if the new contact is not a UAS. In general, how to handle routes?
First question: is this a valid possibility? Henning suggested that we preserve simplicity, even if the documented procedure won't always work. Adam Roach made the specific suggestion to disallow a 302 response to a re-INVITE: mid-call redirection can be done by other means. The meeting agreed with Adam's proposal.
(g) IPv6 in SIP
Jonathan outlined a syntax problem with IPv6 addresses and gave three proposals for resolution. The meeting accepted the third proposal.
4. WG Working Methods
Jonathan Rosenberg reported that Scott has told the Chairs to be more restrictive on work item admissions. They plan to redraft the charter to scope the work to be done.
Henning noted that the difficulty comes about because the same group is handling both 2543bis and extensions. The preferred organization would have separate group(s) for extensions. Possibly there should be a split between PSTN-related and other work. Working Group management requires a solid draft progression plan with tracking.
Tom Taylor [taylor@nortelnetworks.com] wondered whether 2543bis should go back to MMUSIC, given changed conditions since last year's breakout. Henning responded that there were advantages to keeping 2543bis out of MMUSIC: more meeting time for both endeavours, and MMUSIC can concentrate on other work items. Dean Willis noted that some design teams set up last year continue to function, while others have faded.
Jonathan (continuing his remarks) observed that we need a project manager to run the WG, leaving technical experts to make their contributions. Also the Working Group needs more technical involvement -- other people besides Jonathan to write drafts. Finally, the WG needs more meeetings. Brian Rosen responded that the chairs are looking at the possibility of interim meetings.
Rohan Mahy noted that design teams stall because the same people are involved in multiple issues. The teams should consolidate and focus on priority issues. Dean Willis saw the need for more resources. Henning said no: the group needs a roadmap with priorities, so it can achieve solid progress on specific issues. He agrees with the need for aWG secretary and schedule tracker. Rohan Maky said the starting point should be currently chartered items. Christian Huitema took a quick census of those reading the list daily, and just a few hands were raised. He went on to say that the fact that most people don't read the list daily indicates overload. Henning noted the huge volume of FAQ questions. He made the proposal that there should be no more responses to newbies: the should be referred to another list.
The Chairs requested a hum on whether to create multiple WGs or reorganize the current one. The results were fairly even. Matt Holdrege [matt@ipverse.com] said we should make sure we write good specification if we want to reduce FAQ questions. Adam Roach made the final observation that not we are not likely to gain by splitting the WG, because the new groups would tend to have a common membership.
Tom Taylor +1 613 736 0961 taylor@nortelnetworks.com
Updated 12/13/2001