Trickle ICE with a non-trickle peer

[SteveG]

Hi,

Could someone clarify the correct behaviour for Chrome when it receives an offer from a peer that does not support trickle-ice?

If I look at the trickle standard it seems to say that if an offer is received that does not include a=ice-options-trickle then the answerer MUST adopt vanilla ICE behaviour.

  When an agent receives an initial offer, it will first check if the

 offer or offerer indicates support for Trickle ICE as explained in
 Section 3.  If this is not the case, the agent MUST process the offer
 according to Vanilla ICE procedures [rfc5245bis]

I take this to mean it will gather all candidates before sending answer.  However, the actual behaviour I see is that for an aduio+video call Chrome will send an answer with a candidate for audio, but with the video stream advertised as port 9 and 0 candidates.

Is this a bug?  I notice chrome does not appear to be advertising a=ice-options:trickle either, so maybe there are updates to trickle coming? 

Cheers,

Steve

[Emil Ivov]

Hey there,

On 19.02.16 г. 10:52, SteveG wrote:
> Hi,
>
> Could someone clarify the correct behaviour for Chrome when it receives
> an offer from a peer that does not support trickle-ice?
>
> If I look at the trickle standard it seems to say that if an offer is
> received that does not include a=ice-options-trickle then the answerer
> MUST adopt vanilla ICE behaviour.
>
> When an agent receives an initial offer, it will first check if the
>
> offer or offerer indicates support for Trickle ICE as explained in

> Section 3 <https://tools.ietf.org/html/draft-ietf-ice-trickle-01#section-3>. If this is not the case, the agent MUST process the offer

> according to Vanilla ICE procedures [rfc5245bis

> <https://tools.ietf.org/html/draft-ietf-ice-trickle-01#ref-rfc5245bis>]

>
>
> I take this to mean it will gather all candidates before sending answer.
> However, the actual behaviour I see is that for an aduio+video call
> Chrome will send an answer with a candidate for audio, but with the
> video stream advertised as port 9 and 0 candidates.
>
> Is this a bug? I notice chrome does not appear to be advertising
> a=ice-options:trickle either, so maybe there are updates to trickle coming?

Actually sending the answer is up to the JavaScript application, so it
simply needs to wait for gathering to complete and then send the answer
to the non-trickle peer.

Hope this helps,
Emil
>
> Cheers,
> Steve
>
> --
>
> ---
> You received this message because you are subscribed to the Google
> Groups "discuss-webrtc" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to discuss-webrt...@googlegroups.com
> <mailto:discuss-webrt...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/discuss-webrtc/57aa79ab-5f39-4f71-932d-fcb3cab7eeea%40googlegroups.com
> <https://groups.google.com/d/msgid/discuss-webrtc/57aa79ab-5f39-4f71-932d-fcb3cab7eeea%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

--
https://jitsi.org

[Steve Gibbard]

Hi,

Thanks for the response.  

The issue we have is a BUNDLE answer from chrome is sending all ice candidates for the audio port (expected), but for the video stream (which is part of the bundle) it is sending port 9 (rather than audio port) and 0 candidates (rather than the candidates associated with the audio port).  As if it is trying to adhere to trickle procedures.

Is it up to the application to munge the SDP and reflect the audio port against the video m line, or should the media layer be returning a candidate for the video stream that reflects the audio port/candidates.

Back in M46 we were seeing the bundle port reflected in both streams of the answer:

Answer sdp (paraphrased)

a=group:BUNDLE audio video 

m=audio 52195 UDP/TLS/RTP/SAVPF 0 8

c=IN IP4 10.198.29.163

a=rtcp:9 IN IP4 0.0.0.0

a=candidate:2467227523 1 udp 2122260223 10.128.99.163 52195 typ host generation 0

a=candidate:3717012339 1 tcp 1518280447 10.128.99.163 0 typ host tcptype active generation 0

a=ice-ufrag:oPBhPbLYsI3JLejL

a=ice-pwd:hwiUVq2lElI8RUCksULQsPm0

m=video 52195 UDP/TLS/RTP/SAVPF 100 116 117 96

c=IN IP4 10.198.29.163

a=rtcp:9 IN IP4 0.0.0.0

a=candidate:2467227523 1 udp 2122260223 10.128.99.163 52195 typ host generation 0

a=candidate:3717012339 1 tcp 1518280447 10.128.99.163 0 typ host tcptype active generation 0

a=ice-ufrag:oPBhPbLYsI3JLejL

a=ice-pwd:hwiUVq2lElI8RUCksULQsPm0

Now I see the audio with a port, but video with port 9 (as if trickle is used):

a=group:BUNDLE audio video 

m=audio 52195 UDP/TLS/RTP/SAVPF 0 8

c=IN IP4 10.198.29.163

a=rtcp:9 IN IP4 0.0.0.0

a=candidate:2467227523 1 udp 2122260223 10.128.99.163 52195 typ host generation 0

a=candidate:3717012339 1 tcp 1518280447 10.128.99.163 0 typ host tcptype active generation 0

a=ice-ufrag:oPBhPbLYsI3JLejL

a=ice-pwd:hwiUVq2lElI8RUCksULQsPm0

m=video 9 UDP/TLS/RTP/SAVPF 100 116 117 96

c=IN IP4 0.0.0.0

a=rtcp:9 IN IP4 0.0.0.0

I'm not ruling out this is the app layer, rather than chrome, that has changed but want to make sure I understand where the responsibility lies.  

To me the answer should not act as if tribckle is being used since all candidates are gathered for the audio port and bundle is accepted.

Steve

--

--- You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/A0PkRro-EDU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/56C75106.2090402%40jitsi.org.

[Taylor Brandstetter]

Ah. This was a side effect of some refactoring done a while back. If BUNDLE is negotiated, Chrome no longer duplicates the candidates in every m= section. The assumption was that a BUNDLE-aware endpoint would only care about the transport-related attributes (such as a=candidate) in the m= section associated with the BUNDLE-tag.

The current BUNDLE draft actually does require duplicating the candidates, but there's ongoing discussion in MMUSIC about changing this. If you have some reasons why the candidates should always be duplicated, by all means let your concerns be heard.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAE26g8EXJmE7x3cRP6QT1cSFCAxQGwnMPrj72teV9qXr-REwCg%40mail.gmail.com.

[Steve Gibbard]

Thanks Taylor.  The problem we have is that we are using the standards as guidance when developing our applications to interface webrtc to traditional voip services. We are also verifying browser behaviour and accommodating that.  

For the bundle case, we originally observed Chrome and the standards were inline as far as advertising candidates and ports for the other bundled streams is concerned.

When you change the behaviour in Chrome to move away from the latest proposed standard it makes it very difficult to interop because not only do we have a moving standard but also a moving target on the browser side. 

We'd like to make sure our implementation is using the same assumptions that Chrome is making, but we are currently finding these assumptions only once something breaks.

Was there a PSA associated with this change or is there some documentation or tracking of where Chrome's behaviour deviates from the standard?   

Steve

  

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAK35n0arh%3D3bT8oDGnO-7cWbvrDZbqBKygC8t13NhN6%2BZuQ-bw%40mail.gmail.com.

[Taylor Brandstetter]

I definitely understand your frustration. However I don't believe a PSA was sent out, because the change was initially unintentional, and classified as a bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=5211

We've just been holding off on taking action on the bug until the discussion in MMUSIC resolves. It appears that currently, the draft is close to being changed. Here's the latest thread: http://www.ietf.org/mail-archive/web/mmusic/current/msg15738.html

CC'ing Peter Thatcher, in case he wants to weigh in.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAE26g8EZWpBA4_WDnwf7XqBw%2BySdEKE1tTWPnZWge0%2B5drFEuw%40mail.gmail.com.

[Sumanta Sen]

Taylor,

We understand this is an issue. Nut just need to clarify one thing:

Why is it picking video port as 9 only?

Thanks,

Sumanta

<mailto:discuss-webrtc+unsub...@googlegroups.com>.

--
https://jitsi.org

[Taylor Brandstetter]

9 is chosen as the default port if there are no "a=candidate" lines for the media section. I realize this doesn't match the current BUNDLE draft, which says the port should be the same for m-lines bundled by a previous offer/answer. We'll fix this at some point.

<mailto:discuss-webrt...@googlegroups.com>.

--
https://jitsi.org

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/e786719d-0efe-4218-8635-789c974b7b99%40googlegroups.com.