As per Relevance of the word signaling, we have this rfc below:
Network Working Group S.
Request for Comments: 2976
Category: Standards Track October 2000
The SIP INFO
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document proposes an extension to the Session
Protocol (SIP). This extension adds the INFO method to the
protocol. The intent of the INFO method is to allow for the
of session related control information that is generated during
session. One example of such session control information is ISUP
ISDN signaling messages used to control telephony call services
This and other example uses of the INFO method may be standardized
the future
Table of
1 Introduction................................................2
1.1 Example Uses................................................2
2 INFO Method.................................................3
2.1 Header Field Support for INFO Method........................3
2.2 Responses to the INFO Request Method........................4
2.3 Message Body Inclusion......................................5
2.4 Behavior of SIP User Agents.................................6
2.5 Behavior of SIP Proxy and Redirect Servers..................6
2.5.1 Proxy Server................................................6
2.5.2 Forking Proxy Server........................................6
2.5.3 Redirection Server..........................................6
3. INFO Message Bodies.........................................6
4. Guidelines for extensions making use of INFO................7
5. Security Considerations.....................................7
6. References..................................................8
Donovan Standards Track [Page 1]
RFC 2976 SIP INFO Method October 2000
7. Acknowledgments.............................................8
8. Author's Address............................................8
Full Copyright Statement....................................9
1.
The SIP protocol described in [1] defines session control
used during the setup and tear down stages of a SIP
session
In addition, the SIP re-INVITE can be used during a session to
the characteristics of the session. This is generally to change
properties of media flows related to the session or to update the
session timer
However, there is no general-purpose mechanism to carry
control information along the SIP signaling path during the session
The purpose of the INFO message is to carry application
information along the SIP signaling path
The INFO method is not used to change the state of SIP calls, or
parameters of the sessions SIP initiates. It merely sends
application layer information, generally related to the session
It is necessary that the mid-session signaling information
the post session setup SIP signaling path. This is the path taken
SIP re-INVITEs, BYEs and other SIP requests that are tied to
individual session. This allows SIP proxy servers to receive,
potentially act on, the mid-session signaling information
This document proposes an extension to SIP by defining the new
method. The INFO method would be used for the carrying of mid-
signaling information along the session signaling path
1.1 Example
The following are a few of the potential uses of the INFO message
- Carrying mid-call PSTN signaling messages between
gateways
- Carrying DTMF digits generated during a SIP session
- Carrying wireless signal strength information in support
wireless mobility applications
- Carrying account balance information
Donovan Standards Track [Page 2]
RFC 2976 SIP INFO Method October 2000
- Carrying images or other non streaming information between
participants of a session
These are just potential uses; this document does not specify
uses nor does it necessarily recommend them
It can also be envisioned that there will be other telephony
non-telephony uses of the INFO method
2. INFO
The INFO method is used for communicating mid-session
information along the signaling path for the call
The INFO method is not used to change the state of SIP calls,
does it change the state of sessions initiated by SIP. Rather,
provides additional optional information which can further
the application using SIP
The signaling path for the INFO method is the signaling
established as a result of the call setup. This can be either
signaling between the calling and called user agents or a
path involving SIP proxy servers that were involved in the call
and added themselves to the Record-Route header on the initial
message
The mid-session information can be communicated in either an
message header or as part of a message body. The definition of
message body and/or message headers used to carry the mid-
information is outside the scope of this document
There are no specific semantics associated with INFO. The
are derived from the body or new headers defined for usage in INFO
2.1 Header Field Support for INFO
Tables 1 and 2 add a column to tables 4 and 5 in the [1].
to Section 6 of [1] for a description of the content of
tables. Note that the rules defined in the enc. and e-e
in tables 4 and 5 in [1] also apply to use of the headers in
INFO request and responses to the INFO request
Donovan Standards Track [Page 3]
RFC 2976 SIP INFO Method October 2000
2.2 Responses to the INFO Request
If a server receives an INFO request it MUST send a
response
A 200 OK response MUST be sent by a UAS for an INFO request
no message body if the INFO request was successfully received
an existing call. Beyond that, no additional operations
required
Header Where
------ ----- ----
Accept R
Accept-Encoding R
Accept-Language R
Allow 200 -
Allow 405
Authorization R
Call-ID gc
Contact R
Contact 1xx -
Contact 2xx -
Contact 3xx -
Contact 485 -
Content-Encoding e
Content-Length e
Content-Type e *
CSeq gc
Date g
Encryption g
Expires g
From gc
Hide R
Max-Forwards R
Organization g
Table 1 Summary of header fields, A-0
Handling of INFO messages that contain message bodies is
the scope of this document. The documents defining the
bodies will also need to define the SIP protocol rules
with those message bodies
A 481 Call Leg/Transaction Does Not Exist message MUST be sent
a UAS if the INFO request does not match any existing call leg
Donovan Standards Track [Page 4]
RFC 2976 SIP INFO Method October 2000
If a server receives an INFO request with a body it understands
but it has no knowledge of INFO associated processing rules
the body, the body MAY be rendered and displayed to the user.
INFO is responded to with a 200 OK
If the INFO request contains a body that the server does
understand then, in the absence of INFO associated
rules for the body, the server MUST respond with a 415
Media Type message
Header Where
------ ----- ----
Priority R
Proxy-Authenticate 407
Proxy-Authorization R
Proxy-Require R
Require R
Retry-After R -
Retry-After 404,480,486
Retry-After 503
Retry-After 600,603
Response-Key R
Record-Route R
Record-Route 2xx
Route R
Server r
Subject R
Timestamp g
To gc(1)
Unsupported 420
User-Agent g
Via gc(2)
Warning r
WWW-Authenticate 401
Table 2 Summary of header fields, P-
Bodies which imply a change in the SIP call state or the
initiated by SIP MUST NOT be sent in an INFO message
Other request failure (4xx), Server Failure (5xx) and
Failure (6xx) responses MAY be sent for the INFO Request
2.3 Message Body
The INFO request MAY contain a message body
Donovan Standards Track [Page 5]
RFC 2976 SIP INFO Method October 2000
2.4 Behavior of SIP User
Unless stated otherwise, the protocol rules for the INFO
governing the usage of tags, Route and Record-Route
retransmission and reliability, CSeq incrementing and
formatting follow those in [1] as defined for the BYE request
An INFO request MAY be cancelled. A UAS receiving a CANCEL for
INFO request SHOULD respond to the INFO with a "487
Cancelled" response if a final response has not been sent to
INFO and then behave as if the request were never received
However, the INFO message MUST NOT change the state of the
call, or the sessions initiated by SIP
2.5 Behavior of SIP Proxy and Redirect
2.5.1 Proxy
Unless stated otherwise, the protocol rules for the
request at a proxy are identical to those for a BYE request
specified in [1].
2.5.2 Forking Proxy
Unless stated otherwise, the protocol rules for the
request at a proxy are identical to those for a BYE request
specified in [1].
2.5.3 Redirection
Unless stated otherwise, the protocol rules for the
request at a proxy are identical to those for a BYE request
specified in [1].
3. INFO Message
The purpose of the INFO message is to carry mid-session
between SIP user agents. This information will generally be
in message bodies, although it can be carried in headers in the
message
The definition of the message bodies or any new headers created
the INFO method is outside the scope of this document. It
expected that separate documents will be created to
definition of these entities
Donovan Standards Track [Page 6]
RFC 2976 SIP INFO Method October 2000
In addition, the INFO method does not define additional
for ensuring in-order delivery. While the CSeq header will
incremented upon the transmission of new INFO messages, this
not be used to determine the sequence of INFO information. This
due to the fact that there could be gaps in the INFO message
count caused by a user agent sending re-INVITES or other
messages
4. Guidelines for extensions making use of
The following are considerations that should be taken into
when defining SIP extensions that make use of the INFO method
- Consideration should be taken on the size of message bodies to
carried by INFO messages. The message bodies should be kept
due to the potential for the message to be carried over UDP and
potential for fragmentation of larger messages
- There is potential that INFO messages could be forked by a
Proxy Server. The implications of this forking of the
in the INFO message need to be taken into account
- The use of multi-part message bodies may be helpful when
the message bodies to be carried by the INFO message
- The extensions that use the INFO message MUST NOT rely on
INFO message to do anything that effects the SIP call state or
state of related sessions
- The INFO extension defined in this document does not depend
the use of the Require or Proxy-Require headers. Extensions
the INFO message may need the use of these mechanisms. However
the use of Require and Proxy-Require should be avoided,
possible, in order to improve interoperability between
entities
5. Security
If the contents of the message body are private then end-to-
encryption of the message body can be used to prevent
access to the content
There are no other security issues specific to the INFO method
The security requirements specified in the SIP specification
to the INFO method
Donovan Standards Track [Page 7]
RFC 2976 SIP INFO Method October 2000
6.
[1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg
"SIP: Session Initiation Protocol", RFC 2543, March 1999.
7.
The author would like to thank Matthew Cannon for his
to this document. In addition, the author would like to thank
members of the MMUSIC and SIP working groups, especially
Rosenberg, for comments and suggestions on how to improve
document
8. Author's
Steve
5100 Tennyson Parkway, Suite 200
Plano, Texas 75024
Email: sdonovan@dynamicsoft.
Donovan Standards Track [Page 8]
RFC 2976 SIP INFO Method October 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Donovan Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
