Notes from SIP WG Interim Day 1 9Feb01 entered by Dean Willis ------------------------------------------------------------------------ Multiple from Fields Early Media Transfer Out of Consultion -- geting Refer-To address to actual endpoint Bye/Also in BIS Draft Request URI Parameters -- allowed, unallowed, recommended Reinvite Glare -- overlapping reinvites Preloaded Route Headers (route on initial INVITE) SRV Randomization Issues New open issues: Overlap Dialing Message Header Length limits Time Stamp Header usage Unknown Provisional Responses (set at 49 to fix in BIS) Discussion: SRV must be deployed properly to get proper behavior in record-routed networks. Request that BIS include clarification that record route with transport other than UDP requires that SRV records be correctly implemented. The issue is that a proxy that changes transport protocols and doesn't record route may cause problems on reflective side. Meaning of Call ID: Receive INVITE at conference with call-ID matching an existing call but with a different From: field. Proposal: follow simplicity, this is either an error or an all-new call leg. Argument: under 2543, this is legitimate behavior. However, call-ID has no conferencing semantics. This is not an error, just undefined. No objections to addressing on joins/replaces. SDP Semantics: What exactly is SDP exchange procedure? Which messages can contain or must contain SDP? Consensus from 49 -- offer and answer, two cases, SDP in INVITE and OK, or OK and ACK. Discussion -- do we need to modify UAs that honor 3rd SDP in ACK to discard call? Rough consensus -- this condition is up the receiver to resolve, general rule to ignore. From 49, we are allowing 183 in SDP. How do we deal with this and the offer/answer model? Early Media: Issues: send invite, get audio in reverse direction before call is "established". Since reinvite while invite in progress is disallowed, there is no way to modify the session parameters until the invite completes. Can't put early media on hold. Difficult to reconcile with forking. Early media may not match code it comes in (180 with fast busy). Requires PRACK. Eliminates possibility of sequential searches. Note: some kind of indication critical for ISUP mappings. Note: Callee-caller early media is one set of cases, caller-caller early media is another. Also case of reverse media with 1xx response. Case matrix developed in meeting. Point: difference between preparing to receive media before 200OK, and sending an early media stream before sending 200OK. There may be a requirement for an ability to refuse or squelch early media. Divergence into early-media and PSTN gateway interworking issues, . Action item: Adam and Gonzalo to clarify gateway behavior for pre-connect 200 vs early media in ISUP-interworking draft. Action item: Henning to includerecommendation against (should not) early media before 200 OK in BIS. Further exploration of early media to be devloped in later draft work. Discussion of manyfolks need for UI-semantic provisional response for "progress", aka 183. This implies a need for an IANA registration process for response codes and possibly methods. Action item: Henning to produce a IANA considerations draft for response codes and method names. Timestamp header: Spec says reflect timestamp in response, but not which one. Why? For retransmit timeing, want to know RTT between client and server. This means only needed 100 resposnes. However there are other uses. Conclusion: relection of timestamp header mandatory in all responses in BIS. Action item: Henning add to BIS. Message Header Lengths: 1500 byte limit exceeded frequently. Many implementations limit. What should spec say? Proposal: 1) SHOULD allow to 64k, 2) SHOULD allow any number of each header, 3) SHOULD allow headers of size bounded only by message size limit. Much debate about embedded, cellular, 5xx response codes, etc. Conclusions: Normative text about message size is a future problem -- not a good idea now. We want to put stuff needed to send response up front in message. May need a "minimal message only" mechanism for forward direction. Action item: Allison and Scott to take to Apps ADs and see if there are guidelines. Multiple Froms/Sender: Conclusion: Future extension work. Bye/Also Header: Some clients support now. Keep? Argument: whatever we decide to do becomes the solution. Proposal: remove Also header from BIS draft, consider obsolete. Somebody may wish to record history in separate draft -- Allison says may go directly to "historical". Action: Rick Dean to do informational record for history. Action: Henning to not include in BIS. Action: Robert Sparks to spank people who bring up Bye/Also on list. Overlapping Transaction: Can one inititate a new transaction while one is in progress? What does it mean? Needed for some cases such as PRACK, COMET, INFO for ISUP. Proposal: 1) Allow overlapping transactions under specific conditions. 2) Final response for new transaction not dependent on final response for previous. 3) Transactions do not affect state of each other. 4) Can only do them once tags/route obtained from earlier transaction. Question: too general or hard to use concretely? Action: Unknown party needed to query list and see if anybody has done this. close of notes at 1:30. Meaning of re-INVITE without SDP: