Notes by Bert Culpepper, Day 2, 2nd session
Interim meeting 2/9/01
Open issues discussion
Jonathan led the discussion using his list of issues presented at 49th IETF ( http://www.cs.columbia.edu/~jdrosen/papers/sipwgdec00_issues.ppt <http://www.cs.columbia.edu/~jdrosen/papers/sipwgdec00_issues.ppt> ). Most will be resolved in the bis. Those not resolved as of the last WG meeting include: Meaning of call-id, SDP semantics, overlapping transactions, multiple from fields, early media, transfer out of consultation, request URI parameters, bye/also, re-invite glare, pre-loaded route headers, SRV randomization issues, overlap dialing, message/header length restrictions
bug of handling of unknown 1xx messages as 100, this is a problem with 183. solution is to forward all unknown 1xx messages upstream. Bill's proposal is for all UAs include "proxy require: bis" header. Shouldn't be needed if default proxy behavior is to forward all unknown 1xx messages upstream. The bis will have this issue clarified.
Discussed record-route issue (including what transport is supported by next hop) being closed, Jonathan posted text to the SIP list.
Meaning of call-ID: issue-what is the meaning of a receiving an invite with a call-id that matches an existing call leg (but different From). consensus is it's not an error nor does it mean anything.
SDP semantics: issue-what is exactly the exchange procedure? consensus was that it's only to occur in two places: in the offer and answer. SDP in either INV/200 or 200/ACK.
Meaning of reINVITE with out SDP: (editor's note: didn't capture the consensus.)
Early Media: issues 1-no way to modify it once started, 2-can't transfer while on hold. 3- can't put media on hold. 4-problems with forking. 5-early media may not match the code it comes in (e.g. 180 & fast busy tone). 6-requires PRACK. 7-eliminates possibility of sequential searches.
The following table shows the problems that apply to the three cases where early media exist.
reverse media reverse+1xx forward early media can't modify once started can't modify once started can't modify once started forking (matching) forking (bandwidth) can't hang-up just one branch requires PRACK
The bandwidth problem (caller can receive multiple RTP streams and not support combined bandwidth) introduces a requirement to be able to refuse a media stream.
The can't hang-up problem (caller can't CANCEL individual branches prior to final responses of a forked request) introduces a requirement to have a reverse message.
A reverse INVITE was talked about as a possible solution, a requires header will be needed for this approach.
Another consideration is with PSTN Gateways - they need to know when to send 200 OK vs. 1xx.
consensus: bis will say UAs SHOULD NOT send media prior to 200 OK, but not forbid it. There will be a separate draft for early media. ISUP I-D authors should update isup draft to discuss when gateways send 200 or 180.
Timestamp headers: issue-which response to reflect timestamp. The useful purpose of the header is in 100 for RTT determination. consensus: supply the timestamp header in all responses, specifically 100 Trying.
Message/header lengths: issue-1500 message limit exceeded frequently, implementations limit header or parameter sizes. Proposals are 1) to allow up to 64K, 2) should allow any number of each header (via, record-route), 3) should allow headers of any size (not beyond message size limit).
A recommended UA behavior is to put the important headers (those needed for response routing) up front. So endpoints can send an error response about the message being too big.
Normative text on max messages size is long term. May need a forward message indicating max supported length so proxies can gracefully "refuse" request or not record-route if doing so will result in message length exceeding that supported by the UA.
multiple from fields: - conclusion: future work, will be a SIP extension.
BYE/Also - has been removed from bis draft, the consensus is that this is deprecated. May be documented in an information I-D that becomes a historical RFC to support existing implementations that use it. New implementations should use REFER. Rick indicated he'd put together this draft. Robert Sparks will take ownership of this issue on the SIP list.
Overlapping Transactions: issue-can a new transaction start while one is in progress. Proposal: allow overlapping under specific conditions, 1) final response for the new transaction is not dependent on final response of the previous transaction, 2) transactions do not affect state of each other, 3) can only do them once tags/routes obtained from provisional response of outstanding request. It is thought sending a request prior to completion of a pending request should be OK under these condition for most methods. Exception is the INVITE method. Could be a problem for other methods if CANCEL is used with the method (since specific request to cancel can't be determined if more than one is pending). Action: need to find out if anyone implemented CANCEL for any method other than INVITE before documenting the resolution.