1 / 11

67 th IETF (November 5-10, 2006) San Diego, CA (USA)

Handling Large UDP Responses in SIP Scott Lawrence and Vijay K. Gurbani draft-gurbani-sip-large-udp-response-00. 67 th IETF (November 5-10, 2006) San Diego, CA (USA).

reese-byers
Download Presentation

67 th IETF (November 5-10, 2006) San Diego, CA (USA)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Handling Large UDP Responses in SIPScott Lawrence and Vijay K. Gurbanidraft-gurbani-sip-large-udp-response-00 67th IETF (November 5-10, 2006) San Diego, CA (USA)

  2. SIP responses get bigger due to response aggregation resulting from forking, R-R headers with state information, other headers (Path, Service-Route, …), SDP in answer, … If response size > link MTU, fragmentation results; reassembly often not possible. Result: a failed session attempt over UDP, but may succeed over TCP. Fragmentation/reassembly problematic with middleboxes (draft-heffner-frag-harmful-02, http://www1.ietf.org/mail-archive/web/sip/current/msg17295.html). UDP deprecation will not happen overnight: in the meantime, better to diagnose when and how UDP is causing problems. Problem Statement

  3. The Problem UAC Proxy1 Proxy2 UAS 408

  4. Use provisional responses: 140, 141 (described later). A repairable final response (possibly 4xx). Problems: HERFP, false positives. Use message/sipfrag in a 4xx (a la hop-limit-diagnostics). Problems: What to prune in the response? Request in backwards direction. Problems: No Contact to send the request to, UA may not be directly accessible (NATs), forking results in many requests coming back. Possible Solutions

  5. Solution: Provisional responses UAC Proxy1 Proxy2 UAS 141 141 141 408 140 408

  6. WG List Discussion – 14x approach • Are both 140 (proxy) and 141 (uas) needed? Can one be suppressed? • The 140 is intended only for when the proxy is changing from UDP due to message size; not for all changes to UDP. • Incremental deployment argues for both • Interaction with PRACK? • Can we send the 14x without 100rel without affecting UA state machines when other 1xx responses use it? • Specifically requesting TCP all the way through. • Can do so for the R-URI with “transport=tcp” on the retried request, but what about intermediaries routing the request based on alternate logic?

  7. WG List Discussion - alternatives • In 4xx response solution, can we tolerate false positives (i.e., force a call to fail that would have otherwise succeeded)? • Request in the backwards direction?

  8. Next steps • WG interest in pursuing this? • WG item?

  9. Diagnostic Responses for SIP Hop Limit ErrorsS. Lawrence, A. Hawrylyshen, R. Sparks draft-hop-limit-diagnostics-03 67th IETF (November 5-10, 2006) San Diego, CA (USA)

  10. Recap • When sending 483 Hop Limit Exceeded,Include the headers from the request as a message/sipfrag body • Analogous to ICMP behavior used by traceroute

  11. WG List Discussion • Expands use of Warning to non-SDP errors • Generates large responsesProblematic for UDP • Is this useful for other error responses as well? • Request in reverse direction?

More Related