{"draft":"draft-ietf-sip-record-route-fix-10","doc_id":"RFC5658","title":"Addressing Record-Route Issues in the Session Initiation Protocol (SIP)","authors":["T. Froment","C. Lebel","B. Bonnaerens"],"format":["ASCII","HTML"],"page_count":"18","pub_status":"PROPOSED STANDARD","status":"PROPOSED STANDARD","source":"Session Initiation Protocol","abstract":"A typical function of a Session Initiation Protocol (SIP) Proxy is to\r\ninsert a Record-Route header into initial, dialog-creating requests in\r\norder to make subsequent, in-dialog requests pass through it.  This\r\nheader contains a SIP Uniform Resource Identifier (URI) or SIPS\r\n(secure SIP) URI indicating where and how the\r\nsubsequent requests should be sent to reach the proxy.  These SIP or SIPS\r\nURIs can contain IPv4 or IPv6 addresses and URI parameters that could\r\ninfluence the routing such as the transport parameter (for example,\r\ntransport=tcp), or a compression indication like \"comp=sigcomp\".  When\r\na proxy has to change some of those parameters between its incoming\r\nand outgoing interfaces (multi-homed proxies, transport protocol\r\nswitching, or IPv4 to IPv6 scenarios, etc.), the question arises on\r\nwhat should be put in Record-Route header(s).  It is not possible to\r\nmake one header have the characteristics of both interfaces at the\r\nsame time.  This document aims to clarify these scenarios and fix bugs\r\nalready identified on this topic; it formally recommends the use of\r\nthe double Record-Route technique as an alternative to the current RFC\r\n3261 text, which describes only a Record-Route rewriting solution.  \r\n[STANDARDS-TRACK]","pub_date":"October 2009","keywords":["[--------]","multi-homed","user agent","proxy","interoperability","double record-routing"],"obsoletes":[],"obsoleted_by":[],"updates":[],"updated_by":[],"see_also":[],"doi":"10.17487\/RFC5658","errata_url":null}