RFC 6086
Session Initiation Protocol (SIP) INFO Method and Package Framework
Part 1 of 7 π π
Title Block π¦
- RFC number: 6086
- Title: Session Initiation Protocol (SIP) INFO Method and Package Framework
- Series: Internet Engineering Task Force (IETF)
- Authors: C. Holmberg (Ericsson), E. Burger (Georgetown University), H. Kaplan (Acme Packet)
- Category: Standards Track
- ISSN: 2070-1721
- Date: January 2011
- Obsoletes: RFC 2976 π
- Updates: none listed
Abstract β¨
okay so this doc defines a method called INFO for the Session Initiation Protocol (SIP), plus an Info Package mechanism πΈ it also obsoletes RFC 2976, so RFC 2976 is officially retired and this one is the new main character π
for backward compatibility, it also describes a "legacy" mode of using INFO that matches how RFC 2976 defined it. the doc calls this "legacy INFO Usage" π«Ά
Status of This Memo π
this is an Internet Standards Track document, so it's a real standard and not just vibes π
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). if you want more info on Internet Standards, check Section 2 of RFC 5741 π§
want the current status of this doc, any errata, or a way to send feedback? go to http://www.rfc-editor.org/info/rfc6086 π
Copyright Notice π
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this doc was published. please actually read these, bestie, because they explain your rights and restrictions for this doc π
if you pull Code Components out of this doc, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. they come without warranty, as the Simplified BSD License describes π
Table of Contents πΊοΈ
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Motivation ......................................................4
3. Applicability and Backward Compatibility ........................5
4. The INFO Method .................................................6
4.1. General ....................................................6
4.2. INFO Request ...............................................6
4.2.1. INFO Request Sender .................................6
4.2.2. INFO Request Receiver ...............................7
4.2.3. SIP Proxies .........................................8
4.3. INFO Message Body ..........................................8
4.3.1. INFO Request Message Body ...........................8
4.3.2. INFO Response Message Body ..........................9
4.4. Order of Delivery ..........................................9
5. Info Packages ...................................................9
5.1. General ....................................................9
5.2. User Agent Behavior .......................................10
5.2.1. General ............................................10
5.2.2. UA Procedures ......................................10
5.2.3. Recv-Info Header Field Rules .......................11
5.2.4. Info Package Fallback Rules ........................12
5.3. REGISTER Processing .......................................12
6. Formal INFO Method Definition ..................................13
6.1. INFO Method ...............................................13
7. INFO Header Fields .............................................15
7.1. General ...................................................15
7.2. Info-Package Header Field .................................15
7.3. Recv-Info Header Field ....................................16
8. Info Package Considerations ....................................16
8.1. General ...................................................16
8.2. Appropriateness of Info Package Usage .....................16
8.3. INFO Request Rate and Volume ..............................16
8.4. Alternative Mechanisms ....................................17
8.4.1. Alternative SIP Signaling Plane Mechanisms .........17
8.4.2. Media Plane Mechanisms .............................18
8.4.3. Non-SIP-Related Mechanisms .........................19
9. Syntax .........................................................19
9.1. General ...................................................19
9.2. ABNF ......................................................19
10. Info Package Requirements .....................................20
10.1. General ..................................................20
10.2. Overall Description ......................................20
10.3. Applicability ............................................20
10.4. Info Package Name ........................................21
10.5. Info Package Parameters ..................................21
10.6. SIP Option-Tags ..........................................22
10.7. INFO Message Body Parts ..................................22
10.8. Info Package Usage Restrictions ..........................22
10.9. Rate of INFO Requests ....................................23
10.10. Info Package Security Considerations ....................23
10.11. Implementation Details ..................................23
10.12. Examples ................................................24
11. IANA Considerations ...........................................24
11.1. Update to Registration of SIP INFO Method ................24
11.2. Registration of the Info-Package Header Field ............24
11.3. Registration of the Recv-Info Header Field ...............24
11.4. Creation of the Info Packages Registry ...................25
11.5. Registration of the Info-Package Content-Disposition .....25
11.6. SIP Response Code 469 Registration .......................26
12. Examples ......................................................26
12.1. Indication of Willingness to Receive INFO Requests
for Info Packages ........................................26
12.1.1. Initial INVITE Request ............................26
12.1.2. Target Refresh ....................................27
12.2. INFO Request Associated with Info Package ................28
12.2.1. Single Payload ....................................28
12.2.2. Multipart INFO ....................................28
13. Security Considerations .......................................30
14. References ....................................................31
14.1. Normative References .....................................31
14.2. Informative References ...................................32
Appendix A. Acknowledgements .....................................351. Introduction β¨
this doc defines a method called INFO for the Session Initiation Protocol (SIP) [RFC3261] π
the whole point of an INFO message is to carry application level information between endpoints, using the SIP dialog signaling path π¦ note that INFO is not used to update the characteristics of a SIP dialog or session. instead, it lets the applications using the SIP session swap information, which might update the state of those applications π§
using INFO doesn't count as its own dialog usage π ββοΈ INFO messages are always part of an invite dialog usage [RFC5057] and they share its fate, so if that usage goes, the INFO goes with it π INFO messages cannot be sent as part of other dialog usages, and they can't be sent outside an existing dialog either.
this doc also defines an Info Package mechanism π an Info Package spec defines the content and semantics of the information carried in an INFO message tied to that package. the mechanism also gives user agents (UAs) a way to say which Info Packages they're willing to receive INFO requests for, and which Info Package a specific INFO request belongs to π«Ά
a UA uses the Recv-Info header field on a per-dialog basis to say which Info Packages it's willing to receive INFO requests for. it can set an initial set during dialog establishment and then set a new one whenever it wants during the lifetime of the invite dialog usage π
NOTE: A UA can use an empty Recv-Info header field (a header field without a value) to indicate that it is not willing to receive INFO requests for any Info Package, while still informing other UAs that it supports the Info Package mechanism.
when a UA sends an INFO request, it uses the Info-Package header field to say which Info Package the request is tied to π one particular INFO request can only be associated with a single Info Package, no exceptions, periodt π
1.1. Conventions Used in This Document π
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] πΈ these are the official requirement words, so they hold real weight, iykyk π₯
Part 2 is coming next, bestie π«Άπ
2. Motivation β¨
okay so a bunch of apps, both standardized AND proprietary π, use the INFO method the way it was originally defined in RFC 2976 [RFC2976]. we're calling that "legacy INFO usage" π¦ and it's giving main character energy. the big ones include (but aren't limited to):
- RFC 3372 [RFC3372] specifies the encapsulation of ISDN User Part (ISUP) in SIP message bodies. ITU-T and the Third Generation Partnership Project (3GPP) have specified similar procedures. π
- [ECMA-355] specifies the encapsulation of "QSIG" in SIP message bodies. πΈ
- RFC 5022 [RFC5022] specifies how INFO is used as a transport mechanism by the Media Server Control Markup Language (MSCML) protocol. MSCML uses an option-tag in the Require header field to make sure the receiver understands the INFO content. π₯
- RFC 5707 [RFC5707] specifies how INFO is used as a transport mechanism by the Media Server Markup Language (MSML) protocol. π§
- Companies have been using INFO messages to request fast video update. There's now a standardized mechanism for that, based on the Real-time Transport Control Protocol (RTCP), specified in RFC 5168 [RFC5168]. π
- Companies have been using INFO messages to transport Dual-Tone Multi-Frequency (DTMF) tones. All of these mechanisms are proprietary and have not been standardized. π
Some legacy INFO usages are also recognized as shortcuts to more appropriate and flexible mechanisms. β¨
Also, RFC 2976 didn't define any mechanisms that would let a SIP UA say (1) what types of applications and contexts it supports the INFO method for, or (2) what types of applications and contexts a specific INFO message is associated with. π
Because legacy INFO usages don't have associated Info Packages, you can't use the Recv-Info and Info-Package header fields with them. That means a UA can't use the Recv-Info header field to say which legacy INFO usages it's willing to receive INFO requests for, and a UA can't use the Info-Package header field to say which legacy INFO usage an INFO request is tied to. not it π
Because of all that, legacy INFO usages often need static configuration to figure out which types of applications and contexts the UAs support the INFO method for, and how they handle the application information carried in INFO messages. this has caused interoperability problems across the industry. π©
To fix this, the SIP Working Group spent a LOT of discussion time over many years deciding whether it made more sense to fix INFO (by defining a registration mechanism for the ways it's used) or to deprecate it altogether (with the usage described in RFC 3398 [RFC3398] being grandfathered in as the only legitimate usage). getting consensus took serious work, and the people leaning toward full deprecation had to make concessions π«Ά. the final direction was to publish a framework for registering Info Packages, which is what this specification does. π
3. Applicability and Backward Compatibility π
This document defines a method, INFO, for the Session Initiation Protocol (SIP) [RFC3261], plus an Info Package mechanism. It obsoletes RFC 2976 [RFC2976]. For backward compatibility, it also specifies a "legacy" mode of the INFO method that's compatible with the usage previously defined in RFC 2976, which we're calling "legacy INFO Usage". π¦
For backward compatibility purposes, this document does not deprecate legacy INFO usages, and it doesn't force anyone to define Info Packages for them. However:
- A UA MUST NOT insert an Info-Package header field in a legacy INFO request (as described in Section 4.2.1, an INFO request associated with an Info Package always contains an Info-Package header field). π«
- Any new usage MUST use the Info Package mechanism defined in this specification, since it doesn't share the issues associated with legacy INFO usage, and since Info Packages can be registered with IANA. π
- UAs are allowed to enable both legacy INFO usages and Info Package usages as part of the same invite dialog usage. But UAs SHALL NOT mix legacy INFO usages and Info Package usages to transport the same application level information. If possible, UAs SHALL prefer using an Info Package. π
4. The INFO Method π
4.1. General
The INFO method gives you a way to transport application level information that can further enhance a SIP application. Section 8 has more details on which types of applications INFO is appropriate for. π§
This section describes how a UA handles INFO requests and responses, along with the message bodies included in INFO messages. π
4.2. INFO Request π¦
4.2.1. INFO Request Sender
An INFO request can be associated with an Info Package (see Section 5), or with a legacy INFO usage (see Section 2). πΈ
Building the INFO request works the same way as any other non-target refresh request within an existing invite dialog usage, as described in Section 12.2 of RFC 3261. π
When a UA sends an INFO request associated with an Info Package, it MUST include an Info-Package header field that says which Info Package the request is associated with. A specific INFO request can only be used for a single Info Package. π
When a UA sends an INFO request associated with a legacy INFO usage, there's no Info Package associated with the request, so the UA MUST NOT include an Info-Package header field in it. π ββοΈ
The INFO request MUST NOT contain a Recv-Info header field. A UA can only indicate the set of Info Packages it's willing to receive INFO requests for by using the SIP methods (and their responses) listed in Section 5. π₯
A UA MUST NOT send an INFO request outside an invite dialog usage, and MUST NOT send an INFO request for an Info Package inside an invite dialog usage if the remote UA hasn't indicated it's willing to receive that Info Package within that dialog. π«β¨
If a UA gets a 469 (Bad Info Package) response to an INFO request, based on RFC 5057 [RFC5057], that response counts as a Transaction Only failure, and the UA MUST NOT terminate the invite dialog usage. π€π
Because forking can happen, the UA that sends the initial INVITE request MUST be prepared to receive INFO requests from multiple remote UAs during the early dialog phase. On top of that, the UA MUST be prepared to receive different Recv-Info header field values from different remote UAs. π
NOTE: If the User Agent Server (UAS) (the receiver of the initial INVITE request) sends an INFO request right after it has sent the response that creates the dialog, the UAS needs to be ready for the possibility that the INFO request reaches the User Agent Client (UAC) before the dialog-creating response. The UAC might therefore reject it. Also, an INFO request might get rejected because of a race condition, if a UA sends the INFO request at the same time the remote UA sends a new set of Info Packages it's willing to receive INFO requests for. π
4.2.2. INFO Request Receiver
If a UA receives an INFO request associated with an Info Package that the UA hasn't indicated it's willing to receive, the UA MUST send a 469 (Bad Info Package) response (see Section 11.6). That response contains a Recv-Info header field listing the Info Packages the UA is willing to receive INFO requests for. The UA MUST NOT use the response to update the set of Info Packages. It's only there to show the current set. In the terminology of multiple dialog usages [RFC5057], this counts as a Transaction Only failure, and it does not terminate the invite dialog usage. π
If a UA receives an INFO request associated with an Info Package, and the message body part with Content-Disposition "Info-Package" (see Section 4.3.1) has a Multipurpose Internet Mail Extensions (MIME) type that the UA supports but not in the context of that Info Package, it is RECOMMENDED that the UA send a 415 (Unsupported Media Type) response. π
The UA MAY send other error responses, such as Request Failure (4xx), Server Failure (5xx), and Global Failure (6xx), following the error-handling procedures defined in RFC 3261. πΈ
Otherwise, if the INFO request is syntactically correct and well structured, the UA MUST send a 200 (OK) response. π
NOTE: If the application needs to reject the information it received in an INFO request, that has to happen at the application level. The application needs to trigger a new INFO request saying the previously received application data wasn't accepted. Individual Info Package specifications need to describe the details of those procedures. π«Ά
4.2.3. SIP Proxies
Proxies don't need any extra behavior beyond what RFC 3261 describes in order to support INFO. π§
4.3. INFO Message Body π
4.3.1. INFO Request Message Body
The whole point of the INFO request is to carry application level information between SIP UAs. That application information rides in the payload of the INFO request's message body. π
NOTE: An INFO request associated with an Info Package can also include information tied to that Info Package, using Info-Package header field parameters. β¨
If an INFO request associated with an Info Package contains a message body part, that body part is identified by a Content-Disposition header field with the value "Info-Package". The body part can contain a single MIME type, or it can be a multipart [RFC5621] that holds other body parts associated with the Info Package. π¦
UAs MUST support multipart body parts in accordance with RFC 5621. π₯
NOTE: An INFO request can also contain other body parts that make sense within the context of an invite dialog usage but aren't specifically associated with the INFO method and the application concerned. π
When a UA supports a specific Info Package, the UA MUST also support message body MIME types in accordance with that Info Package. That said, per RFC 3261, the UA still indicates the MIME types it supports using the Accept header. π
4.3.2. INFO Response Message Body
A UA MUST NOT include a message body associated with an Info Package in an INFO response. Message bodies associated with Info Packages MUST only be sent in INFO requests. π«
A UA MAY include a message body that isn't associated with an Info Package in an INFO response. πΈ
4.4. Order of Delivery π
The Info Package mechanism doesn't define any delivery order mechanism. Info Packages can rely on the CSeq header field [RFC3261] to detect whether an INFO request arrived out of order. π§
If specific applications need extra mechanisms for order of delivery, those mechanisms and their related procedures get specified as part of the associated Info Package (for example, using sequence numbers within the application data). π
5. Info Packages π
5.1. General
An Info Package specification defines the content and semantics of the information carried in an INFO message associated with an Info Package. The Info Package mechanism gives UAs a way to say which Info Packages they're willing to receive INFO requests for, and which Info Package a specific INFO request is associated with. π¦
5.2. User Agent Behavior π
5.2.1. General
Okay so this bit covers how a UA handles Info Packages, how it uses the Recv-Info header field, and how it acts in re-INVITE rollback situations π
β¨
5.2.2. UA Procedures
Bestie, this is the big one π«Ά A UA that supports the Info Package mechanism MUST indicate, using the Recv-Info header field, the set of Info Packages it's willing to receive INFO requests for in a specific session. A UA can list multiple Info Packages in a single Recv-Info header field, and it can use multiple Recv-Info header fields too. It can also send an empty Recv-Info header field, which just means a header field with no header field values π¦
A UA shares its set of Info Packages during dialog establishment. It can update that set during the invite dialog usage, so it's not locked in forever πΈ
If a UA isn't willing to receive INFO requests for any Info Packages, whether that's during dialog establishment or later on during the invite dialog usage, the UA MUST indicate this by including an empty Recv-Info header field. This tells the other UAs that it still supports the Info Package mechanism, so nobody gets confused π
Example: If a UA has previously indicated Info Packages "foo" and "bar" in a Recv-Info header field, and during the lifetime of the invite dialog usage it wants to say it doesn't want INFO requests for any Info Packages anymore, it sends a message with an empty Recv-Info header field. Simple as that π
Once a UA has sent a message with a Recv-Info header field containing a set of Info Packages, that set stays valid until the UA sends a new Recv-Info header field with a new (or empty) set of Info Packages. Basically the latest one wins β¨
Once a UA has said it's willing to receive INFO requests for a specific Info Package, and a dialog has been established, the UA MUST be prepared to receive INFO requests associated with that Info Package until the UA indicates it's no longer willing to receive them. No ghosting allowed π
For a specific dialog usage, a UA MUST NOT send an INFO request associated with an Info Package until it has received an indication that the remote UA is willing to receive INFO requests for that Info Package, or after the UA has received an indication that the remote UA is no longer willing to receive INFO requests associated with that Info Package. Wait for the green light, periodt π¦π
NOTE: When a UA sends a message that contains aRecv-Infoheader field with a new set of Info Packages it's willing to receive INFO requests for, the remote UA might send an INFO request based on the old set of Info Packages before it gets that message. In this case, the receiver of the INFO requests rejects the INFO request and sends a469 (Bad Info Package)response to it. Timing is everything, bestie π
If a UA indicates multiple Info Packages that provide similar functionality, it isn't possible to indicate a priority order for them, or to say it only wants INFO requests for one of them. It's up to the application logic associated with the Info Packages, and to the particular Info Package specifications, to describe application behavior in those cases π§
For backward compatibility purposes, even if a UA indicates support for the Info Package mechanism, it's still allowed to enable legacy INFO usages. Also, if a UA indicates support for the INFO method using the Allow header field [RFC3261], that does NOT implicitly mean it supports the Info Package mechanism. A UA MUST use the Recv-Info header field in order to indicate that it supports the Info Package mechanism. And even if a UA uses the Recv-Info header field to indicate Info Package support, it still indicates support for the INFO method using the Allow header too. Two different signals, both valid π
This document does not define a SIP option-tag [RFC3261] for the Info Package mechanism. However, an Info Package specification can define an option-tag associated with a specific Info Package, as described in Section 10.6. π
5.2.3. Recv-Info Header Field Rules
Here's the rulebook for when a UA has to include a Recv-Info header field in SIP messages π Section 7.1 lists the SIP methods where a UA can insert a Recv-Info header field in requests and responses.
- The sender of an initial INVITE request MUST include a
Recv-Infoheader field in the initial INVITE request, even if the sender isn't willing to receive INFO requests associated with any Info Package. No exceptions, bestie π - The receiver of a request that contains a
Recv-Infoheader field MUST include aRecv-Infoheader field in a reliable 18x/2xx response to the request, even if the request contains an emptyRecv-Infoheader field, and even if the receiver's header field value hasn't changed since the last time it sent aRecv-Infoheader field. π«Ά - A UA MUST NOT include a
Recv-Infoheader field in a response if the associated request did not contain aRecv-Infoheader field. π ββοΈ
NOTE: Unlike the rules for generating Session Description Protocol (SDP) answers [RFC3264], the receiver of a request isn't restricted to generating its own set of Info Packages as a subset of the Info Package set received in the Info-Package header field of the request. Main character energy, no limits π
As with SDP answers, the receiver can include the same Recv-Info header field value in multiple responses (18x/2xx) for the same INVITE/re-INVITE transaction, but the receiver MUST use the same Recv-Info header field value (if included) in all responses for that same transaction. Consistency is iconic π
5.2.4. Info Package Fallback Rules
If the receiver of a request that contains a Recv-Info header field rejects the request, both the sender and the receiver of the request MUST roll back to the set of Info Packages that was used before the request was sent. This also applies when the receiver of an INVITE/re-INVITE request included a Recv-Info header field in a provisional response but later rejects the request. Undo, undo, undo ππ
NOTE: The dialog state rollback rules for Info Packages might differ from the rules for other types of dialog state information (SDP, target, etc.). Different vibes for different things π
5.3. REGISTER Processing
This document lets a UA insert a Recv-Info header field in a REGISTER request. BUT, a UA SHALL NOT include a header value for a specific Info Package unless that Info Package's specification describes how the header field value shall be interpreted and used by the registrar, e.g., to determine request targets. Don't go freelancing with the registrar π«π§
Rather than using the Recv-Info header field to determine request targets, it is recommended to use more appropriate mechanisms, e.g., based on RFC 3840 [RFC3840]. However, this document does not define a feature tag for the Info Package mechanism, or a mechanism to define feature tags for specific Info Packages. So the better tools exist, just not from this doc πΈ
6. Formal INFO Method Definition π
6.1. INFO Method
This document describes one new SIP method: INFO. This document replaces the definition and registrations found in RFC 2976 [RFC2976]. π
This table expands on Tables 2 and 3 in RFC 3261 [RFC3261]. π
Header field where INFO
--------------------------------------------
Accept R o
Accept 415 o
Accept-Encoding R o
Accept-Encoding 2xx o
Accept-Encoding 415 c
Accept-Language R o
Accept-Language 2xx o
Accept-Language 415 o
Accept-Resource-Priority 2xx,417 o
Alert-Info -
Allow R o
Allow 405 m
Allow r o
Authentication-Info 2xx o
Authorization R o
Call-ID c m
Call-Info o
Contact -
Content-Disposition o
Content-Encoding o
Content-Language o
Content-Length o
Content-Type *
CSeq c m
Date o
Error-Info 3xx-6xx o
Expires -
From c m
Geolocation R o
Geolocation-Error r o
Max-Breadth R -
Max-Forwards R o
MIME-Version o
Min-Expires -
Organization -
Priority R -
Privacy o
Proxy-Authenticate 401 o
Proxy-Authenticate 407 m
Proxy-Authorization R o
Proxy-Require R o
Reason R o
Record-Route R o
Record-Route 2xx,18x o
Referred-By R o
Request-Disposition R o
Require o
Resource-Priority o
Retry-After R -
Retry-After 404,413,480,486 o
Retry-After 500,503 o
Retry-After 600,603 o
Route R o
Security-Client R o
Security-Server 421,494 o
Security-Verify R o
Server r o
Subject R o
Supported R o
Supported 2xx o
Timestamp o
To c m (w/ Tag)
Unsupported 420 o
User-Agent o
Via m
Warning r o
WWW-Authenticate 401 m
WWW-Authenticate 407 oTable 1: Summary of Header Fields πβ¨
7. INFO Header Fields π§
7.1. General π
okay so this table is basically the cheat sheet for Tables 2 and 3 in RFC 3261 [RFC3261] π it shows which header fields show up in which requests and responses, so you can check the vibe at a glance
Header field where proxy ACK BYE CAN INV OPT REG PRA INF MSG UPD
------------------------------------------------------------------
Info-Package R - - - - - - - m* - -
Recv-Info R - - - m - o o - - o
Recv-Info 2xx - - - o** - - o***- - o***
Recv-Info 1xx - - - o** - - - - - -
Recv-Info 469 - - - - - - - m* - -
Recv-Info r - - - o - - o - - o
Header field where SUB NOT RFR
--------------------------------
Info-Package R - - -
Recv-Info R - - -
Recv-Info 2xx - - -
Recv-Info 1xx - - -
Recv-Info 469 - - -
Recv-Info r - - -
Table 2: INFO-Related Header Fieldsthe Info-Package and Recv-Info header fields are not applicable to UAs that only support legacy INFO usages, so if that's you, you can skip them π
* Not applicable to INFO requests and responses associated with legacy INFO usages.
** Mandatory in at least one reliable 18x/2xx response, if sent, to the INVITE request, if the associated INVITE request contained a Recv-Info header field.
*** Mandatory if the associated request contained a Recv-Info header field.
bestie, Section 20 of RFC 3261 says a "mandatory" header field MUST be present in a request, and MUST be understood by the UAS receiving the request. no cap, that part is non-negotiable π₯
7.2. Info-Package Header Field β¨
this document adds "Info-Package" to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 4 is where you'll find the whole Info-Package header field usage story π¦
when you're matching Info Package types from Recv-Info with the ones in the Info-Package header field value, you compare the Info-package-name portion of the Info-package-type portion octet by octet against the Recv-Info header field value. the Info Package name is case sensitive, so "Foo" and "foo" are NOT the same girl π Info-package-param doesn't count in that comparison-checking algorithm at all.
this document doesn't define any values for Info-Package types. the individual Info Package specifications do that part πΈ
7.3. Recv-Info Header Field π
this document adds Recv-Info to the definition of the element "message-header" in the SIP message grammar [RFC3261]. Section 5 walks through how the Recv-Info header field gets used π§
8. Info Package Considerations π
8.1. General π
this section is all about the stuff you should think through before deciding whether an Info Package is the right move for carrying application information in your specific use-case π
8.2. Appropriateness of Info Package Usage π₯
when you're designing an Info Package for application level information exchange, it's important to ask: is signaling, using INFO requests, within a SIP dialog, an appropriate mechanism for the use-case? like, is it genuinely the most reasonable choice, or is it just because "it's easy"? π picking the wrong mechanism for a use-case can cause negative effects in the SIP networks where it's being used, so be honest with yourself here, periodt π
8.3. INFO Request Rate and Volume π
INFO messages are different from a lot of other SIP messages because they carry application information, and the size and rate of INFO messages are directly determined by the application. this can make application information traffic interfere with other traffic on that infrastructure, or self-interfere when the data rates get too high π
there is no default throttling mechanism for INFO requests. apart from SIP session establishment, the number of SIP messages exchanged during the lifetime of a normal SIP session is pretty small β¨
some applications, like the ones sending Dual-Tone Multi-Frequency (DTMF) tones, can generate a burst of up to 20 messages per second. other applications, like constant GPS location updates, could generate a high rate of INFO requests during the lifetime of the invite dialog usage. that's a LOT of messages, bestie π
a designer of an Info Package, and the application that uses it, needs to consider the impact that the size and the rate of the INFO messages have on the network and on other traffic. the reason is that it normally cannot be ensured that INFO messages will be carried over a congestion-controlled transport protocol end-to-end. even if an INFO message is sent over such a transport protocol, a downstream SIP entity might forward the message over a transport protocol that does not provide congestion control π¬
also, SIP messages tend to be relatively small, on the order of 500 Bytes to 32K Bytes. SIP is a poor mechanism for direct exchange of bulk data beyond these limits, especially if the headers plus body exceed the User Datagram Protocol (UDP) MTU [RFC0768]. the appropriate mechanisms for that kind of traffic include the Hypertext Transfer Protocol (HTTP) [RFC2616], the Message Session Relay Protocol (MSRP) [RFC4975], or other media plane data transport mechanisms π¦
RFC 5405 [RFC5405] has additional guidelines for applications using UDP, and it's useful background reading if you want to go deeper πΈ
8.4. Alternative Mechanisms π§
8.4.1. Alternative SIP Signaling Plane Mechanisms π
8.4.1.1. General π
this subsection describes some alternative mechanisms for transporting application information on the SIP signaling plane, using SIP messages β¨
8.4.1.2. SUBSCRIBE/NOTIFY π¦
an alternative for application level interaction is to use subscription-based events [RFC3265] that use the SIP SUBSCRIBE and NOTIFY methods. with that mechanism, a UA requests state information, like keypad presses from a device to an application server, or key-map images from an application server to a device π±
Event Packages [RFC3265] do the job of disambiguating the context of a message for subscription-based events. the Info Package mechanism gives you similar functionality for application information exchange using invite dialog usages [RFC5057] π
here's the difference: an INFO request is always part of an existing invite dialog usage, and it shares that dialog's fate. a SUBSCRIBE request, on the other hand, creates a separate dialog usage [RFC5057], and is normally sent outside an existing dialog usage π
the subscription-based mechanism can be used by SIP entities to receive state information about SIP dialogs and sessions, without requiring those entities to be part of the route set of those dialogs and sessions. iconic behavior π«Ά
as SUBSCRIBE/NOTIFY messages traverse through stateful SIP proxies and back-to-back user agents (B2BUAs), the resource impact caused by the subscription dialogs needs to be considered. the number of subscription dialogs per user also needs to be considered π
just like any other SIP-signaling-plane-based mechanism for transporting application information, SUBSCRIBE/NOTIFY messages can put a significant burden on intermediate SIP entities that are part of the dialog route set but don't have any interest in the application information transported between the end users π
8.4.1.3. MESSAGE π
the MESSAGE method [RFC3428] defines one-time instant message exchange, typically for sending MIME contents for rendering to the user π
8.4.2. Media Plane Mechanisms β
8.4.2.1. General π
in SIP, media plane channels associated with SIP dialogs are established using SIP signaling, but the data exchanged on the media plane channel doesn't traverse SIP signaling intermediates. so if there's going to be a lot of information exchanged, and the SIP signaling intermediaries don't need to examine it, it is recommended to use a media plane mechanism rather than a SIP-signaling-based mechanism π§
a low-latency requirement for exchanging information is one strong indicator for using a media channel. exchanging information through the SIP routing network can introduce hundreds of milliseconds of latency, which is a whole vibe-killer β±οΈπ
8.4.2.2. MRCP π
one mechanism for media plane exchange of application data is the Media Resource Control Protocol (MRCP) [SPEECHSC-MRCPv2]. there, a media plane connection-oriented channel gets established, such as a Transmission Control Protocol (TCP) [RFC0793] or Stream Control Transmission Protocol (SCTP) [RFC4960] stream πΈ
8.4.2.3. MSRP π
MSRP [RFC4975] defines session-based instant messaging as well as bulk file transfer and other such large-volume uses π¦β¨
8.4.3. Non-SIP-Related Mechanisms π¦
another alternative is to use a SIP-independent mechanism, such as HTTP [RFC2616]. in this model, the UA knows about a rendezvous point it can direct HTTP requests to for transferring information. examples include encoding a prompt to retrieve in the SIP Request URI [RFC4240], or encoding a SUBMIT target in a VoiceXML [W3C.REC-voicexml21-20070619] script π«Ά
9. Syntax π
9.1. General π
this section describes the syntax extensions to the ABNF syntax defined in RFC 3261 that the INFO method needs, and it adds definitions for the Info-Package and Recv-Info header fields. the previous sections covered the semantics. the ABNF in this specification conforms to RFC 5234 [RFC5234] π
9.2. ABNF β
INFOm = %x49.4E.46.4F ; INFO in caps
Method =/ INFOm
message-header =/ (Info-Package / Recv-Info) CRLF
Info-Package = "Info-Package" HCOLON Info-package-type
Recv-Info = "Recv-Info" HCOLON [Info-package-list]
Info-package-list = Info-package-type *( COMMA Info-package-type )
Info-package-type = Info-package-name *( SEMI Info-package-param )
Info-package-name = token
Info-package-param = generic-param10. Info Package Requirements π§
10.1. General π
this section gives guidance on how to define an Info Package, and what information needs to exist in an Info Package specification π
if an Info Package needs to extend or modify the behavior described in this document, that behavior MUST be described in the Info Package specification. it's bad practice for Info Package specifications to repeat procedures defined in this document, unless it's needed for clarification or emphasis π ββοΈ
Info Package specifications MUST NOT weaken any behavior designated with "SHOULD" or "MUST" in this specification. however, Info Package specifications MAY strengthen "SHOULD", "MAY", or "RECOMMENDED" requirements to "MUST" if the applications associated with the Info Package require it πͺ
Info Package specifications MUST address the issues defined in the following subsections, or document why an issue is not applicable to the specific Info Package π«Ά
bestie, Section 8.4 describes alternative mechanisms, which you really should consider as part of solving a specific use-case when there's a need to transport application information π₯
10.2. Overall Description π
the Info Package specification MUST contain an overall description of the Info Package: what type of information is carried in INFO requests associated with the Info Package, and what types of applications and functionalities UAs can use the Info Package for πΈ
if the Info Package is defined for a specific application, the Info Package specification MUST state which application UAs can use the Info Package with π
10.3. Applicability π
okay bestie, the spec MUST explain why the Info Package mechanism was picked over some other mechanism for the specific use-case of moving application info between SIP endpoints π¦ it's giving "show your work." Common reasons can be that SIP proxies or back-to-back user agents (B2BUAs) need to see the transported application info (which wouldn't happen if the info rode on a media path π), or that making separate dialogs (subscriptions) just to carry the info isn't feasible.
Section 8 has more on this and walks through alternative mechanisms you should consider for a given use-case β¨
10.4. Info Package Name π
The Info Package specification MUST define an Info Package name. UAs use it as a header field value (like "infoX") to identify the package in the Recv-Info and Info-Package header fields. That header field value MUST conform to the ABNF defined in Section 9.2 π
Info Packages don't support package versioning π Specific message body payloads can carry version info, and the applications tied to the package handle that. But that's outside the scope of the generic Info Package mechanism, so don't count on the mechanism itself for it.
NOTE: Even if an Info Package name contains version numbering (e.g., foo_v2), the Info Package mechanism does not distinguish a version number from the rest of the Info Package name.
10.5. Info Package Parameters πΈ
The Info Package specification MAY define Info Package parameters. These can be used in the Recv-Info or Info-Package header fields, together with the header field value that names the package (see Section 10.4) π§
The specification MUST define the syntax and semantics of the parameters it defines. On top of that, it MUST say whether a given parameter applies only to the Recv-Info header field, only to the Info-Package header field, or to both π
By default, a parameter only applies to the Info Package it was explicitly defined for β¨
Parameters from different Info Packages can share a name, and their semantics are still specific to the package they belong to. Still, when you're naming a parameter, it is RECOMMENDED not to reuse the name of an existing parameter from another Info Package if the semantics differ. Future you will thank you π«Ά
10.6. SIP Option-Tags π¦
The Info Package specification MAY define SIP option-tags, which can be used as described in RFC 3261 β¨
The registration requirements for option-tags are defined in RFC 5727 [RFC5727].
10.7. INFO Message Body Parts π
The Info Package specification MUST define which message body part MIME types are associated with the Info Package. It MUST either define those body parts (syntax, semantics, and MIME type of each one) or refer to other documents that define them π¦
If an Info Package has multiple message body part MIME types associated with it, the specification MUST define whether UAs need to use multipart body parts so they can put several body parts in a single INFO request π
10.8. Info Package Usage Restrictions π§
If there are restrictions on how UAs can use an Info Package, the Info Package specification MUST document them π
Restrictions can cover whether UAs may send overlapping (outstanding) INFO requests for the package, or whether a UA has to wait for the response to a previous INFO request for that same package. They can also cover whether UAs need to support and use other SIP extensions and capabilities when they use the package, and whether there are limits on using the package together with other Info Packages π
The SIP stack might not know about package-specific restrictions, so you can't assume overlapping requests will get rejected. As defined in Section 4.2.2, UAs will normally send a 200 (OK) response to an INFO request. The application logic tied to the Info Package has to handle the situations where UAs don't follow the restrictions π
10.9. Rate of INFO Requests β
If there's a maximum or minimum rate at which UAs can send INFO requests for the Info Package within a dialog, the Info Package specification MUST document the rate values π₯
If the rates can vary, the specification MAY define Info Package parameters that UAs can use to indicate or negotiate the rates. Or, the rate info can live inside the application data carried with the Info Package. Your call, babe πΈ
10.10. Info Package Security Considerations π
If the application info carried in INFO requests for the Info Package needs a certain level of security, the Info Package specification MUST describe the mechanisms UAs need to use to provide it π‘οΈ
If the specification doesn't require any security beyond what the underlying SIP protocol already gives you, it MUST say so explicitly in the specification π
NOTE: In some cases, it may not be sufficient to mandate Transport Layer Security (TLS) [RFC5246] in order to secure the Info Package payload, since intermediaries will have access to the payload, and because beyond the first hop, there is no way to assure subsequent hops will not forward the payload in clear text. The best way to ensure secure transport at the application level is to have the security at the application level. One way of achieving this is to use end-to-end security techniques such as Secure/Multipurpose Internet Mail Extensions (S/MIME) [RFC5751].
10.11. Implementation Details π οΈ
It is strongly RECOMMENDED that the Info Package specification define the procedure for how implementors implement and use the Info Package, or point to other places where implementors can find that info β¨
NOTE: Sometimes an Info Package designer might choose to not reveal the details of an Info Package. However, in order to allow multiple implementations to support the Info Package, Info Package designers are strongly encouraged to provide the implementation details.
10.12. Examples π
It is RECOMMENDED that the Info Package specification provide demonstrative message flow diagrams, paired with complete messages and message descriptions πΈ
Example flows are informative by definition, and they don't replace the normative text π€
11. IANA Considerations π§Ύ
11.1. Update to Registration of SIP INFO Method π
IANA updated the existing registration in the "Methods and Response Codes" registry under "Session Initiation Protocol (SIP) Parameters" from:
Method: INFO
Reference: [RFC2976]to:
Method: INFO
Reference: [RFC6086]11.2. Registration of the Info-Package Header Field π·
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
Header Name: Info-Package
Compact Form: (none)
Reference: [RFC6086]11.3. Registration of the Recv-Info Header Field π
IANA added the following new SIP header field in the "Header Fields" registry under "Session Initiation Protocol (SIP) Parameters".
Header Name: Recv-Info
Compact Form: (none)
Reference: [RFC6086]11.4. Creation of the Info Packages Registry ποΈ
IANA created the following registry under "Session Initiation Protocol (SIP) Parameters":
Info Packages
Note to the reviewer: The policy for review of Info Packages is "Specification Required", as defined in [RFC5226]. This policy was selected because Info Packages re-use an existing mechanism for transport of arbitrary session-associated data within SIP; therefore, new Info Packages do not require the more extensive review required by specifications that make fundamental protocol changes. However, the reviewer is expected to verify that each Info Package registration is in fact consistent with this definition. Changes to the SIP protocol and state machine are outside of the allowable scope for an Info Package and are governed by other procedures including RFC 5727 and its successors, if any.
The following data elements populate the Info Packages Registry.
- Info Package Name: The Info Package Name is a case-sensitive token. In addition, IANA shall not register multiple Info Package names that have identical case-insensitive values.
- Reference: A reference to a specification that describes the Info Package.
The initial population of this table shall be:
Name Reference11.5. Registration of the Info-Package Content-Disposition π
IANA added the following new header field value to the "Mail Content Disposition Values" registry under "Mail Content Disposition Values and Parameters".
Name: info-package
Description: The body contains information associated with an
Info Package
Reference: RFC608611.6. SIP Response Code 469 Registration π«
IANA registered the following new response code in the "Session Initiation Protocol (SIP) Parameters" -- "Response Codes" registry.
Response Code: 469
Default Reason Phrase: Bad Info Package
Reference: RFC608612. Examples π
12.1. Indication of Willingness to Receive INFO Requests for Info Packages π¨
12.1.1. Initial INVITE Request π
The UAC sends an initial INVITE request, where the UAC indicates that it is willing to receive INFO requests for Info Packages P and R.
INVITE sip:bob@example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Recv-Info: P, R
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...The UAS sends a 200 (OK) response back to the UAC, where the UAS indicates that it is willing to receive INFO requests for Info Packages R and T.
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776;
received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 INVITE
Contact: <sip:bob@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...The UAC sends an ACK request.
ACK sip:bob@pc33.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK754
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314159 ACK
Content-Length: 012.1.2. Target Refresh β¨
okay so the UAC sends an UPDATE request inside the invite dialog usage π , and it says (with an empty Recv-Info header field) that it is not willing to receive INFO requests for any Info Packages π ββοΈ
UPDATE sip:bob@pc33.example.com SIP/2.0
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK776
Max-Forwards: 70
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 UPDATE
Recv-Info:
Contact: <sip:alice@pc33.example.com>
Content-Type: application/sdp
Content-Length: ...
...then the UAS replies with a 200 (OK) response back to the UAC π and this time it says it is willing to receive INFO requests for Info Packages R and T π¦
SIP/2.0 200 OK
Via: SIP/2.0/TCP pc33.example.com;branch=z9hG4bK893;
received=192.0.2.1
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710@pc33.example.com
CSeq: 314163 INVITE
Contact: <sip:alice@pc33.example.com>
Recv-Info: R, T
Content-Type: application/sdp
Content-Length: ...
...12.2. INFO Request Associated with Info Package π§
12.2.1. Single Payload πΈ
here the UA sends an INFO request that's associated with Info Package "foo" π
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Bob <sip:bob@example.com>;tag=a6c85cf
From: Alice <sip:alice@example.com>;tag=1928301774
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314333 INFO
Info-Package: foo
Content-type: application/foo
Content-Disposition: Info-Package
Content-length: 24
I am a foo message type12.2.2. Multipart INFO π«Ά
12.2.2.1. Non-Info Package Body Part π
bestie, SIP extensions can sometimes add body part payloads into an INFO request, and that's totally independent of the Info Package π so in this case the Info Package payload gets put into a multipart MIME body, and a Content-Disposition header field shows which body part is linked to the Info Package β¨
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314400 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Length: ...
--theboundary
Content-Type: application/mumble
...
<mumble stuff>
--theboundary
Content-Type: application/foo-x
Content-Disposition: Info-Package
Content-length: 59
I am a foo-x message type, and I belong to Info Package foo
--theboundary--12.2.2.2. Info Package with Multiple Body Parts inside Multipart Body Part π
multiple body part payloads can be tied to one single Info Package π₯ in that case the body parts go inside a multipart MIME body, with a Content-Disposition header field that says which body part belongs to the Info Package π
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314423 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: Info-Package
Content-Length: ...
--theboundary
Content-Type: application/foo-x
Content-length: 59
I am a foo-x message type, and I belong to Info Package foo
<mumble stuff>
--theboundary
Content-Type: application/foo-y
Content-length: 59
I am a foo-y message type, and I belong to Info Package foo
--theboundary--12.2.2.3. Info Package with Single Body Part inside Multipart Body Part π
the body part payload linked to the Info Package can have a Content-Disposition header field value that's not "Info-Package" π so here the body part goes inside a multipart MIME body, and the Content-Disposition header field on the multipart body says which body part belongs to the Info Package π¦
INFO sip:alice@pc33.example.com SIP/2.0
Via: SIP/2.0/UDP 192.0.2.2:5060;branch=z9hG4bKnabcdef
To: Alice <sip:alice@example.net>;tag=1234567
From: Bob <sip:bob@example.com>;tag=abcdefg
Call-Id: a84b4c76e66710@pc33.example.com
CSeq: 314423 INFO
Info-Package: foo
Content-Type: multipart/mixed;boundary="theboundary"
Content-Disposition: Info-Package
Content-Length: ...
--theboundary
Content-Type: application/foo-x
Content-Disposition: icon
Content-length: 59
I am a foo-x message type, and I belong to Info Package foo
--theboundary--13. Security Considerations π
okay this part is SERIOUS bestie π but it's also kind of iconic. by getting rid of multiple usages of INFO messages without proper community review, and by stopping rogue SIP UAs from confusing another UA with unrelated INFO requests on purpose, we expect this document's clarification of INFO to make the Internet safer π‘οΈβ¨ rogue UAs can still send unrelated INFO requests tho π, but this mechanism lets the UAS and other security devices tie INFO requests to the Info Packages that were negotiated for a session π―
if the content of the Info Package payload is private, UAs need to use end-to-end encryption, like S/MIME, so nobody can get into the content π this matters a LOT because INFO transport is likely not end-to-end. it goes through SIP proxies and back-to-back user agents (B2BUAs), and the user might not trust those π¬
the INFO request carries application level information π° which means INFO messages may need a higher level of protection than the underlying SIP dialog signaling. if you don't protect the SIP signaling from eavesdropping or authentication and repudiation attacks (for example by using TLS transport), then the INFO request and its contents are vulnerable too π¨ even with SIP/TLS, any SIP hop along the path from UAC to UAS can view, modify, or intercept INFO requests, the same as with any SIP request π so some applications may need end-to-end encryption of the INFO payload, on top of hop-by-hop protection of the SIP signaling itself, for example π since the application decides how much security it needs, individual Info Packages have to list these requirements π either way, the Info Package mechanism described by this document gives you the tools for secure, end-to-end transport of application data π
one interesting thing about Info Package usage is that you can reuse the same digest-challenge mechanism used for INVITE-based authentication for the INFO request π€― for example, you could use a quality-of-protection (qop) value of authentication with integrity (auth-int) to challenge the request and its body, which stops intermediate devices from modifying the body π ββοΈ BUT (and this is a big but) this assumes the device that knows the credentials for the INVITE challenge is still in the path for the INFO request, or that the far-end UAS knows those credentials π«
14. References π
14.1. Normative References π
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC5621] Camarillo, G., "Message Body Handling in the Session
Initiation Protocol (SIP)", RFC 5621, September 2009.
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process
for the Session Initiation Protocol (SIP) and the Real-
time Applications and Infrastructure Area", BCP 67,
RFC 5727, March 2010.14.2. Informative References π
Okay bestie, these are the "good to know, not required" reads π€ Here's the whole list, copied exactly so every citation still works:
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981.
[RFC2976] Donovan, S., "The SIP INFO Method", RFC 2976,
October 2000.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3398] Camarillo, G., Roach, A., Peterson, J., and L. Ong,
"Integrated Services Digital Network (ISDN) User Part
(ISUP) to Session Initiation Protocol (SIP) Mapping",
RFC 3398, December 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3372] Vemuri, A. and J. Peterson, "Session Initiation Protocol
for Telephones (SIP-T): Context and Architectures",
BCP 63, RFC 3372, September 2002.
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
Event Notification", RFC 3265, June 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC4240] Burger, E., Van Dyke, J., and A. Spitzer, "Basic Network
Media Services with SIP", RFC 4240, December 2005.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC5022] Van Dyke, J., Burger, E., and A. Spitzer, "Media Server
Control Markup Language (MSCML) and Protocol", RFC 5022,
September 2007.
[RFC5057] Sparks, R., "Multiple Dialog Usages in the Session
Initiation Protocol", RFC 5057, November 2007.
[RFC5168] Levin, O., Even, R., and P. Hagendorf, "XML Schema for
Media Control", RFC 5168, March 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines
for Application Designers", BCP 145, RFC 5405,
November 2008.
[RFC5707] Saleem, A., Xin, Y., and G. Sharratt, "Media Server Markup
Language (MSML)", RFC 5707, February 2010.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[W3C.REC-voicexml21-20070619]
Porter, B., Oshry, M., Rehor, K., Auburn, R., Bodell, M.,
Carter, J., Burke, D., Baggia, P., Candell, E., Burnett,
D., McGlashan, S., and A. Lee, "Voice Extensible Markup
Language (VoiceXML) 2.1", World Wide Web Consortium
Recommendation REC-voicexml21-20070619, June 2007,
<http://www.w3.org/TR/2007/REC-voicexml21-20070619>.
[SPEECHSC-MRCPv2]
Burnett, D. and S. Shanmugham, "Media Resource Control
Protocol Version 2 (MRCPv2)", Work in Progress,
November 2010.
[ECMA-355]
"Standard ECMA-355 Corporate Telecommunication Networks -
Tunnelling of QSIG over SIP", ECMA http://
www.ecma-international.org/publications/standards/
Ecma-355.htm, June 2008.Appendix A. Acknowledgements π«Ά
Big shoutout time! β¨ The work here was inspired by twoε pieces (okay, two papers) that got the ball rolling: "The Session Initiation Protocol (SIP) INFO Considered Harmful" (26 December 2002) by Jonathan Rosenberg, and "Packaging and Negotiation of INFO Methods for the Session Initiation Protocol" (15 January 2003) by Dean Willis. Iconic origin story π
So many people helped out with the work and gave input and feedback on this document: Adam Roach, Anders Kristensen, Andrew Allen, Arun Arunachalam, Ben Campbell, Bob Penfield, Bram Verburg, Brian Stucker, Chris Boulton, Christian Stredicke, Cullen Jennings, Dale Worley, Dean Willis, Eric Rescorla, Frank Miller, Gonzalo Camarillo, Gordon Beith, Henry Sinnreich, Inaki Baz Castillo, James Jackson, James Rafferty, Jeroen van Bemmel, Joel Halpern, John Elwell, Jonathan Rosenberg, Juha Heinanen, Keith Drage, Kevin Attard Compagno, Manpreet Singh, Martin Dolly, Mary Barnes, Michael Procter, Paul Kyzivat, Peili Xu, Peter Blatherwick, Raj Jain, Rayees Khan, Robert Sparks, Roland Jesske, Roni Even, Salvatore Loreto, Sam Ganesan, Sanjay Sinha, Spencer Dawkins, Steve Langstaff, Sumit Garg, and Xavier Marjoum πΈ
John Elwell and Francois Audet helped with the QSIG references π§ Francois Audet also wrote the text for the revised abstract β¨ And Keith Drage gave comments and helped immensely with Table 1 π
Arun Arunachalam, Brett Tate, John Elwell, Keith Drage, and Robert Sparks gave valuable feedback during the working group last call process, which got this document ready for publication π¦
Adam Roach, Dean Willis, John Elwell, and Paul Kyzivat gave valuable input to sort out the message body part usage for Info Packages π
Authors' Addresses π
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas, 02420
Finland
EMail: christer.holmberg@ericsson.com
Eric W. Burger
Georgetown University
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Hadriel Kaplan
Acme Packet
100 Crosby Drive
Bedford, MA 01730
USA
EMail: hkaplan@acmepacket.comπ¦ where this page comes from
- ietf: rfc6086 2011-01
- π girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms