Subject: [MMUSIC] draft-ice-sip-sdp: ICE Mismatch Considerations

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 26 Apr 2018 11:26:48 -0700

Hello All

  Flemming, Roman and myself met this morning to discuss the path forward
with ICE mismatch changes for ice-sip-sdp draft.

@flemming/@roman please feel free to correct if I have messed up somethings
:-)

Context:
------------
  Current version of the draft says, if the answerer finds that IP Address
in c= and port in m line doesn't match any of the candidates for a given m
section. the answerer MUST insert an ice-mismatch attribute and default to
RFC3264 procedures. Also the offerer's handling of ice-mismatch is
application dependent. [This was written this way in RFC5245 when dealing
with ALGs modifying the SDP in transit]

Roman's Observations:
-------------------------------
1. Above requirement is too restrictive given the current deployments of
ALGs where if the Answerer treated the new IP and port it found in C= and m
lines as candidates it learnt (say peer reflexive over signaling channel),
the ICE process may continue and even succeed. In these cases, it makes
more sense to not  include a=ice-mismatch attribute in the answer.

2. WebRTC implementations today populate IP (0.0.0.0/::) and port (9) when
trickling and the current draft text has implication to call such offers as
ice-mismatch.

Proposed Direction
-------------------------

Answerer Behavior:

If IP in C= attribute is one of [0.0.0.0/::] and port is 9, don't treat it
as ice-mismatch and continue normal processing.

When the Answerer sees IP in C= and port in m line that doesn't match any
of the candidates, treat it as a new candidate that it learnt via signaling
and continue normal ICE processing.  OTOH if the answerer isn't one such
implementation or does't want to do so, then it MUST insert a=ice-mismatch
and default to RFC3264 procedures.

Look forward for your inputs in making progress on this draft.

Cheers
Suhas Nandakumar

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 26 Apr 2018 18:38:20 +0000

Hi,

Shouldn’t the trickle case (0.0.0.0:9) be described in the trickle draft?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Suhas Nandakumar
Sent: 26 April 2018 20:27
To: mmusic WG <[email-masked]>
Subject: [MMUSIC] draft-ice-sip-sdp: ICE Mismatch Considerations

Hello All

  Flemming, Roman and myself met this morning to discuss the path forward with ICE mismatch changes for ice-sip-sdp draft.

@flemming/@roman please feel free to correct if I have messed up somethings :-)

Context:
------------
  Current version of the draft says, if the answerer finds that IP Address in c= and port in m line doesn't match any of the candidates for a given m section. the answerer MUST insert an ice-mismatch attribute and default to RFC3264 procedures. Also the offerer's handling of ice-mismatch is application dependent. [This was written this way in RFC5245 when dealing with ALGs modifying the SDP in transit]

Roman's Observations:
-------------------------------
1. Above requirement is too restrictive given the current deployments of ALGs where if the Answerer treated the new IP and port it found in C= and m lines as candidates it learnt (say peer reflexive over signaling channel), the ICE process may continue and even succeed. In these cases, it makes more sense to not  include a=ice-mismatch attribute in the answer.

2. WebRTC implementations today populate IP (0.0.0.0/:<http://0.0.0.0/:>:) and port (9) when trickling and the current draft text has implication to call such offers as ice-mismatch.

Proposed Direction

Answerer Behavior:

If IP in C= attribute is one of [0.0.0.0/:<http://0.0.0.0/:>:] and port is 9, don't treat it as ice-mismatch and continue normal processing.

When the Answerer sees IP in C= and port in m line that doesn't match any of the candidates, treat it as a new candidate that it learnt via signaling and continue normal ICE processing.  OTOH if the answerer isn't one such implementation or does't want to do so, then it MUST insert a=ice-mismatch and default to RFC3264 procedures.

Cheers
Suhas Nandakumar

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 26 Apr 2018 19:51:00 +0000

Hi Christer

 Please see in-line

> Shouldn’t the trickle case (0.0.0.0:9) be described in the trickle draft?

Trickle defines it , but the idea was not to call such thing as ice
mismatch in this draft.

>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Suhas
> Nandakumar
> *Sent:* 26 April 2018 20:27
> *To:* mmusic WG <[email-masked]>
> *Subject:* [MMUSIC] draft-ice-sip-sdp: ICE Mismatch Considerations
>
>
>
> Hello All
>
>
>
> 2. WebRTC implementations today populate IP (0.0.0.0/::) and port (9)
> when trickling and the current draft text has implication to call such
> offers as ice-mismatch.
>
>
>
>
>
> Proposed Direction
>
> If IP in C= attribute is one of [0.0.0.0/::] and port is 9, don't treat
> it as ice-mismatch and continue normal processing.
>
>
>
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Sat, 28 Apr 2018 17:07:27 -0700

Hello All

   Wondering if its fine to make changes to the draft based on the above ?

Please let me know

Cheers
Suhas

On Thu, Apr 26, 2018 at 12:51 PM, Suhas Nandakumar <[email-masked]>
wrote:

>>   Current version of the draft says, if the answerer finds that IP
>> Address in c= and port in m line doesn't match any of the candidates for a
>> given m section. the answerer MUST insert an ice-mismatch attribute and
>> default to RFC3264 procedures. Also the offerer's handling of ice-mismatch
>> is application dependent. [This was written this way in RFC5245 when
>> dealing with ALGs modifying the SDP in transit]
>>
>>
>>
>> Roman's Observations:
>>