Subject: [MMUSIC] ice-sip-sdp-19: Flemming's comment on Section 3.2.5 on ICE Mismatch

From: Suhas Nandakumar <[email-masked]>
Date: Mon, 2 Apr 2018 10:56:34 -0700

Hi Flemming

Moving the discussion in a separate thread to keep it focussed. How about
following rewording of the section 3.2.5.

3.2.5 <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-3.2.5>.
Verifying ICE Support

   The agents will proceed with the ICE procedures defined in [ICE-BIS
<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#ref-ICE-BIS>]
   and this specification if, for each data stream in the SDP it
   received, the default destination for each component of that data
   stream appears in a candidate attribute.  For example, in the case of
   RTP, the IP address and port in the "c=" and "m=" lines,
   respectively, appear in a candidate attribute and the value in the
   rtcp attribute appears in a candidate attribute.

   If this condition is not met, the agents MUST process the SDP based on
   normal [RFC3264 <https://tools.ietf.org/html/rfc3264>] procedures,
without using any of the ICE mechanisms
   described in the remainder of this specification with the following
   exceptions:

   1.  An controlled/responding agent MUST follow the rules of

       section 11 of [ICE-BIS
<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#ref-ICE-BIS>],
which describe keepalive procedures

       for all agents. Also, If the default candidates were relayed

       candidates learned through a TURN server, the controlled agent

       MUST create permissions in the TURN server for the IP addresses

       learned from its peer in the offer SDP it just received.

       If this is not done, initial packets in the data stream from the

       peer may be lost.

   2.  On the other hand, if the controlled agent is not proceeding

       with ICE because there were a=candidate attributes, but none that

       matched the default destination of the data stream, it MUST include

       an a=ice-mismatch attribute in its answer and MAY omit a=candidate
       attributes for such data streams.  See Section 9.2.2
<https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-9.2.2>
for a
       discussion of cases where this can happen. This specification provides

       no guidance on how an controlled agent should proceed in such a

       failure case.

Cheers
Suhas

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 2 Apr 2018 19:45:53 -0400

I'm still having a hard time following this - let me try and elaborate 
below

On 4/2/18 1:56 PM, Suhas Nandakumar wrote:
> Hi Flemming
>
> Moving the discussion in a separate thread to keep it focussed. How 
> about following rewording of the section 3.2.5.
>
>
>         3.2.5
>         <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-3.2.5>.
>         Verifying ICE Support
>
>
>
So far so good.
>     normal [RFC3264 <https://tools.ietf.org/html/rfc3264>] procedures, without using any of the ICE mechanisms
Ok, so at this point, there is mismatch between at least one default 
destination in a component and all of its corresponding candidate 
attributes. The above says to do normal offer/answer instead of ICE, 
except as follows:

> <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#ref-ICE-BIS>], which describe keepalive procedures
>         for all agents.
Earlier, the document says the answerer acts as the responding agent, 
and the controlling/controlled roles are determined by ICE procedures. 
Here you seem to say responding = controlled. In any case, it must mean 
we are dealing with the answerer (which would be easiser to understand 
from an O/A point of view which is the perspective this documenet should 
have to the extent possible).

So it says, the answer will still follow the keep-alive procedures, but 
we are not doing ICE. I'm not quite sure what that means, but I'm 
guessing it means we must stop sending keepalives if we were previously 
sending them (since the ICE session is terminated).
> Also, If the default candidates were relayed
Here it's not entirely clear whether this is a rule for the offerer or 
the answerer:
1) Answerer
The default candidates were present in the offer and apparently they are 
marked as relayed candidates. However, since the text refers to 
controlled, per the above, this cannot be test for the answerer.

2) Offerer
This must be an answer SDP that came back to us, however the text 
clearly talks about the offer SDP.

I'm confused at this point.

>         attributes for such data streams.
Above you said this list was supposed to be exceptions to this rule, but 
this is the rule itself repeated !?

Let me know if I am missing something here (but in either case, we need 
to make the write-up clearer).

Thanks

-- Flemming

>   SeeSection 9.2.2 
> <https://tools.ietf..org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-9.2.2>  for a
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 3 Apr 2018 00:29:15 -0700

Hello Flemming

  The original text was take from RFC5245 sections
https://tools.ietf.org/html/rfc5245#section-5.1 and 6.1 where it is defines
procedures for answerer and the offerer for verifying ice support. The
versions pre 13 for the current ice-sip-sdp had the exact same content.

Wondering if we should get back to the original format since it seems to be
more clearer in explaining ?

Thanks
Suhas

On Mon, Apr 2, 2018 at 4:45 PM, Flemming Andreasen <[email-masked]>
wrote:

>   3.2.5 <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-3.2.5>.  Verifying ICE Support
>
>    The agents will proceed with the ICE procedures defined in [ICE-BIS <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#ref-ICE-BIS>]
> attributes. The above says to do normal offer/answer instead of ICE, except
> as follows:
>
>        section 11 of [ICE-BIS <https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-19#ref-ICE-BIS>], which describe keepalive procedures
>
>        for all agents.
>
> Earlier, the document says the answerer acts as the responding agent, and
> the controlling/controlled roles are determined by ICE procedures. Here you
> seem to say responding = controlled. In any case, it must mean we are
> dealing with the answerer (which would be easiser to understand from an O/A
> point of view which is the perspective this documenet should have to the
> extent possible).
>
> So it says, the answer will still follow the keep-alive procedures, but we
> are not doing ICE. I'm not quite sure what that means, but I'm guessing it
> means we must stop sending keepalives if we were previously sending them
> (since the ICE session is terminated).
>
> Here it's not entirely clear whether this is a rule for the offerer or the
> answerer:
> 1) Answerer
> marked as relayed candidates. However, since the text refers to controlled,
> per the above, this cannot be test for the answerer.
>
> 2) Offerer
> This must be an answer SDP that came back to us, however the text clearly
> talks about the offer SDP.
>
> Let me know if I am missing something here (but in either case, we need to
> make the write-up clearer).
>
>
> Thanks
>
> -- Flemming
>
>  See Section 9.2.2 <https://tools.ietf..org/html/draft-ietf-mmusic-ice-sip-sdp-19#section-9.2.2> for a
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 3 Apr 2018 21:24:08 -0700

Hello Flemming

On Tue, Apr 3, 2018 at 12:29 AM, Suhas Nandakumar <[email-masked]>
wrote:

> Hello Flemming
>
>   The original text was take from RFC5245 sections https://tools.ietf.
> org/html/rfc5245#section-5.1 and 6.1 where it is defines procedures for
> answerer and the offerer for verifying ice support. The versions pre 13 for
> the current ice-sip-sdp had the exact same content.
>
> Wondering if we should get back to the original format since it seems to
> be more clearer in explaining ?
>

Any thoughts on this proposal ? please let me know

>> we are not doing ICE. I'm not quite sure what that means, but I'm guessing
>> it means we must stop sending keepalives if we were previously sending them

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2018 01:15:50 -0400

Hi Suhas,

On Wed, Apr 4, 2018 at 12:24 AM, Suhas Nandakumar <[email-masked]>
wrote:

>>   The original text was take from RFC5245 sections https://tools.ietf.or
>> g/html/rfc5245#section-5.1 and 6.1 where it is defines procedures for

Original text in https://tools.ietf.org/html/rfc5245#section-5.1 should be
updated to accommodate the following two issues :

1. rtcp attribute is now optional
2. ICE implementation MAY choose to ignore ICE mismatch and not examine
address in c= line and rtcp attribute

Regards,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Wed, 4 Apr 2018 00:43:45 -0700

Hello Roman

Thanks for the inputs, Have a clarification question inline

On Tue, Apr 3, 2018 at 10:15 PM, Roman Shpount <[email-masked]> wrote:

> Original text in https://tools.ietf.org/html/rfc5245#section-5.1 should
> be updated to accommodate the following two issues :
>

[Suhas] On 2, we need to say exactly the behavior here. If answers sets the
ice-mismatch in multiple m=lines (not all) and offer decides to ignore some
but not others might lead to confusing interpretations. RFC5245 made it
clear that offerer's handling of ice-mismatch is outside the scope.
I tend to incline with that as well. What are your thoughts ?

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 4 Apr 2018 09:12:57 -0400

On 4/3/18 3:29 AM, Suhas Nandakumar wrote:
> https://tools.ietf.org/html/rfc5245#section-5.1
RFC 5245 Section 5.1 describes answerer procedures and says:
<quote>
5.1.  Verifying ICE Support

    The agent will proceed with the ICE procedures defined in this
    specification if, for each media stream in the SDP it received, the
    default destination for each component of that media stream appears
    in a candidate attribute.  For example, in the case of RTP, the IP
    address and port in the c and m lines, respectively, appear in a
    candidate attribute and the value in the rtcp attribute appears in a
    candidate attribute.

    If this condition is not met, the agent MUST process the SDP based on
    normal RFC 3264 procedures, without using any of the ICE mechanisms
    described in the remainder of this specification with the following
    exceptions:

    1.  The agent MUST follow the rules of Section 10, which describe
        keepalive procedures for all agents.

    2.  If the agent is not proceeding with ICE because there were
        a=candidate attributes, but none that matched the default
        destination of the media stream, the agent MUST include an a=ice-
        mismatch attribute in its answer.

    3.  If the default candidates were relayed candidates learned through
        a TURN server, the agent MUST create permissions in the TURN
        server for the IP addresses learned from its peer in the SDP it
        just received.  If this is not done, initial packets in the media
        stream from the peer may be lost.
<quote>

Everything up to bullet 2 looks good. Bullet 3 is unclear to me:
- Which default candidates are we referring to ?
- If they were from the offer SDP, then how can the answerer create 
permissions in the offerer's TURN server ?
- I guess that means we are actually talking about the answerers default 
candidates, which seems like a somewhat convoluted way of saying that if 
the answerer is using a TURN server for its media stream, then it needs 
to create permissions for whatever the default candidate is in the offer 
SDP (whether relayed or not), or am I missing something ? In either 
case, some clarification is needed here.

> and 6.1 where it is defines procedures for answerer and the offerer 
> for verifying ice support.
RFC 5245 Section 6.1 looks good to me.
> The versions pre 13 for the current ice-sip-sdp had the exact same 
> content.
>
> Wondering if we should get back to the original format since it seems 
> to be more clearer in explaining ?
>
I think so (modulo the above).

Thanks

-- Flemming

>
> Thanks
> Suhas
>
>
> On Mon, Apr 2, 2018 at 4:45 PM, Flemming Andreasen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     I'm still having a hard time following this - let me try and
>     elaborate below
>
>>     Moving the discussion in a separate thread to keep it focussed.
>>     How about following rewording of the section 3.2.5.
>>
>>
>>             3.2.5
>     Ok, so at this point, there is mismatch between at least one
>     default destination in a component and all of its corresponding
>     candidate attributes. The above says to do normal offer/answer
>     instead of ICE, except as follows:
>
>     Earlier, the document says the answerer acts as the responding
>     agent, and the controlling/controlled roles are determined by ICE
>     procedures. Here you seem to say responding = controlled. In any
>     case, it must mean we are dealing with the answerer (which would
>     be easiser to understand from an O/A point of view which is the
>     perspective this documenet should have to the extent possible).
>
>     So it says, the answer will still follow the keep-alive
>     procedures, but we are not doing ICE. I'm not quite sure what that
>     means, but I'm guessing it means we must stop sending keepalives
>     if we were previously sending them (since the ICE session is
>     terminated).
>     Here it's not entirely clear whether this is a rule for the
>     offerer or the answerer:
>     1) Answerer
>     The default candidates were present in the offer and apparently
>     they are marked as relayed candidates. However, since the text
>     refers to controlled, per the above, this cannot be test for the
>     answerer.
>
>     2) Offerer
>     Above you said this list was supposed to be exceptions to this
>     rule, but this is the rule itself repeated !?
>
>     Let me know if I am missing something here (but in either case, we
>     need to make the write-up clearer).
>
>
>     Thanks
>
>     -- Flemming
>
>>       SeeSection 9.2.2
>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>

---

From: Flemming Andreasen <[email-masked]>
Date: Wed, 4 Apr 2018 09:13:39 -0400

On 4/4/18 3:43 AM, Suhas Nandakumar wrote:
> On Tue, Apr 3, 2018 at 10:15 PM, Roman Shpount <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Suhas,
>
>     On Wed, Apr 4, 2018 at 12:24 AM, Suhas Nandakumar
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         On Tue, Apr 3, 2018 at 12:29 AM, Suhas Nandakumar
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             <https://tools.ietf.org/html/rfc5245#section-5.1> and 6.1
>             where it is defines procedures for answerer and the
>             offerer for verifying ice support. The versions pre 13 for
>             Wondering if we should get back to the original format
>             since it seems to be more clearer in explaining ?
>
>
>
>     Original text in https://tools.ietf.org/html/rfc5245#section-5.1
>     <https://tools.ietf.org/html/rfc5245#section-5.1> should be
>     2. ICE implementation MAY choose to ignore ICE mismatch and not
>     examine address in c= line and rtcp attribute
>
>
> [Suhas] On 2, we need to say exactly the behavior here. If answers 
> sets the ice-mismatch in multiple m=lines (not all) and offer decides 
> to ignore some
> but not others might lead to confusing interpretations. RFC5245 made 
> it clear that offerer's handling of ice-mismatch is outside the scope.
Seems reasonable.

-- Flemming

---

From: Roman Shpount <[email-masked]>
Date: Wed, 4 Apr 2018 15:40:50 -0400

Hi All,

I think I need to try to provide some background to this section of the
specification.

First of all, address provided in c= line and port in m= line together with
address in rctp SDP attribute (or address from c= line and port from m=
line +1) are refereed to as default candidates. These are the addresses
which will be used if answering end point would not understand ICE and RFC
3264 procedures were used.

Section 5.1 of RFC 5245 is there in order to support SIP ALG or SIP aware
firewalls (which are evil -- https://wiki.freeswitch.org/wiki/ALG). The
assumption in this section is if the SIP ALG is present and modified the
session description, ICE nomination should not happen and addresses from
default candidates should be used. Also, in order to indicate to the
offerer that this happened, ice-mismatch attribute needs to be added the
answer, so that offerer will not follow ICE nomination procedures and use
RFC 3264 procedures as well.

In practice following this guidance is typically the worst thing that you
can do. Procedure which is the most likely to succeed is to add
address/ports from c=/m= line and rtcp SDP attribute to the list of
candidates, if they are not already there and proceed with ICE nomination.
Do not insert ice-mismatch in the answer in order not to confuse the
offerer. This way, if SIP ALG works, then ICE nomination process will
verify the addresses that SIP ALG inserted. If SIP ALG is broken (as it
almost always is), then correct candidate will be picked via the normal ICE
process.

Even better option is to use secure communications channel for signaling
and make sure SDP is not modified by ALG.

Furthermore, a fair number of implementations (including some WebRTC and
trickle ice), insert c=IN IP4 0.0.0.0 and port 9 in m= line even when ICE
candidates are present. Based on the RFC5245 text this causes ICE mismatch.

To conclude, at the very least, I would suggest making the whole procedure
of matching candidates to addresses in c= and m= lines and rtcp SDP
attribute optional so that devices which do not do this are still
compliant. Better yet, add default candidates to candidate list, if these
addresses did not match any of the candidates and do not send ice-mismatch,
since it is more likely to succeed.

Answering some of the Flemming's questions:

Default candidates in the offer. Default candidates are candidates defined
in c= and m= lines of SDP and in rtcp SDP attribute i.e. default
destination for this m= line if this end point was not ICE aware and RFC
3264 procedures were used. See
https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-20#section-2

If answerer's default candidates are TURN candidates, then answerer MUST
create permissions in the answerer's TURN server for the IP addresses from
offer default candidates. The intent there is that answerer will
communicate through answerer's TURN server with addressees/ports in c= and
m= line and rtcp attribute from the offer.

- I guess that means we are actually talking about the answerers default
candidates, which seems like a somewhat convoluted way of saying that if
the answerer is using a TURN server for its media stream, then it needs to
create permissions for whatever the default candidate is in the offer SDP
(whether relayed or not), or am I missing something ? In either case, some
clarification is needed here.

Yes. You are correct and clarification is needed.

Regards,
_____________
Roman Shpount