Open Issues in bis 12/6/2001 5:28 PM Jonathan Rosenberg dynamicsoft

Resolved since last time: #7: CANCEL for non- INVITE –MUST be prepared to receive –SHOULDNOT send for anything but INVITE –New methods can define usage –Not in spec yet, will be in - 06 #10: Stripping maddr: OK? –Yes, in -05 #11: record-routing non- INVITE mid-call? –Proxy can, UA ignores –In –05 #20: mixing multicast/unicast in offer/answer –Disallowed, in –05 #21: granularity of multicast in SDP –Will fix in offer-answer-01

Resolved since last time: #23: dynamic PT reuse –Disallowed –Clarifications in offer- answer-01 #26: should we specify how to handle misaligned SDP? –No; removed in bis-05 #58: Rejecting mid- call SDP where offer is in 2xx –Make it so it never is needed –Already in bis-05 #71: RTT Estimation: how? –Algorithm now specified in bis-05

Resolved Since Last time: #72: Multicast CANCEL –Multicast allowed, but works like unicast –Means CANCEL is responded to even over multicast –In bis-05 #73: Respond to held SDP w/ Held SDP –Dont; in offer-answer-00 #84: CANCEL/Request race condition –Wait till 1xx; in bis-05 #107: e/p lines in SDP –Offer-answer-01 indicates its not mandatory, in line w/ sdp-new

Resolved Since Last Time #118: 481 then BYE –Is call down on 481, or only after you send a BYE? –Bis-05: send a BYE #121: Reason codes in BYE/CANCEL? –Separate extension #122: CANCEL on 2xx MUST/MAY/SHOULD? –MUST in bis-05 #130: BYE v. CANCEL –CANCEL before 2xx –BYE afterwards –In bis-05 #133: On hold indication –Use a=inactive instead of

Resolved Since last time #138: Fork or not to fork –Fork #163: Where to put SDP stuff –In separate I-D #216: Directionality of Alert-Info –Can be both request and response –In bis-05

Open Issue #24/#146: re-use disabled streams Spec says that once youve disabled a stream (port zero) you cant reuse it –Result is that SDP size increases as you disable/add streams Why? –MUST maintain implicit ordering of codecs Problem is increasing size of SDP –Issue for 3gpp it seems Proposal –Can never remove a disabled stream –But, if you add a new one, it can take disabled streams slot within SDP Can be totally different media –This keeps ordering without increasing size of SDP

Open Issue #81: Caching of SIP Proxy Credentials Spec says a UA should cache its credentials for a proxy, and reuse next time it sends to that proxy How does UA know what proxy its sending to? –No easy way for initial requests –For re-INVITES, depends if that proxy record-routed – no easy way to know! –If proxy didnt record-route, Proxy-Auth never stripped Proposal –MAY use any cache strategy –RECOMMENDED to place credentials in request if it has same call-id as a request you got a challenge for that realm on (next slide) –MAY have configured local outbound realm – cache credentials to it –MAY reuse UA credentials if To field in request is same as previous –What you are really caching is the nonce

Issue #81 Flow UA1 P1 P2 UA2 |INVITE | | | | >| | | |407 Realm: A | | | |< | | | |INVITE Realm: A | | | | >| | | | |INVITE | | | | >| | | |407 Realm: B | | | |< | | |407 Realm: B | | | |< | | | |INVITE Realm:A,B | | | | >| | | | |INVITE Realm:B | | | | >| | | | |INVITE | | | | >| | | |200 | | | |< | | |200 | | | |< | | |200 | | | |< | | | |ACK Realm: A,B | | | | >| | | | |ACK Realm: B | | | | >|

Issue #88: Addressing Proxy w/ OPTIONS Bis-05 says the target is in the r-uri, which can be a proxy or UAS. What URI for a proxy? Solution: sip:domain, much like registrations.

Issue #109: Allow in non-INVITE Two questions: –Is it allowed outside of INVITE/OPTIONS –What URL does it refer to in an OPTIONS response? Subsequent request may get routed elsewhere! Answer one: –No – has no useful meaning Answer 2: –General problem, for Accept, Accept- Encoding, etc., even Authorization –State that it refers to request URI in original request

Issue #113: Overlapping Forward Transactions Current SIP model –One INVITE at a time –Within an INVITE, other non-INVITEs –Each non-INVITE cannot overlap This has limitations –Non-INV throughput 1/RTT –Cannot update INVITE (early media) INVITE INFO PRACK INFO

Why did we do it? INVITE: Confusion about most recent session description –Cannot determine ordering of SDP in both responses Non-INVITE –Cannot guarantee sequence delivery Proposal? –Disallow overlapping INV –Allow overlapping non-INV Notion of full state nonsensical Strict sequencing within content

Open Issue #126: Behavior on no ACK to 2xx to re-INVITE Current text says to re- INVITE to re-establish session state –Could get complicated – what if that fails too? For initial INVITE, you send a BYE –For conformity, shouldnt it be the same for re-INVITE? Proposal: –Send a BYE in this case

Open Issue #128: 503 Handling Should SRV processing continue with the next element if you got a 503 when trying one of them? Yes

Open Issue #131: Challenging gateways If a proxy or UAS challenges a UAC that is a gateway, is the challenge –For the gateway –For the user through the gateway In the latter case, the gateway might play a prompt to ask for the password How to tell the difference? Proposal –Realms –Gateway knows realm it has credentials on, answers challenges for it –Gateway could ask user for password for realms it doesnt know, these may be for user

Open Issue #139: INVITE glare A INVITEs B at same time B INVITEs A Problem: –No way for B to order INVITE from A and 2xx from A –Same for A Ordering needed to know which is most recent SDP Current text recommends a 5xx with Retry-After –Problem is that its slow –Apparently is happening in real usage Proposal: –Be explicit –Define a 491 response code to indicate this –Two cases: INV from far side beats 491 to your INV –Send 491 –Retry randomly in 0-3s 491 from far side beats INV from far side –Respond 2xx

Two cases of 491 INV 491 INV OK INV 2xx

#140: Remove URL from call-leg definition Why do that? –Helps overlap dialing – can change the To field in re- invites on the same leg –Can use actual URL in From field in re-INVITE in reverse direction –Faster UA lookups Drawbacks: –Backwards compatibilty issues – would need a Supported header –Could still be an issue for proxies Discussion –Overlap point is moot if overlapping INVITE not allowed –Can do faster lookups without a spec change –From field in reverse re- invite not useful for policy anyway, not authenticated Proposal –Change nothing

#144: Branch ID = Transaction ID Transaction ID computation is challenging –Many fields –Conditional inclusion (tags) Bis-05 already has branch ID as unqiue for each transaction Proposal: Allow branch ID to be the transaction ID –Clients MAY insert –Cookie in value to indicate its unique Would improve performance, simplify interop, little cost since you must still fallback Recommendation: accept proposal

#145: Stateless SRV Part I Bis-05 says that all requests with the same call-id go to the same next-hop That is a problem for proxies, which are either stateless or just transaction stateful! Call-ID granularity chosen for overlap dialing Stateless algorithm would need to: –Alphabetize DNS answer HGS suggests order by weight –Choose index as H(Call-ID) –Ugly Proposal: –Revert to only requiring requests within a transaction to same next hop –Stateless proxies need to do what they need to do

#150: Saying dont send Spec has many ways to say dont send me media: –A=sendonly –A=inactive –Bw=0 –Port zero – Do we need all of these?? Answer: no, but we need several: –A=sendonly stops receipt of media –A=inactive stops RTP/RTCP in both directions –Port zero terminates media stream (stop tools) –All others not needed OK?

Open Issue #140: Call Leg w/o URLs Problem: –Call leg ID includes a combination of To/From/Call-ID, which includes URLs –SIP URLs make lousy identifiers Must canonicalize Long Problem: –From field in reverse re- INVITEs may not be the sender of the request! –Loss of idempotency Proposal: –Re-define call-leg ID with tags/Call-ID ONLY –Needs Supported header in INVITE/2xx No impact on proxies though –Benefits Re-INVITEs can carry real identity Faster call leg lookups Glare scenario improved Replaces header easier

#164: Proxy-Authentication-Info Defined (barely) in rfc2617, used for mutual auth between UAC and proxies Problem: missing realm parameter –Makes it hard for client to figure out which header is for which client Approaches: –Give up –Add realm –Use nonce Proposal: –Use nonce –Client supplies unique cnonce in each request –Response has cnonce mirrored, so it can be used to match

#178: Deprecate absolute times Expires header and expires param can be in absolute time Absolute time requires time sync between client and server –Not always the case –Would need to include Date header to tell other side what they thought date is –Result is effectively always delta time Proposal: deprecated absolute times in Expires, expires Two variants –Remove entirely (if no one is using) –MUST be prepared to receive, but MUST NOT send (backwards compatible)

#179: Multicast to unicast REGISTER Multicast REGISTER refreshes –Multicasting them also may be useful for replication –Unicasting useful if multicast was only for discovery How to do first REGISTER multicast, rest unicast? –301 to unicast URL –Sip:foo.com;maddr= If it fails, you need to try multicast again –General issue for cached redirects – try the original URI Proposal –Add text to 301 section, saying try original URI on failure –Add text to registration section, detailing this case

#181: Stock splits? No – forking OPTIONS OPTIONS can fork Youll get only one 200 OK back Who knows which UA it corresponds to Ideally, would like to hear from all UA it reached Could use an approach similar to SUBSCRIBE –Reverse OPTIONS from each server back to client –Too complex Proposal: –Document limitation

#184: Size does matter Sub-problem 1: MTU and fragmentation –Were seeing sip messages bigger than ethernet mtu –Solutions Deprecate UDP Deprecate UDP inter- server Define sip fragmentation Use UDP IFF size < 1500, else TCP –Add response code that means response is too big to actually fit so client retries with TCP Ignore Sub-problem 2: Maximum field sizes –Spec says nothing on maximum header or parameter sizes –People often impose a limitation in their implementation –Has resulted in interop issues –What to do? Specify no limits Define limits Ignore

#188: Reply-To You know what it means. We dont have it. –Not the same as Contact (thats a host address) –Not the same as From (might not want return calls back to me) Issues –Use Remote-Party-ID instead? –Separate extension? –Privacy implications? Need to strip off at edge or something? Have an R-P-ID equivalent? Proposal: –Its simple. –Its understood. –We need it. –Just put it in.

#197: Contact in OPTIONS response There are two types of Contact –3xx/REGISTER semantics –INVITE/INV-2xx semantics Which one is OPTIONS response using? Odds are you cant signal directly to the contact if it were the INV/2xx semantics –Firewall, nat Proposal: –3xx semantics

#203: URL Params in To/From Table I allows port but not maddr in URL in To/From Should either be all transport related params, or none To/From should be logical addresses Proposal: –Neither port, transport, maddr, ttl

#204: Password in To/From Bis-05 allows URL password in the From field, but not in the To field. Seems inconsistent –Should either allow both or document why the discrepancy exists Proposal –Discrepancy is because password is to identify the originator in a simple way –Password for To would be wrong if request forwarded –Document these

#205: Header/Method params in Contact Bis-05 allows method and header params in URL in 3xx/register Contact Do we really want that? –Headers: yes; you could add a Subject for example to a call to you –Method: no, except people have confused method and methods for presence stuff Proposal: –Dont specify things that are known wrong –Disallow method, allow headers

#207: Handling of media failures Spec is silent on what to do in SIP if session fails –ICMP errors –Lack of RTCP –Etc. Draft-rosenberg-sip- reconstitute suggests a re- INVITE to see if that helps –Will help if end system has failed – will reconstitute session state at a backup –Wont help if network problem exists Most of text in reconstitute draft is not normative –Implementation guidelines Only normative text is to send this re-INVITE on failure –Needs to be in bis Proposal: –SHOULD re-INVITE –SHOULD send BYE if it doesnt help

#210: Timer D depends on client T1 Timer D in INVITE Client transaction depends on Timer H in server transaction –See next slide Timers scale based on local RTT estimate T1 So, client may have wrong value for timer at server Proposal –Define RTT independent minimums (32s in this case)

FSM Dependencies | | | | V | | ACK sent | | | | | | | | Completed | | | >| | | | | | ^ | | | | | Timer D fires | | - | | | V | | | | | | Terminated|< | | | | | INVITE V Timer G fires | send response send response | | | | | | Completed | | | >| |< | | | | | ACK | | | - | >+ | Timer H fires | V fail to TU | | | | | | Confirmed | | | | | | Client INVITE Transaction Server INVITE Tranaction Timer H = 64*T1 Timer D = Timer H

#212: Applicability of RTT Estimates RTT Estimate is done using transactions, between client and server transactions –So, stateless proxies dont count Thus, RTT estimate to IP addr X might have X as a stateless proxy –That estimate would be wrong for other R-URI What to do? Proposal: Ignore –Use IP address anyway A B C 100ms 200ms A sends to B, gets RTT estimate to IP X as 200ms A sends to C through X again, RTT estimate of 200ms is wrong; should be 300ms

#219/#221: SRV algorithm More work needed here TBD Jonathan

#220: Stateless SRV Pain II SRV processing algorithm retains state –Where each request in a transaction goes –Set of failed servers! Second piece of state is a big problem –How does a stateless proxy know that a server has failed? Possibilities –Each request starts at the top and will take require detection of failure each time –Problematic if server recovers mid-transaction Proposal –RECOMMENDED that servers that use SRV are stateful –Otherwise, start at the top as above –Document issues that arise

#231: Stateless UAS Stateless UAS is not well defined in the spec but possible –Regenerates the response for each request –Never sends 1xx Works fine for both INVITE and non- INVITE transactions Why do you want this? –Needed for DoS SYN attack prevention style attacks –401/407 should always be sent this way Issue: should we talk more about this behavior? Proposal –Yes – its needed for DoS attack prevention

#232: TLS v. IPSec Bis-05 recommends TLS for transport layer security Issues –Need not have same thing for u2p and p2p –UDP/IPSec has no congestion control –IPSec has no useful keying scheme –TLS allows application to know authenticated ID of far side Many cases, IP address based policy is NOT what you want –Wholesale SIP trunk Proposal –Proxies MUST support TLS for p2p operation –Proxies MAY support IPSec –U2p is a separate problem

#266: Heterogeneous Error Response Forking Problem User A Proxy User B User C |INVITE | | | | >| | | | |INVITE | | | | >| | | |INVITE | | | | >| | |415 | | | |< | | | |ACK | | | | >| | | |180 | | | |< | |180 | | | |< | | | | |200 | | | |< | |200 | | | |< | | | |ACK | | | | >|

Reasons for the problem Proxy merging rules are best on single best wins Merging of 401/407 credentials only works when ALL elements generate a challenge! –Doesnt allow for merging across response codes Proposals –TBD

#281: URL as key to LS DB Bis-05 says that you use the entire URL as the key to store registration info in the Location Service DB –I.e., To field URL This URL is matched, using URL equality, against Request-URI of requests for routing Problem –R-URI may have port/maddr/transport/ttl –These would not have been in To of REGISTER –Thus, they dont have URL equality –404 is getting sent by proxies Proposal –Make key a matter of local policy –Need only be consistent between registrar and proxy –Document guidelines

#282: Timer C needs default for proxies Timer C specifies time INVITE client transaction waits for final response after provisional Currently, spec says TU specifies it For UAC, represents how long the phone rings What is it for proxies? Issues –Need to specify a minimum –If proxies give up early, calls will fail (proxies will cancel on giving up) Proposal –32s

The Biggie: Routing Bugs #159, #161, #213, #218, #268 Proposals: –TBD by Robert