STUN/Turn                                                STUN/TURN
Servers          Alice                      Bob          Servers
   |               |                             |               |
   |<--------------|                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Candidate   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |   Discovery   |                             |               |
   |               |                             |               |
   |               |                             |               |
   |-------------->|       INVITE (Offer)        |               |
   |               |---------------------------->|               |
   |               |        183 (Answer)         |-------------->|
   |               |<----------------------------|               |
   |               |  INFO (repeated candidates) |               |
   |               |---------------------------->|               |
   |               |                             |               |
   |               |    INFO (more candidates)   |   Candidate   |
   |               |<----------------------------|               |
   |               |    Connectivity Checks      |               |
   |               |<===========================>|   Discovery   |
   |               |   INFO (more candidates)    |               |
   |               |<----------------------------|               |
   |               |    Connectivity Checks      |<--------------|
   |               |<===========================>|               |
   |               |                             |               |
   |               |          200 OK             |               |
   |               |<----------------------------|               |
   |               |                             |               |
   |               |      5245 SIP re-INVITE     |               |
   |               |---------------------------->|               |
   |               |            200 OK           |               |
   |               |<----------------------------|               |
   |               |                             |               |
   |               |                             |               |
   |               |<======= MEDIA FLOWS =======>|               |
   |               |                             |               |

            

Figure 10: Example - A typical (Half) Trickle ICE exchange with SIP

It is worth reminding that once a single Offer or Answer had been exchanged within a specific dialog, support for Trickle ICE will have been determined. No further use of Half Trickle will therefore be necessary within that same dialog and all subsequent exchanges can use the Full Trickle mode of operation.

6. Considerations for RTP and RTCP multiplexing

The following consideration describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing RTCP candidates.

Handling of the "a=rtcp" attribute [RFC3605] and the "a=rtcp-mux" attribute for RTP/RTCP multiplexing [RFC5761] is already considered in section 4.2. of [I-D.ietf-mmusic-ice-sip-sdp], respectively, as well in [RFC5761] itself. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange in case of RTCP multiplexing.

If the Offerer supports RTP/RTCP multiplexing exclusively as specified in [I-D.ietf-mmusic-mux-exclusive], the procedures in that document apply for the handling of the "a=rtcp-mux-only", "a=rtcp" and the "a=rtcp-mux" attributes.

While a Half Trickle Offerer would have to send an offer compliant to [I-D.ietf-mmusic-ice-sip-sdp] and [RFC5761] including candidates for all components, this flexibility allows a Full Trickle Offerer to initially send only RTP candidates (component 1) if it assumes that RTCP multiplexing is supported by the Answerer. A Full Trickle Offerer would need to start gathering and trickling RTCP candidates (component 2) only after having received an indication in the answer that the answerer unexpectedly does not support RTCP multiplexing.

A Trickle answerer MAY include an "a=rtcp-mux" attribute [RFC5761] in the application/trickle-ice-sdpfrag body it supports and uses RTP and RTCP multiplexing. Trickle answerer MUST follow the guidance on the usage of the "a=rtcp" attribute as given in [I-D.ietf-mmusic-ice-sip-sdp] and Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses RTP and RTCP multiplexing. The Offerer can use this information e.g. for stopping gathering of RTCP candidates and/or for freeing corresponding resources.

This behavior is illustrated by the following example offer that indicates support for RTP and RTCP multiplexing.

      v=0
      o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
      s=
      c=IN IP4 atlanta.example.com
      t=0 0
      a=ice-pwd:777uzjYhagZgasd88fgpdd
      a=ice-ufrag:Yhh8
      m=audio 10000 RTP/AVP 0
      a=mid:1
      a=rtcp-mux
      a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host

            

Once the dialog is established as described in section Section 4.1 the Answerer sends the following INFO message.

      INFO sip:alice@example.com SIP/2.0
      ...
      Info-Package: trickle-ice
      Content-type: application/sdp
      Content-Disposition: Info-Package
      Content-length: ...

      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      m=audio 9 RTP/AVP 0
      a=mid:1
      a=rtcp-mux
      a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host

            

This INFO message indicates that the Answerer supports and uses RTP and RTCP multiplexing as well. This allows the Offerer to omit gathering of RTCP candidates or releasing already gathered RTCP candidates. If the INFO message did not contain the a=rtcp-mux attribute, the Offerer would have to gather RTCP candidates unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for RTP and RTCP multiplexing.

7. Considerations for Media Multiplexing

The following consideration describe options for Trickle-ICE in order to give some guidance to implementors on how trickling can be optimized with respect to providing candidates in case of Media Multiplexing [I-D.ietf-mmusic-sdp-bundle-negotiation]. It is assumed that the reader is familiar with [I-D.ietf-mmusic-sdp-bundle-negotiation].

ICE candidate exchange is already considered in section 11 of [I-D.ietf-mmusic-sdp-bundle-negotiation]. These considerations are still valid for Trickle ICE, however, trickling provides more flexibility for the sequence of candidate exchange, especially in Full Trickle mode.

Except for bundle-only m-lines, a Half Trickle Offerer would have to send an offer with candidates for all bundled m-lines. The additional flexibility, however, allows a Full Trickle Offerer to initially send only candidates for the m-line with the suggested Offerer BUNDLE address.

Latest on receipt of the answer, the Offerer will detect if BUNDLE is supported and if the suggested Offerer BUNDLE address was selected. In this case the Offerer does not need to trickle further candidates for the remaining m-lines in a bundle. However, if BUNDLE is not supported, the Full Trickle Offerer needs to gather and trickle candidates for the remaining m-lines as necessary. If the answerer selects a Offerer BUNDLE address different from suggested Offerer BUNDLE address, the Full Trickle Offerer needs to gather and trickle candidates for the m-line that carries the selected Offerer BUNDLE address.

A Trickle Answerer SHOULD include an "a=group: BUNDLE" attribute [I-D.ietf-mmusic-sdp-bundle-negotiation] in the application/trickle-ice-sdpfrag body if it supports and uses bundling. When doing so, the Answerer MUST include all identification-tags in the same order that is used or will be used in the Answer.

Receipt of this attribute at the Offerer in an INFO request prior to the Answer indicates that the Answerer supports and uses bundling. The Offerer can use this information e.g. for stopping the gathering of candidates for the remaining m-lines in a bundle and/or for freeing corresponding resources.

This behaviour is illustrated by the following example offer that indicates support for Media Multiplexing.

       v=0
       o=alice 2890844526 2890844526 IN IP4 atlanta.example.com
       s=
       c=IN IP4 atlanta.example.com
       t=0 0
       a=group:BUNDLE foo bar
       a=ice-pwd:777uzjYhagZgasd88fgpdd
       a=ice-ufrag:Yhh8
       m=audio 10000 RTP/AVP 0
       a=mid:foo
       a=rtpmap:0 PCMU/8000
       a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid
       m=video 10002 RTP/AVP 31
       a=mid:bar
       a=rtpmap:31 H261/90000
       a=extmap 1 urn:ietf:params:rtp-hdrext:sdes:mid

            

Once the dialog is established as described in section Section 4.1 the Answerer sends the following INFO message.

      INFO sip:alice@example.com SIP/2.0
      ...
      Info-Package: trickle-ice
      Content-type: application/sdp
      Content-Disposition: Info-Package
      Content-length: ...

      a=group:BUNDLE foo bar
      a=ice-pwd:asd88fgpdd777uzjYhagZg
      a=ice-ufrag:8hhY
      m=audio 9 RTP/AVP 0
      a=mid:1
      a=rtcp-mux
      a=candidate:1 1 UDP 1658497328 192.168.100.33 5000 typ host
      m=audio 9 RTP/AVP 0
      a=mid:bar


            

This INFO message indicates that the Answerer supports and uses Media Multiplexing as well. Note, that the second m-line shows the default values as specified in section Section 4.2, e.g. media set 'audio' although 'video' was offered. The receiving ICE agents needs to ignore these default values in the pseudo m-lines.

The INFO message also indicates that the Answerer accepted the suggested Offerer Bundle Address. This allows the Offerer to omit gathering of RTP and RTCP candidates for the other m-lines or releasing already gathered candidates. If the INFO message did not contain the a=group:BUNDLE attribute, the Offerer would have to gather RTP and RTCP candidates for the other m-lines unless it wants to wait until receipt of an Answer that eventually confirms support or non-support for Media Multiplexing.

Independent of using Full Trickle or Half Trickle mode, the rules from [I-D.ietf-mmusic-sdp-mux-attributes] apply to both, Offerer and Answerer, when putting attributes in the application/trickle-ice-sdpfrag body.

8. SDP 'end-of-candidate' Attribute

This section defines a new SDP media-level and session-level attribute [RFC4566] 'end-of-candidate'. 'end-of-candidate' is a property attribute [RFC4566], and hence has no value. By including this attribute in an Offer or Answer the sending agent indicates that it will not trickle further candidates. The detailed SDP Offer/Answer procedures for the 'end-of-candidate' attribute are specified in [I-D.ietf-ice-trickle].

• Name: end-of-candidate
• Value: N/A
• Usage Level: media and session-level
• Charset Dependent: no
• Mux Category: IDENTICAL
• Example: a=end-of-candidate

9. Content Type 'application/trickle-ice-sdpfrag'

9.1. Overall Description

A application/trickle-ice-sdpfrag body is used by the Trickle-ICE Info Package. It uses a subset of the possible SDP lines as defined by the grammar defined in [RFC4566]. A valid body uses only media descriptions and certain attributes that are needed and/or useful for trickling candidates. The content adheres to the following grammar.

9.2. Grammar

The grammar of an 'application/trickle-ice-sdpfrag' body is based the following ABNF [RFC5234]. It specifies the subset of existing SDP attributes, that are needed or useful for trickling candidates.

      ;  Syntax
      trickle-ice-sdpfrag =   session-level-fields
                        pseudo-media-descriptions
      session-level-fields = [bundle-group-attribute CRLF]
                        [ice-lite-attribute CRLF]
                        ice-pwd-attribute CRLF
                        ice-ufrag-attribute CRLF
                        [ice-options-attribute CRLF]
                        [ice-pacing-attribute CRLF]
                        [end-of-candidates-attribute CRLF]
                        extension-attribute-fields
                              ; for future extensions

      ice-lite-attribute     = %s"a=" ice-lite
      ice-pwd-attribute      = %s"a=" ice-pwd-att
      ice-ufrag-attribute    = %s"a=" ice-ufrag-att
      ice-pacing-attribute  =    %s"a="  ice-pacing-att
      ice-options-attribute  =    %s"a="  ice-options
      bundle-group-attribute = "a=group:" bundle-semantics
                                 *(SP identification-tag)
      bundle-semantics = "BUNDLE"
      end-of-candidates-attribute  = %s"a=" end-of-candidates
      extension-attribute-fields   = attribute-fields

      pseudo-media-descriptions    =  *( media-field
                                 trickle-ice-attribute-fields
                                [extension-attribute-fields] )
                                    ; for future extensions
      trickle-ice-attribute-fields =  mid-attribute CRLF
                              ["a=rtcp-mux" CRLF]
                              ["a=rtcp-mux-only" CRLF]
                              *(candidate-attributes CRLF)
                              [ice-pwd-attribute CRLF]
                              [ice-ufrag-attribute CRLF]
                              [remote-candidate-attribute CRLF]
                              [end-of-candidates-attribute CRLF]
      remote-candidate-attribute   = %s"a=" remote-candidate-att
      candidate-attributes         = %s"a=" candidate-attribute
      end-of-candidates            = %s"end-of-candidates"
         

with ice-lite, ice-pwd-att, remote-candidate-att, ice-ufrag-att, ice-pacing-att, ice-options, candidate-attribute remote-candidate-att from [I-D.ietf-mmusic-ice-sip-sdp], identification-tag, mid-attribute ; from [RFC5888], media-field, attribute-fields from [RFC4566]. The indicator for case-sensitivity %s is defined in [RFC7405].

An Agent MUST ignore any received unknown extension-attribute-fields.

10. Info Package

10.1. Rationale - Why INFO?

The decision to use SIP INFO requests as a candidate transport method is based primarily on their lightweight nature. Once a dialog has been established, INFO messages can be exchanged both ways with no restrictions on timing and frequency and no risk of collision.

On the other hand, using Offer/Answer and UPDATE requests [RFC3311] introduces the following complications:

Blocking of messages:

[RFC3264] defines Offer/Answer as a strictly sequential mechanism. There can only be a maximum of one exchange at any point of time. Both sides cannot simultaneously send Offers nor can they generate multiple Offers prior to receiving an Answer. Using UPDATE requests for candidate transport would therefore imply the implementation of a candidate pool at every agent where candidates can be stored until it is once again that agent's "turn" to emit an Answer or a new Offer. Such an approach would introduce non-negligible complexity for no additional value.

Elevated risk of glare:

The sequential nature of Offer/Answer also makes it impossible for both sides to send Offers simultaneously. What's worse is that there are no mechanisms in SIP to actually prevent that. [RFC3261], where the situation of Offers crossing on the wire is described as "glare", only defines a procedure for addressing the issue after it has occurred. According to that procedure both Offers are invalidated and both sides need to retry the negotiation after a period between 0 and 4 seconds. The high likelihood for glare to occur and the average two second back-off intervals would imply Trickle ICE processing duration would not only fail to improve but actually exceed those of Vanilla ICE.

INFO messages decouple the exchange of candidates from the Offer/Answer negotiation and are subject to none of the glare issues described above, which makes them a very convenient and lightweight mechanism for asynchronous delivery of candidates.

Using in-dialog INFO messages also provides a way of guaranteeing that candidates are delivered end-to-end, between the same entities that are actually in the process of initiating a session. Out-of-dialog alternatives would have implied requiring support for Globally Routable UA URI (GRUU) [RFC5627] which, given GRUUs relatively low adoption levels, would have constituted too strong of constraint to the adoption of Trickle ICE.

10.2. Overall Description

This specification defines an Info Package for use by SIP user agents implementing Trickle ICE. INFO requests carry ICE candidates discovered after the peer user agents have confirmed mutual support for Trickle ICE.

10.3. Applicability

The purpose of the ICE protocol is to establish a media path in the presence of NAT and firewalls. The candidates are transported in INFO requests and are part of this establishment.

Candidates sent by a Trickle ICE agent after the Offer, follow the same signaling path and reach the same entity as the Offer itself. While it is true that GRUUs can be used to achieve this, one of the goals of this specification is to allow operation of Trickle ICE in as many environments as possible including those without GRUU support. Using out-of-dialog SUBSCRIBE/NOTIFY requests would not satisfy this goal.

10.4. Info Package Name

This document defines a SIP Info Package as per [RFC6086]. The Info Package token name for this package is "trickle-ice"

10.5. Info Package Parameters

This document does not define any Info Package parameters.

10.6. SIP Option Tags

[RFC6086] allows Info Package specifications to define SIP option-tags. This specification extends the option-tag construct of the SIP grammar as follows:

 option-tag /= "trickle-ice"
           

SIP entities that support this specification MUST place the 'trickle-ice' option-tag in a SIP Supported: header field within all SIP INVITE requests and responses.

When responding to, or generating a SIP OPTIONS request a SIP entity MUST also include the 'trickle-ice' option-tag in a SIP Supported: header field.

10.7. Info Message Body Parts

Entities implementing this specification MUST include a payload of type 'application/trickle-ice-sdpfrag' as defined in Section 9.2 all SIP INFO requests. The payload is used to convey SDP encoded ICE candidates.

10.8. Info Package Usage Restrictions

This document does not define any Info Package Usage Restrictions.

10.9. Rate of INFO Requests

A Trickle ICE Agent with many network interfaces might create a high rate of INFO requests if every newly detected candidate is trickled individually without aggregation. Implementor that are concerned about loss of packets in such a case might consider aggregating ICE candidates and sending INFOS only at some configurable intervals.

10.10. Info Package Security Considerations

See Section 12

11. IANA Considerations

[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this document. Please replace "I-D.ietf-ice-trickle" with the RFC number of that document.]

11.1. SDP 'end-of-candidate' Attribute

This section defines a new SDP media-level and session-level attribute [RFC4566] , 'end-of-candidate'. 'end-of-candidate' is a property attribute [RFC4566] , and hence has no value.

      
  Name: end-of-candidate

   Value: N/A

   Usage Level: media and session

   Charset Dependent: no

   Purpose: The sender indicates that it will not trickle
            further candidates.

   O/A Procedures: "I-D.ietf-ice-trickle" defines the detailed
                   SDP Offer/Answer procedures for
                   the 'end-of-candidate' attribute.

   Mux Category: IDENTICAL

   Reference: RFCXXXX

   Example:

   a=end-of-candidate
      
      

11.2. application/trickle-ice-sdpfrag MIME Type

• Type name: application
• Subtype name: trickle-ice-sdpfrag
• Required parameters: None.
• Optional parameters: None.
• Encoding considerations:
• • SDP files are primarily UTF-8 format text. Although the initially defined content of a trickle-ice-sdpfrag body does only include ASCII characters, UTF-8 encoded content might be introduced via extension attributes. The "a=charset:" attribute may be used to signal the presence of other character sets in certain parts of a trickle-ice-sdpfrag body (see [RFC4566]). Arbitrary binary content cannot be directly represented in SDP or a trickle-ice-sdpfrag body.
• Security considerations:
• • See [RFC4566]) and RFCXXXX
• Interoperability considerations:
• • See RFCXXXX
• Published specification:
• • See RFCXXXX
• Applications which use this media type:
• • Voice over IP, video teleconferencing, streaming media, instant messaging, Trickle-ICE among others.
• Additional information:
• Magic number(s): none
• File extension(s): none
• Macintosh File Type Code(s): none
• Person and email address to contact for further information:
• • IETF MMUSIC working group mmusic@ietf.org
• Intended usage:
• • Trickle-ICE for SIP as specified in RFCXXXX.
• Author/Change controller:
• • IETF MMUSIC working group mmusic@ietf.org

11.3. SIP Info Package 'trickle-ice'

This document defines a new SIP Info Package named 'trickle-ice' and updates the Info Packages Registry with the following entry.

    +-------------+-----------+
    | Name        | Reference |
    +-------------+-----------+
    | trickle-ice | [RFCXXXX] |
    |             |           |
    +-------------+-----------+

              

11.4. SIP Option Tag 'trickle-ice'

This specification registers a new SIP option tag 'trickle-ice' as per the guidelines in Section 27.1 of [RFC3261] and updates the "Option Tags" section of the SIP Parameter Registry with the following entry:

    +-------------+-------------------------------------+-----------+
    | Name        | Description                         | Reference |
    +-------------+-------------------------------------+-----------+
    | trickle-ice | This option tag is used to indicate | [RFCXXXX] |
    |             | that a UA supports and understands  |           |
    |             | Trickle-ICE.                        |           |
    +-------------+-------------------------------------+-----------+

                

12. Security Considerations

The Security Considerations of [I-D.ietf-mmusic-ice-sip-sdp], [RFC6086], [I-D.ietf-ice-trickle] apply. This document clarifies how the above specifications are used together for trickling candidates and does not create addtitional security risks.

13. Acknowledgements

The authors would like to thank Ayush Jain, Paul Kyzivat, Jonathan Lennox, Simon Perreault and Martin Thomson for reviewing and/or making various suggestions for improvements and optimizations.

14. Change Log

[RFC EDITOR NOTE: Please remove this section when publishing].

Changes from draft-ietf-mmusic-trickle-ice-sip-01

• Editorial Clean up
• IANA Consideration added
• Security Consideration added
• RTCP and BUNDLE Consideration added with rules for including "a=rtcp-mux" and "a=group: BUNDLLE" attributes
• 3PCC Consideration added
• Clarified that 18x w/o answer is sufficient to create a dialog that allows for trickling to start
• Added remaining Info Package definition sections as outlined in section 10 of [RFC6086]
• Added definition of application/sdpfrag making draft-ivov-mmusic-sdpfrag obsolete
• Added pseudo m-lines as additional separator in sdpfrag bodies for Trickle ICE
• Added ABNF for sdp-frag bodies and Trickle-ICE package

Changes from draft-ietf-mmusic-trickle-ice-sip-02

• Removed definition of application/sdpfrag
• Replaced with new type application/trickle-ice-sdpfrag
• RTCP and BUNDLE Consideration enhanced with some examples
• draft-ietf-mmusic-sdp-bundle-negotiation and RFC5761 changed to normative reference
• Removed reference to 4566bis
• Addressed review comment from Simon Perreault

Changes from draft-ietf-mmusic-trickle-ice-sip-03

• replaced reference to RFC5245 with draft-ietf-mmusic-rfc5245bis and draft-ietf-mmusic-ice-sip-sdp
• Corrected Figure 10, credits to Ayush Jain for finding the bug
• Referencing a=rtcp and a=rtcp-mux handling from draft-ietf-mmusic-ice-sip-sdp
• Referencing a=rtcp-mux-exclusive handling from draft-ietf-mmusic-mux-exclusive, enahnced ABNF to support a=rtcp-mux-exclusive
• Clarifying that draft-ietf-mmusic-sdp-mux-attributes applies for the application/trickle-ice-sdpfrag body

Changes from draft-ietf-mmusic-trickle-ice-sip-04

• considered comments from Christer Holmberg
• corrected grammar for INFO package, such that ice-ufrag/pwd are also allowed on media-level as specified in [I-D.ietf-mmusic-ice-sip-sdp]
• Added new ice-pacing-attribute fom [I-D.ietf-mmusic-ice-sip-sdp]
• Added formal definition for the end-of-candidates attribute

Changes from draft-ietf-mmusic-trickle-ice-sip-05

• considered further comments from Christer Holmberg
• editorial comments on section 3 addressed
• moved section 3.1 to section 10.1 and applied some edits
• replaced the term "previously sent candidates" with "currently known and used candidates".

15. References

15.1. Normative References

[I-D.ietf-ice-trickle]	Ivov, E., Rescorla, E., Uberti, J. and P. Saint-Andre, "Trickle ICE: Incremental Provisioning of Candidates for the Interactive Connectivity Establishment (ICE) Protocol", Internet-Draft draft-ietf-ice-trickle-04, September 2016.
[I-D.ietf-mmusic-ice-sip-sdp]	Petit-Huguenin, M., Keranen, A. and S. Nandakumar, "Using Interactive Connectivity Establishment (ICE) with Session Description Protocol (SDP) offer/answer and Session Initiation Protocol (SIP)", Internet-Draft draft-ietf-mmusic-ice-sip-sdp-10, July 2016.
[I-D.ietf-mmusic-mux-exclusive]	Holmberg, C., "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", Internet-Draft draft-ietf-mmusic-mux-exclusive-10, August 2016.
[I-D.ietf-mmusic-rfc5245bis]	Keranen, A. and J. Rosenberg, "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal", Internet-Draft draft-ietf-mmusic-rfc5245bis-05, September 2015.
[I-D.ietf-mmusic-sdp-bundle-negotiation]	Holmberg, C., Alvestrand, H. and C. Jennings, "Negotiating Media Multiplexing Using the Session Description Protocol (SDP)", Internet-Draft draft-ietf-mmusic-sdp-bundle-negotiation-36, October 2016.
[I-D.ietf-mmusic-sdp-mux-attributes]	Nandakumar, S., "A Framework for SDP Attributes when Multiplexing", Internet-Draft draft-ietf-mmusic-sdp-mux-attributes-14, September 2016.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC3261]	Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002.
[RFC3262]	Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002.
[RFC3264]	Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002.
[RFC3605]	Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, DOI 10.17487/RFC3605, October 2003.
[RFC4566]	Handley, M., Jacobson, V. and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006.
[RFC5234]	Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008.
[RFC5761]	Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, DOI 10.17487/RFC5761, April 2010.
[RFC5888]	Camarillo, G. and H. Schulzrinne, "The Session Description Protocol (SDP) Grouping Framework", RFC 5888, DOI 10.17487/RFC5888, June 2010.
[RFC6086]	Holmberg, C., Burger, E. and H. Kaplan, "Session Initiation Protocol (SIP) INFO Method and Package Framework", RFC 6086, DOI 10.17487/RFC6086, January 2011.
[RFC7405]	Kyzivat, P., "Case-Sensitive String Support in ABNF", RFC 7405, DOI 10.17487/RFC7405, December 2014.

15.2. Informative References

[RFC3311]	Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 2002.
[RFC3840]	Rosenberg, J., Schulzrinne, H. and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, DOI 10.17487/RFC3840, August 2004.
[RFC5627]	Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009.
[RFC6120]	Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011.
[RFC7081]	Ivov, E., Saint-Andre, P. and E. Marocco, "CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)", RFC 7081, DOI 10.17487/RFC7081, November 2013.

Authors' Addresses