| DISPATCH | Shi Tao. Li |
| Internet-Draft | Huawei Technologies |
| Intended status: Standards Track | December 07, 2012 |
| Expires: June 10, 2013 |
SIP signalling for ICE trickling
draft-li-dispatch-ice-trickling-signalling-00
Trickle ICE is a mechanism that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. This document gives several solutions for trickle ICE with SIP protocol.
Discussion and suggestions for improvement are requested, and should be sent to dispatch@ietf.org.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 10, 2013.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:/⁠/⁠trustee.ietf.org/⁠license-⁠info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Trickle ICE is a mechanism that allows ICE agents to send and receive candidates incrementally rather than exchanging complete lists. The purpose of this mechanism is to reduce session establishment times, and trickle ICE had already been included in XMPP Jingle [XEP-0176] and it has been used in rtcweb.
[I-D.rescorla-mmusic-ice-trickle] describes the basic mechanism about trickle ICE. And this document illustrates several possible methods that can be used for trickle ICE with SIP protocol.
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 [RFC2119].
The general descirption about trickle ICE as described in [I-D.rescorla-mmusic-ice-trickle] is that the initiator first include an initial ICE description (such as ICE credentials and host candidates)in their Offers. Answerers in this situation MAY send their ICE description at any point after receiving that of the offerer. After sending an ICE description each agent can continue exchanging of additional candidates
This method complies the SDP Offer/Answer model as described in RFC3264. After the first SDP O/A exchange for the initial ICE description, each side can start to send the SIP UPDATE request which contains the newly collected candidats.
STUN STUN
server Alice Bob Server
| |F1 1NVITE(SDP offer) | |
| | ICE host candidate | |
| discovery | -----------------> | |
| <------------ | | discovery |
| | |---------> |
| new cands |F2 18x response(SDP answer) | |
| ---------> | ICE host candidate | |
| | <-------------------- | new cands |
| | | <------- |
| |F3 UPDATE(SDP offer) | |
| | new candidates | |
| | --------------------> | |
| | | |
| | | |
| new cands |F4 200 OK to UPDATE | |
| ---------> |SDP answer(new candidates | |
| | may has) | |
| | <-------------------- | |
| | | |
| |F5 UPDATE(SDP offer) | |
| | new candidates | |
| | (only can send when F4 has | |
| | received) | |
| | --------------------> | |
| | | |
| | | |
|<-----T1------>|<-------------T2------------>|<---T1---->|
Figure 1: Using UPDATE request for ICE trickling
As described above, each side can start to send the SIP UPDATE request which contains the newly collected candidats after the first SDP O/A exchange. This may cause the "glare" problem as described in RFC3264. In SIP protocol, as specified in RFC3261, when "glare" problem happened, the user agent MUST return a 491 (Request Pending) response, then waits for the timer to expire, so it can start to send another new UPDATE request. Although the "glare" problem can be sloved, it will increase the session setup times.
Another issue for the UPDATE method is that, for example, if Alice wants to send another UPDATE request (message F5 in Figure 1) to carry another new candidats, she has to wait until the SDP answer in SIP 200 OK for the previous UPDATE request (message F4 in figure 1) has received from BOb. This does not completely comply with the trickle ICE mechanism, because, trickle ICE requires the participants to send the additional candidates as soon as the new candidate has been collected.
Assuming the candidate collecting time is T1, message transfer time from Alice to Bob is T2, and T1 smaller than 2*T2.
For the best case, without glare happened:
The fastest time for Bob to receive the first additional candidates information (messsage F3 in Figure1) after received the first SIP INVITE request (message F1 in Figure 1)is 2*T2.
The fast time for Alice to receive the first additional candidates information (message F4 in Figure 1)after received the first response message (message F2 in Figure1)is 2*T2.
Using UPDATE method, in some cases, may has some effect to reduce the session establichment, but in most cases, it can not guarantee it works, for example, when "glare" happened.
This method use SIP INFO message to carry the additional candidates. Either side can start to send the SIP INFO message without any collision problem.
STUN STUN
server Alice Bob Server
| |F1 1NVITE(SDP offer) | |
| | ICE host candidate | |
| discovery | -----------------> | |
| <------------ | | discovery |
| | |---------> |
| new cands |F2 18x response(SDP answer) | |
| ---------> | ICE host candidate | |
| | <-------------------- | new cands |
| | | <------- |
| |F3 INFO(package for | |
| | new candidates ) | |
| | --------------------> | |
| | | |
| |F4 200 OK to INFO | |
| | <-------------------- | |
| | | |
| |F5 INFO(package for | |
| | new candidates ) | |
| | <-------------------- | |
| | | |
| |F6 200 OK to INFO | |
| | --------------------> | |
| | | |
|<-----T1------>|<-------------T2------------>|<---T1---->|
Figure 2: Using INFO request for ICE trickling
Using SIP INFO method to carry additional candidates needs to define a new info package as described in RFC6086.
The issue for INFO method is that, INFO message has to use the existing SIP dialog, that is to say, as the caller, Alice can not send the INFO message(message F3 in FIgure 2) until the first response has recived from Bob(message F2 in Figure 2). When the first response from Bob has received, Alice can start to send INFO message any time it needed. At Bob side, it can send the INFO message just after it send out the first response.
Using INFO method, only the candidiates information needs to be exchanged between the two participants.
The only delay for session setup using INFO method is at the caller side, and only for the first INFO message. The other procedures comply the trickle ICE mechanism.
Assuming the candidate collecting time is T1, message transfer time from Alice to Bob is T2, and T1 smaller than 2*T2.
For most cases, the fastest time for Bob to receive the first additional candidates information (messsage F3 in Figure 2) after received the first SIP INVITE request (message F1 in Figure 2)is 2*T2.
The fast time for Alice to receive the first additional candidates information (message F5 in Figure 2)after received the first response message (message F2 in Figure 2)is T1+T2-T2=T1.
Using INFO method can reduce the session establishment times, has better effect than using UPDATE method.
SUBSCRIBE/NOTIFY method is similar to the Presence service, each side has to implement a trickle AS. One participant has to subscribe to the trickle AS that belong to another participant.
At one side, whenever it collects a new candidate, it uses PUBLISH message to send the new candidates to its trickle AS, the trickle AS will then send a NOTIFY message that also contain the new candidates to the other side.
STUN Alice Bob STUN
server Alice trickle AS trickle AS Bob Server
| | | | | |
| |F1 1NVITE (SDP offer) ICE host candidate| |
|discovery | --------------------------------------> | |
|<---------| | | |discovery|
| | | | |-------> |
| |F2 18x response(SDP answer) | |
| | ICE host candidate | |
| | <-------------------------------------- | |
| | |F3 SUBSCRIBE | |
| | | event=trickle | |
| | | <---------------------- | |
| | | | | |
| | |F4 200 OK to SUBSCRIBE | |
| | | ----------------------> | |
| | F5 SUBSCRIBE | | |
| | event=trickle | | |
| | ----------------------> | | |
| | | | | |
| | F6 200 OK to SUBSCRIBE | | |
| | <---------------------- | | |
| new cands| | | | |
| -------> |F7 PUBLISH | | | |
| | (new cands) | | | |
| | ------------>| | | |
| |F8 200 OK | | | |
| |<----------- | | | |
| | |F9 NOTIFY (new cands) | |
| | | ----------------------> | |
| | |F10 200 OK | |
| | | <---------------------- | |
| | | | |new cands|
| | | | F11 PUBLISH |<------- |
| | | | (new cands) | |
| | | | <----------- | |
| | | | F12 200 OK | |
| | | | -----------> | |
| | F13 NOTIFY (new cands) | | |
| | <---------------------- | | |
| | F14 200 OK | | |
| | ----------------------> | | |
| | | | | |
| |<-----T4----->| |<----T4------>| |
| |<-----------------T2-------------------->| |
|<---T1--->|<------------T3---------->| |<---T1-->|
| | |<------------T3---------->| |
Figure 3: Using SUBSCRIBE/NOTIFY for ICE trickling
Using SUBSCRIBE/NOTIFY method needs to define a new subscribe event package as described in RFC3265.
At the callee side, Bob can start to send SUBSCRIBE request (message F3 in Figure 3) when the first SIP INVITE request has received (message F1 in FIgure 3), the request-URI of the SUBSCRIBE request contains the AOR of Alice, and the event header field contains the new value "trickle", the SUBSCRIBE request will route to the trickle AS of Alice. Whenever Bob has collected a new candidate, it can send a PUBLISH request(message 11 in Figure 3) which contain the new candidate to its own trickle AS. When Bob trickle AS has received the SUBSCRIBE request from Alice(message F5 in Figure 3), it can start to send the NOTIFY request to Alice which including the new candidate information of Bob. (message F13 in Figure 3).
At the caller side, if Alice has already known that Bob supports trickle ICE before the call, Alice can send the SUBSCRIBE request (message F5 in Figure 3) just after send out the first SIP INVITE request, if Alice does know whether Bob supports trickle ICE before the call, she has to wait until it has received the first response from Bob(message F2 in Figure 3). Alice can send the PUBLISH request (message F7 in Figure 3)which contain the additional candidate to its trickle AS only after the first SIP INVITE requset(message F1 in Figure 3) has sent out.
Assuming that the candidate collecting time is T1, message transfer time from Alice to Bob is T2, and T1 smaller than 2*T2, message transfer time from Alice to Bob trickle AS and the time from Bob to Alice trickle AS is T3, obviously T3 smaller than T2. The time from Alice to Alice trickle AS and the time from Bob to Bob trickle AS is T4, but it can be ignored.
If Alice has already known that Bob supports trickle ICE before the call:
The fastest time for Bob to receive the first additional candidates information (messsage F9 in Figure 3) after received the first SIP INVITE request (message F1 in Figure 3)is happened at the case that when F7 sends after F1, and arrives at Alice trickle AS before F3, so the fastest time is 2*T3.
The fast time for Alice to receive the first additional candidates information (message F13 in Figure 3)after received the first response message (message F2 in Figure 3)is happened at the case that when Alice send SUBSCRIBE request (F5) after F1, and do not need to wait F2, so the fastest time is T2+T1+T4+T3-2*T2=T1.
If Alice does know whether Bob suppost trickle ICE before the call:
The fastest time for Bob to receive the first additional candidates information (messsage F9 in Figure 3) after received the first SIP INVITE request (message F1 in Figure 3)is also 2*T3,
The fast time for Alice to receive the first additional candidates information (message F13 in Figure 3)after received the first response message (message F2 in Figure 3)is happened at the case that when Alice sends F5 only when F2 has received, and knows that Bob support trickle ICE, so the fastest time is "2*T3" when F11 arrives befer F5(T2+T1+T4+T3+(T2+T3-(T1+T4))-2*T2=2*T3), or "T1" when F5 arrives before F11(T2+T1+T4+T3-2*T2=T1).
For the SUBSCRIBE/NOTIFY method, the effect to reduce session setup time is better than using INFO method, because PUBLISH request can be sent in a seperate dialog. However, this method also has some issues if one participant is involved in multiple calls. Then there would be multiple subscriptions to the trickle event. And the trickle AS would somehow need to figure out which subscriber should receive a particular published candidate.
This section lists some criterions for comparison for the above three methods.
+----------------+---------------+-------------+------------------+
| | UPDATE method | INFO method | SUBSCRIBE/NOTIFY |
+----------------+---------------+-------------+------------------+
| Using SDP O/A | Yes | No | No |
| | | | |
+----------------+---------------+-------------+------------------+
|initiator can | | | |
|send new cands | | | |
|only when first | Yes | Yes | No |
|answer has | | | |
|received from | | | |
|the remote side | | | |
+----------------+---------------+-------------+------------------+
| glare issue | Yes | No | No |
| | | | |
+----------------+---------------+-------------+------------------+
|inforamtion |All the SDP |Only new |Only new cands |
|exchange |information has|cands infor |infor needs to |
| |to exchange |needs to |exchange |
| | |exchange | |
+----------------+---------------+-------------+------------------+
|needs to wait | | | |
|the answer | | | |
|so another new | Yes | No | No |
|cands can be | | | |
|send | | | |
| | | | |
+----------------+---------------+-------------+------------------+
| new parameter | | Yes | YES |
| needed | No |(new info |(new event) |
| | | package) | |
+----------------+---------------+-------------+------------------+
|more signalling |less signalling| need more | need more |
| |added |signalling |signalling than |
| | |than UPDATe | INFO method |
| | |method | |
+----------------+---------------+-------------+------------------+
|effect of | | | |
|increasing the |Not too much |better than | better then INFO |
|setup time | |UPDATE | |
+----------------+---------------+-------------+------------------+
|multiple call | | | |
|interworking | No | No | Yes |
|problem | | | |
+----------------+---------------+-------------+------------------+
Table 1: methods comparison
To do
Needed if INFO method or SUBSCRIBE/NOTIFY method has been chosen as the final method.
Thanks to Paul Kyzivat for providing useful comments to the document.