An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing
The information below is for an old version of the document that is already published as an RFC.
This is an older version of an Internet-Draft that was ultimately published as RFC 3581.
|Authors||Henning Schulzrinne , Jonathan Rosenberg|
|Last updated||2015-10-14 (Latest revision 2003-07-03)|
|RFC stream||Internet Engineering Task Force (IETF)|
|Additional resources||Mailing list discussion|
|IESG||IESG state||RFC 3581 (Proposed Standard)|
|Responsible AD||Allison J. Mankin|
|Send notices to||<email@example.com>|
A new Request for Comments is now available in online RFC libraries. RFC 3581 Title: An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing Author(s): J. Rosenberg, H. Schulzrinne Status: Standards Track Date: August 2003 Mailbox: firstname.lastname@example.org, email@example.com Pages: 13 Characters: 66133 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sip-symmetric-response-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3581.txt The Session Initiation Protocol (SIP) operates over UDP and TCP, among others. When used with UDP, responses to requests are returned to the source address the request came from, and to the port written into the topmost Via header field value of the request. This behavior is not desirable in many cases, most notably, when the client is behind a Network Address Translator (NAT). This extension defines a new parameter for the Via header field, called "rport", that allows a client to request that the server send the response back to the source IP address and port from which the request originated. This document is a product of the Session Initiation Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information.