c=IN IP4 0.0.0.0 for m=video lines Chrome 28

[Simon Tolham]

Hi,

In Chrome version 28, my local SDP (see below) sometimes contains a c=IN IP4 0.0.0.0 for m=video or m=application descriptions.   Also, when this is the case, no candidates are returned for those media descriptions.  Finally the default media ports and the RTCP-mux ports on the m=video lines are set to 1:

m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0

Performing an offer-answer, ICE does complete. I guess there is only 1 ICE Agent as the media is multiplexed on the same port and as the audio media description contains candidates, the remote end knows where to send its connectivity checks.

However, if I connect the remote stream to a Html5 video element, I see no video (nor hear any audio).  Is there something I am not doing / not waiting for when the offer is being created? I currently send the first SDP I get to the far end, and then trickle candidates to it. My thought was that the local SDP should always have host candidates in it, and then later learn of server reflexive / relay candidates as and when STUN binding responses / TURN allocation creates succeed.

Has anyone else experienced this?

Note: Only when the SDP contains a c=IN IP4 0.0.0.0 do I not see/hear any media in the browser. Otherwise everything works fine.

v=0 o=- 9148204791819634656 3 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE audio video data a=msid-semantic: WMS kyaiqbOs7S2h3EoSHabQ3JlBqZ67cFqZmWFN m=audio 50853 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4 192.168.1.64 a=rtcp:50853 IN IP4 192.168.1.64 a=candidate:3460887983 1 udp 2113937151 192.168.1.64 50853 typ host generation 0 a=candidate:3460887983 2 udp 2113937151 192.168.1.64 50853 typ host generation 0 a=ice-ufrag:4jMM2zIhjZ0aUAW3 a=ice-pwd:Pre9Ek4bdsrMqI4F2b0QExFf a=ice-options:google-ice a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=sendrecv a=mid:audio a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:tfSLd826VxVMQDnFfn9ZRkx/KIj2CBZGHFzve35W a=rtpmap:111 opus/48000/2 a=fmtp:111 minptime=10 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:107 CN/48000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:126 telephone-event/8000 a=maxptime:60 a=ssrc:1786833184 cname:AOneLOYuY/xa8Px2 a=ssrc:1786833184 msid:kyaiqbOs7S2h3EoSHabQ3JlBqZ67cFqZmWFN kyaiqbOs7S2h3EoSHabQ3JlBqZ67cFqZmWFNa0 a=ssrc:1786833184 mslabel:kyaiqbOs7S2h3EoSHabQ3JlBqZ67cFqZmWFN a=ssrc:1786833184 label:kyaiqbOs7S2h3EoSHabQ3JlBqZ67cFqZmWFNa0 m=video 1 RTP/SAVPF 100 116 117 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:4jMM2zIhjZ0aUAW3 a=ice-pwd:Pre9Ek4bdsrMqI4F2b0QExFf a=ice-options:google-ice a=extmap:2 urn:ietf:params:rtp-hdrext:toffset a=sendrecv a=mid:video a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:tfSLd826VxVMQDnFfn9ZRkx/KIj2CBZGHFzve35W a=rtpmap:100 VP8/90000 a=rtcp-fb:100 ccm fir a=rtcp-fb:100 nack a=rtcp-fb:100 goog-remb a=rtpmap:116 red/90000 a=rtpmap:117 ulpfec/90000 m=application 1 RTP/SAVPF 101 c=IN IP4 0.0.0.0 a=rtcp:1 IN IP4 0.0.0.0 a=ice-ufrag:4jMM2zIhjZ0aUAW3 a=ice-pwd:Pre9Ek4bdsrMqI4F2b0QExFf a=ice-options:google-ice a=sendrecv a=mid:data b=AS:30 a=rtcp-mux a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:tfSLd826VxVMQDnFfn9ZRkx/KIj2CBZGHFzve35W a=rtpmap:101 google-data/90000 a=ssrc:4265332770 cname:YZtEmAtn3judr9CY a=ssrc:4265332770 msid:MyChannel MyChannel a=ssrc:4265332770 mslabel:MyChannel a=ssrc:4265332770 label:MyChannel

[Simon Tolham]

Is anybody else seeing this issue?

This happens incredibly frequently (1 in around 5 or 6 calls made) for me with Chrome v28.  I did not used to see this issue in Chrome v27.

Can anyone suggest what may have changed in this version / any changes to the API that I am not looking at ? (ICE states etc.).

[Geoffry Nagy]

Hi, I'm also having the exact same problem as you describe. More often in Chrome <-> Firefox interops.

Op dinsdag 23 juli 2013 20:12:18 UTC+2 schreef Simon Tolham:

[Simon Tolham]

Hi Geoffry,

Good to know I'm not the only one - I'm surprised more people haven't seen this issue.  I believe this is related to network interface enumeration / binding to specific interfaces, as in testing I believe this issue occurs more frequently on PCs with more network interfaces. Disabling all but one interface does tend to improve this, but my testers still see this issue (across a variety of different machines in different network conditions) even on a PC with a single interface.

I also can't see how the local candidates can differ - one valid IP, one invalid - across media descriptions in the session description.  Presumably the candidate gathering stage doesn't start until there is at least 1 candidate per media description in the session description, and seeing as Chrome multiplexes the media on one port, all local candidates across all media descriptions should be the same.

[Vladimir Ralev]

I have seen this issue in a slightly different variant:

c=IN IP4 1.1.1.1 (correct IP) a=rtcp:1 IN IP4 0.0.0.0 (this one is the problem)

Even though this is often related with problems such as unidirectional audio/video, sometimes it works just fine.

This issue occurs seemingly independently for audio and video.

--
 
---
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.

[Simon Tolham]

Please can a Chrome dev give some insight into this issue?  Why would a peer connection ever generate a local SDP with 0.0.0.0 IP addresses?  Is this a bug?

[Mallinath Bareddy]

Simon,

0.0.0.0 address doesn't mean that chrome is not opening any ports for media. This is used as default address in SDP c line. Since chrome do ICE trickling, candidates will be provided in a different callback and not in the offer. So you should expect the ICE candidates when you get c=0.0.0.0. In most of the cases that will be the case. 

Does your testing is between two chromes? Or there are other types of end points like SIP, which may interpret differently to 0.0.0.0 address in c line.

if you run apprtc between two tabs, you will notice in 0.0.0.0 in c line too. So the problem is not in c line, but in something else. I would like to know what your candidates look like when this happens.

/Mallinath

[Simon Tolham]

My testing is to a proprietary application, but that application supports ICE with many other systems that are RFC5245 compliant and Chrome has no issues (in the working case) getting relay candidates from our proprietary TURN server (fully RFC5766 compliant).  I believe the issue I am seeing is purely Chrome side, and happens every 1 in 5 calls on average.

It seems to be that when this case occurs and I get the call-up for the local SDP being known, I have host candidates for the audio description, but not for the video description. Why might that be? As Chrome multiplexes all data onto one port for BUNDLE I don't see how some host candidates are included for one media description, but not for another.

Using the appRTC code for reference, can you confirm that I should expect to see a single "setLocalAndSendMessage" call-up after calling pc.createOffer(setLocalAndSendMessage, null, constraints) and I then call pc.setLocalDescription(sessionDescription). As and when host candidates are learnt, they are then signalled using the onIceCandidate call-up. Can I verify with you that I do not need to configure the peer connection with these local candidates, and that I only need to call pc.addIceCandidate(candidate); for remote candidates that trickle in from the remote end.

In my opening message in this thread, I include the initial session description I learn through the setLocalAndSendMessage equivalent in my code. Why does that have only the audio host candidates in - from what you say I should see none in this initial SDP? Also why does the video description have a=rtcp:1 IN IP4 0.0.0.0 when the audio description does not?

This only appeared to start causing issues in Chrome v28 and the fact that others have seen similar issues is also a bit worrying. I have been using WebRTC in Chrome since it was first made available in Chrome.

--
 
---
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/mc1kPCw5KBU/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.