Subject: [MMUSIC] Questions on ICE-lite procedure

From: David Hancock <[email-masked]>
Date: Thu, 30 Jun 2011 20:19:15 -0600

I have a question on the RFC5245 ICE-lite procedures (three questions actually, inline below).

Consider the case where two SIP endpoints, UA-1 and UA-2, are both dual stack. The endpoints support ICE-lite to negotiate media IP version during session establishment. UA-1 and UA-2 have the following locally configured ICE-lite policies…

UA-1:
- Default candidate is IPv4
- Preferred IP version when selecting valid candidate pair is IPv6

UA-2
- Default candidate is IPv6
- Preferred IP version when selecting valid candidate pair is IPv4

Here’s the call establishment message flow (for simplicity, shows candidates only for RTP component).

UA-1                             UA-2
-----                            -----
   [1]INVITE  SDP-offer --->
         c= IPv4 addr-1
         m = IPv4 port-1
         a=ice-lite
         a=candidate-1 IPv4 addr1
         a=candidate-2 IPv6 addr1

(all IP addresses in [1] are host addresses on UA-1)

   [2] 183-Progress SDP-preview <---
         c=IPv6 addr-2
         m = IPv6 port-2
         a=ice-lite
         a=candidate-1 IPv6 addr-2
         a=candidate-2 IPv4 addr-2
(all IP addresses in [2] are host addresses on UA-2)

UA-1 and UA 2 now pair the local and remote candidates, and come up with two candidate pairs; an IPv4 pair and an IPv6 pair.

Once the candidate pairs have been created, UA-1 and UA-2 then independently select a valid candidate pair. Based on their locally configured policy settings, UA-1 selects the IPv6 pair, while UA-2 selects the IPv4 pair. Both UAs listen for media on both candidate pairs, but send media only on their selected/valid candidate pairs. Therefore, the early-media media stream is asymmetrical w.r.t. IP version.

------ early media via IPv6 ------->
<----- early media via IPv4 -------

Question-1: ICE-lite doesn’t explicitly describe this early-media behavior, but should it be expected to work as shown above?

Eventually, the call is answered. SDP is same as in [2].

   [3] 200OK SDP-answer <---
         c=IPv6 addr-2
         m = IPv6 port-2
         a=ice-lite
         a=candidate-1 IPv6 addr-2
         a=candidate-2 IPv4 addr-2

   [4]ACK --->

UA-1, in its ICE-lite role as controlling agent, sends updated offer to UA-2, based on the following text in section 8.2.2.

      *  To reconcile this, the controlling agent MUST send an updated
         offer as described in Section 9.1.3, which will include the
         remote-candidates attribute.

      *  The agent MUST NOT update the state of ICE processing when the
         offer is sent.  If this subsequent offer completes, the
         controlling agent MUST change the state of ICE processing to
         Completed for all media streams, and the state of ICE
         processing overall to Completed.  The states for the controlled
         agent are set based on the logic in Section 9.2.3.

Section 9.1.3 has two subsections; 9.1.3.1 when ICE is running, and 9.1.3.2 when ICE is completed. The 2nd bullet above indicates that at this stage ICE is still running, which means do 9.1.3.1. However, 9.1.3.1 sends the exact same SDP-offer that was sent back in message [1], with no remote-candidate attribute. I think the correct procedure at this point is 9.1.3.2, since it updates the default candidate in the SDP offer to indicate what candidate pair was selected by UA-1, and includes the remote-candidate attribute.

Question-2: Is this an error in the RFC? If not, how does this subsequent offer/answer tell the controlled agent to start using the candidate pair selected by the controlling agent? Or is it the intention of this procedure to simply let the controlled and controlling agents use different candidates for the established session (as they were during early media)?

I *think* the offer/answer should look like this (i.e., should follow procedure in section 9.1.3.2)…

   [5] INVITE SDP offer --->
         c= IPv6 addr-1
         m = IPv6 port-1
         a=ice-lite
         a=candidate-1 IPv4 addr1
         a=candidate-2 IPv6 addr1
         a=remote-candidate IPv6 addr-2

Per RFC5245 section 9.2.3, UA-2 sets its remote candidate to the default destination (c= line) received in the SDP offer, and its local candidate equal to the remote candidate received in the SDP offer. It then adds this candidate pair to its valid candidate list, and generates an SDP answer based on this valid candidate.

   [6] 200OK SDP answer <---
         c= IPv6 addr-2
         m = IPv6 port-2
         a=ice-lite
         a=candidate-1 IPv6 addr-2
         a=candidate-2 IPv4 addr-2
         a=remote-candidate IPv6 addr-1

   [7]ACK --->

If the above is correct (i.e., compliant with RFC5245) then I think ICE-lite procedure ensures that the established media stream is symmetrical in send/receive direction w.r.t. IP version.

Question-3: Does the ICE-lite procedure in fact guarantee IP version symmetry in the established (not early) media streams?

Thanks
David