RFC 3327 on Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new Request for Comments is now available in online RFC libraries.


        RFC 3327
                                    
        Title:      Session Initiation Protocol (SIP) Extension Header
                    Field for Registering Non-Adjacent Contacts
        Author(s):  D. Willis, B. Hoeneisen
        Status:     Standards Track
        Date:       December 2002
        Mailbox:    dean.willis@softarmor.com,
                    bernhard.honeisen@nokia.com, b.hoeneisen@ieee.org
        Pages:      17
        Characters: 36493
        Updates/Obsoletes/SeeAlso:   None
                                    
        I-D Tag:    draft-willis-sip-path-08.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc3327.txt


The REGISTER function is used in a Session Initiation Protocol (SIP)
system primarily to associate a temporary contact address with an
address-of-record.  This contact is generally in the form of a Uniform
Resource Identifier (URI), such as Contact:
<sip:alice@pc33.atlanta.com> and is generally dynamic and associated
with the IP address or hostname of the SIP User Agent (UA).  The
problem is that network topology may have one or more SIP proxies
between the UA and the registrar, such that any request traveling from
the user's home network to the registered UA must traverse these
proxies.  The REGISTER method does not give us a mechanism to discover
and record this sequence of proxies in the registrar for future use.
This document defines an extension header field, "Path" which provides
such a mechanism.

This document is a product of the Session Initiation Protocol and the
Session Initiation Proposal Investigation Working Groups 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.


Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
<ftp://ftp.isi.edu/in-notes/rfc3327.txt>

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux