ice-lite sdp example

[pablo]

Hi,

Is it ok to use ice-lite for the MCU?
Using ice-lite means that the port will be hard coded and if the client can't send it to it it won't be able to connect?

Is it better that the MCU will send the offer or let the client send the offer?

Can anyone share a minimal ice-lite SDP example?
It can be simplified with only one audio media type and rtcp-mux.

Thanks

[Dmitry Sobinov]

Hi Pablo

From my experience with Chrome, ICE-LITE works quite well. However, I didn't test Firefox.

You can use TURN server to improve connectivity (also TURN with TCP) if MCU's UDP port is blocked by a firewall. UDP port can be a fixed value or dynamic one.

Example of SDP offer-answer:

offer by Chrome

o=- 1862751536763812389 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic: WMS rShHv0ssFzk8fODnhOvZyBiKF3gcoAvXC6SB m=audio 1 RTP/SAVPF 103 c=IN IP4 0.0.0.0 a=ice-ufrag:zM6MgN5dfHpFXYa+ a=ice-pwd:TZjF0P84RubM4/4xj6zMWtl1 a=ice-options:trickle a=mid:audio a=maxptime:60 a=sendonly a=rtcp:1 IN IP4 0.0.0.0 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:y3BFFMZiY/0KAPt0zRa+UGMY4qUc6TpcNw5s1yxz a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=rtpmap:103 ISAC/16000 a=ssrc:28 cname:qFC+oWb21AyDhH4V a=ssrc:28 msid:rShHv0ssFzk8fODnhOvZyBiKF3gcoAvXC6SB rShHv0ssFzk8fODnhOvZyBiKF3gcoAvXC6SBa0 a=ssrc:28 mslabel:rShHv0ssFzk8fODnhOvZyBiKF3gcoAvXC6SB a=ssrc:28 label:rShHv0ssFzk8fODnhOvZyBiKF3gcoAvXC6SBa0

Answer from MCU:

o=relay 20518 0 IN IP4 192.168.1.33 s=- t=0 0 a=group:BUNDLE audio video a=msid-semantic:WMS a=end-of-candidates a=ice-lite

a=ice-options:trickle m=audio 11050 RTP/SAVPF 103 c=IN IP4 0.0.0.0 a=ice-ufrag:y4WXSUz7VPijqr5Z a=ice-pwd:yLvMmn6Kn+c+P8TqPNxTra5d a=ice-options:trickle a=mid:audio a=maxptime:60 a=candidate:0 1 UDP 2113667327 192.168.1.33 11050 typ host a=recvonly a=rtcp:11050 IN IP4 192.168.1.33 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:0xk8WwzMdzWShI+kBlojYHfj+jRQUjdrtOhAlyKI a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=rtpmap:103 ISAC/16000 m=video 11050 RTP/SAVPF 100 c=IN IP4 0.0.0.0 a=ice-ufrag:8UoUo4crEOVk813G a=ice-pwd:0/P/2kEJAWJ7qruhVALN9VnF

Regards,

Dmitry

[pablo platt]

Thank you Dmitry.

Is there any difference when the MCU is the offerer or answerer?

In your Chrome offer there is no m=video block but there is a video bundle. Is this ok?

How do you use a dynamic UDP port?

--
 
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dmitry Sobinov]

Is there any difference when the MCU is the offerer or answerer?

I think, there should be no difference if MCU is offerer or answerer. According to RFC 5245 5.2 ICE-LITE agent will be always controlled, and WebRTC endpoint -- controlling.

In your Chrome offer there is no m=video block but there is a video bundle. Is this ok?

Video m-sections are omitted from the example for brevity, forgot to mention that.

How do you use a dynamic UDP port?

If you mean server port, it's not dynamic. Socket is created on server start up and then all WebRTC clients use the same UDP port to connect to. Port 11050 in the example above is just an arbitrary value set in the config file for development environment.

Regards,

Dmitry

[pablo platt]

In your example Chrome sends an offer with a=ice-options:trickle, in my case Chrome sends an offer with a=ice-options:google-ice.

What's the difference and which one is better for MCU usage?

How did you make Chrome use trickle ice?

Chrome sends STUN binding requests for connectivity checks with a username (Chrome's username and the MCU username concatenated).

Do I need to include the username in the response?

Does it need to be in the opposite order (MCU username, Chrome username)?

I didn't include it and it seems to work but maybe it is needed in the spec (couldn't find it).

I didn't see that the ice-pwd attribute is being used in the MCU.

Can I remove it from the MCU answer/offer?

After sending a response I'm starting to get media packets but still getting STUN packets.
Is it just for keep-alive?

Thanks

[Dmitry Sobinov]

Answers inline:

 

In your example Chrome sends an offer with a=ice-options:trickle, in my case Chrome sends an offer with a=ice-options:google-ice.
What's the difference and which one is better for MCU usage?
How did you make Chrome use trickle ice?

GICE option is removed from SDP, and ice-trickle is added after SDP is formed in PeerConnection.createOffer, but before setting it in PC.setLocalDescription (see http://tools.ietf.org/html/draft-ivov-mmusic-trickle-ice-01 for ICE-trickle details). Google-ICE has some incompatibilities with RFC 5245, so I prefer to disable it by removing corresponding option attribute. ICE-TRICKLE for MCU has serious advantage that it can establish connection almost immediately: it sends connectivity checks as soon as host candidates are gathered.

Chrome sends STUN binding requests for connectivity checks with a username (Chrome's username and the MCU username concatenated).
Do I need to include the username in the response?
Does it need to be in the opposite order (MCU username, Chrome username)?
I didn't include it and it seems to work but maybe it is needed in the spec (couldn't find it).

Chrome should use MCU_ufrag:Chrome_ufrag username (and that's what I've seen in practice). See RFC 5245 for details, paragraph 7.1.2.3. Also note the last sentence there: USERNAME attribute should not be present in the response (although it works if it's there).

I didn't see that the ice-pwd attribute is being used in the MCU.
Can I remove it from the MCU answer/offer?

Actually, yes, for ICE-LITE it's only ice-pwd from MCU is in use. But I guess this field is required in SDP - you can just generate random ice-pwd if sending over signaling link is not an option.

After sending a response I'm starting to get media packets but still getting STUN packets.
Is it just for keep-alive?

Something like this. As far as I understand it's consent freshness mechanism, so you need to respond to these packets. See http://tools.ietf.org/html/draft-muthu-behave-consent-freshness-04

---
Dmitry Sobinov
AddLive.com
Live video and voice for your application

[pablo platt]

Your answers are very helpful.

Thank you.