Project: webrtc Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 21 users
Status: Available
Owner:
Last visit > 30 days ago
Cc:
Components:
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment
ICE candidates on re-negotiation are not reflected in SDP Answer for the new stream
Reported by jmil...@aliax.net, Feb 18 2013 Back to list
What steps will reproduce the problem?
1. Setup an audio call between two RTCPeerconnections
2. Add a video stream to a peer and send the new SDP Offer to the other
3. In the other peer, set the incoming offer as remote description, add a video stream to the peer and generate de SDP Answer. 

What is the expected result?

A SDP Answer where ICE candidates are reflected in the audio and video description.


What do you see instead?

1. No 'a=candidate' lines in the video description
2. No IP address in video description

c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0


What version of the product are you using? On what operating system?

Version 26.0.1410.5 dev / Linux (Debian)


Please provide any additional information below.

Once the audio session is established:

// A peer adds a video stream to it's RTCPeerconnection
// Generates the offer and sends it to the other peer

// The other peer receives the SDP Offer with the new video stream
// The other peer makes it its remote description
pc.setRemoteDescription();
// onaddstream is fired

// The other peer user is asked for video access
navigator.webkitGetUserMedia({audio: false, video: true}, onUserMediaSuccess, onUserMediaError);

// onUserMediaSuccess:
pc.createAnswer(setLocalDescriptionAndSend, null, null);

===

After running setLocalDescription(), ICE candidate gathering starts. When the last candidate is gathered, pc.localDescription.sdp contains an incorrect SDP, with  the following lines for the video description and no 'a=candidate' line for the video description either.

c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0

The caller and callee logic are exactly the same for the first (audio only) establishment and the second one (video addition), but in the last one, ICE candidates are not reflected in the SDP.
 
Project Member Comment 1 by vikasmarwaha@webrtc.org, Feb 19 2013
Cc: mallinath@webrtc.org
Owner: vikasmarwaha@webrtc.org
Project Member Comment 2 by juberti@webrtc.org, Feb 20 2013
Is the bug here that localDescription does not contain a=candidate lines even after gathering completes? 

It is correct behavior for the initial output from createAnswer to not have any a=candidate lines, since gathering has not yet completed.
Project Member Comment 3 by juberti@webrtc.org, Feb 20 2013
Labels: Area-PeerConnection
Comment 4 by jmil...@aliax.net, Feb 20 2013
Hi,

This is the best way I've found to explain what is happening. Here a detailed step-by-step log of what is executed at each moment ant the RTCPeerconnection and ICE status on each one:

// JavaScript
pc.onicecandidate = function(e) {
  if (!e.candidate) {
    console.log(pc.locaDescription.sdp);
  }
};
// end of JavaScript

// Called Receives a audio only Offer

JsSIP | MEDIA SESSION | Calling setRemoteDescription
JsSIP | MEDIA SESSION | PeerConnection state changed to "have-remote-offer"
JsSIP | MEDIA SESSION | stream added: fNp6YzGMDmg9wZtp9x0t5BoCkoCpbpXhK3bj
JsSIP | MEDIA SESSION | requesting access to local media
JsSIP | MEDIA SESSION | Calling getUserMedia (audio only)
JsSIP | MEDIA SESSION | got stream
JsSIP | MEDIA SESSION | Calling addStream
JsSIP | MEDIA SESSION | Calling createAnswer
JsSIP | MEDIA SESSION | Calling setLocalDescription
JsSIP | MEDIA SESSION | PeerConnection state changed to "stable"
JsSIP | MEDIA SESSION | ICE connection state changed to "checking"
JsSIP | MEDIA SESSION | ICE candidate received: a=candidate:4093981320 1 udp 2113937151 192.168.1.130 45935 typ host generation 0
JsSIP | MEDIA SESSION | ICE candidate received: a=candidate:1967993916 1 udp 1845501695 MY.PUBLIC.IP.ADDRESS 45935 typ srflx raddr 192.168.1.130 rport 45935 generation 0
JsSIP | MEDIA SESSION | ICE candidate received: a=candidate:3129396856 1 tcp 1509957375 192.168.1.130 40641 typ host generation 0


""""
v=0
o=- 3387807441 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj
m=audio 45935 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 MY.PUBLIC.IP.ADDRESS
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:4093981320 1 udp 2113937151 192.168.1.130 45935 typ host generation 0
a=candidate:1967993916 1 udp 1845501695 MY.PUBLIC.IP.ADDRESS 45935 typ srflx raddr 192.168.1.130 rport 45935 generation 0
a=candidate:3129396856 1 tcp 1509957375 192.168.1.130 40641 typ host generation 0
a=ice-ufrag:29bc9AsklxanHwOd
a=ice-pwd:keHJ3IcZZc3Ae0YRQZTSmETO
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:j4SpLRH15N9E+it3K1Li7aD9/Ux9qy1pKZ0azTy4
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
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:2734391999 cname:cOe698sjygQ6OmsU
a=ssrc:2734391999 msid:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAja0
a=ssrc:2734391999 mslabel:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj
a=ssrc:2734391999 label:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAja0

""""

// Call is successfully established.
// Later, callee receives a audio+video Offer

JsSIP | MEDIA SESSION | Calling setRemoteDescription
JsSIP | MEDIA SESSION | PeerConnection state changed to "have-remote-offer"
JsSIP | MEDIA SESSION | stream added: ZAWVCCcLtQrGip0uYN4rGyHnfWYXNDHcqcrS
JsSIP | MEDIA SESSION | requesting access to local media
JsSIP | MEDIA SESSION | Calling getUserMedia (video only)
JsSIP | MEDIA SESSION | ICE connection state changed to "disconnected" (**)
JsSIP | MEDIA SESSION | got stream
JsSIP | MEDIA SESSION | Calling addStream
JsSIP | MEDIA SESSION | Calling createAnswer
JsSIP | MEDIA SESSION | Calling setLocalDescription
JsSIP | MEDIA SESSION | PeerConnection state changed to "stable"
JsSIP | MEDIA SESSION | ICE connection state changed to "checking"
JsSIP | MEDIA SESSION | ICE candidate received: a=candidate:4093981320 1 udp 2113937151 192.168.1.130 45935 typ host generation 0
JsSIP | MEDIA SESSION | ICE candidate received: a=candidate:1967993916 1 udp 1845501695 MY.PUBLIC.IP.ADDRESS 45935 typ srflx raddr 192.168.1.130 rport 45935 generation 0


""""
v=0
o=- 3387807441 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 63by1hYQ2VPpI1EFwojTtesNkjdE6tNrEoHb T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj
m=audio 45935 RTP/SAVPF 103 104 111 0 8 107 106 105 13 126
c=IN IP4 MY.PUBLIC.IP.ADDRESS
a=rtcp:1 IN IP4 0.0.0.0
a=candidate:4093981320 1 udp 2113937151 192.168.1.130 45935 typ host generation 0
a=candidate:1967993916 1 udp 1845501695 MY.PUBLIC.IP.ADDRESS 45935 typ srflx raddr 192.168.1.130 rport 45935 generation 0
a=candidate:3129396856 1 tcp 1509957375 192.168.1.130 40641 typ host generation 0
a=candidate:4093981320 1 udp 2113937151 192.168.1.130 45935 typ host generation 0
a=candidate:1967993916 1 udp 1845501695 MY.PUBLIC.IP.ADDRESS 45935 typ srflx raddr 192.168.1.130 rport 45935 generation 0
a=ice-ufrag:29bc9AsklxanHwOd
a=ice-pwd:keHJ3IcZZc3Ae0YRQZTSmETO
a=sendrecv
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:j4SpLRH15N9E+it3K1Li7aD9/Ux9qy1pKZ0azTy4
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
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:2734391999 cname:cOe698sjygQ6OmsU
a=ssrc:2734391999 msid:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAja0
a=ssrc:2734391999 mslabel:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAj
a=ssrc:2734391999 label:T5c6qMI4tgWJ4kLVxG6rcy2Gzrw5ToWERKAja0
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:29bc9AsklxanHwOd
a=ice-pwd:keHJ3IcZZc3Ae0YRQZTSmETO
a=sendrecv
a=mid:video
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:j4SpLRH15N9E+it3K1Li7aD9/Ux9qy1pKZ0azTy4
a=rtpmap:100 VP8/90000
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2019586529 cname:A40zSlHwPkl8Tijs
a=ssrc:2019586529 msid:63by1hYQ2VPpI1EFwojTtesNkjdE6tNrEoHb 63by1hYQ2VPpI1EFwojTtesNkjdE6tNrEoHbv0
a=ssrc:2019586529 mslabel:63by1hYQ2VPpI1EFwojTtesNkjdE6tNrEoHb
a=ssrc:2019586529 label:63by1hYQ2VPpI1EFwojTtesNkjdE6tNrEoHbv0
""""
 

(**) -> After this moment, peer to peer media stops flowing.

The logic for processing initial and not initial offer is the same as shown.


Project Member Comment 5 by vikasmarwaha@webrtc.org, Feb 21 2013
Hi,

I will try to recreate this, do you have a simple demo page i can recreate this? 

/Vikas
Project Member Comment 6 by vikasmarwaha@webrtc.org, Feb 21 2013
Hi,

I tested on  27.0.1418.2 canary on win7 and i could not recreate it. I mean i see video and hear audio. I am attaching my code for reference.

Here are the steps to run the test:-

1. Click start and select the audio device
2. Click call, now you should hear yourself in loopback
3. Click change-media and select the video device
4. Click call-again button and you will see the video.

Let me know if the test fails for you.

/Vikas
reoffer.html
3.6 KB View Download
Comment 7 by jmil...@aliax.net, Feb 21 2013
Hi Vikas,

Thank you for your input.

What I was trying to do was 'modifying' the same session with a second offer. The example you provide does create 'pc1' and 'pc2' again when re-calling, and the previous session as such is lost. If 'pc1' and 'pc2' are not created again but reused, the demo does not work after setting the local description on 'pc2'.

According to RFC 3264 section 8 (Modifying the Session):

"
When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP.
"

I don't really know how compliant is generating a totally new offer in an already established session.

So I guess this is not implemented in RTCPeerconnection right now. Is that correct? Any related information will be very welcome.

Regards
Project Member Comment 8 by vikasmarwaha@webrtc.org, Feb 21 2013
Hi Jose,

Just to clarify, I am not creating pc1 & pc2 again when recalling. It is only created once. I send an updated offer with video when you click the call-again button.

/Vikas
Jose,

I think you misinterpreted the application. I donot create peerconnection when send a new video offer. I tested on M26 and it works fine. I am not sure what problem you are facing? Can you modify this code to show the problem?

-Vikas
Comment 10 by jmil...@aliax.net, Feb 22 2013
Vikas,

Sorry, I misinterpreted the application, and also mixed the results with different browser versions. Now, I've reproduced the problem.

You can find attached two logs for the same re-offer process. It does fail for chrome version 26.0.1410.5 dev and goes ok for Version 27.0.1418.0 (183191).

You will see that, for smaller version browser, no ICE candidates are gathered after Answer to re-offer comes from pc2 (just at the end of the log file), contrary to the newest version, which does gather local ICE candidates after receiving the answer to such offer.

For smaller version browser, the media flow is stopped, the same way happened in my application. 

So, it seems that the bug is already solved in newer versions.

Regards,


reoffer_ok_27.0.1418.0.log
7.0 KB View Download
reoffer_nok_26.0.1410.5 dev.log
5.4 KB View Download
Project Member Comment 11 by vikasmarwaha@webrtc.org, Feb 22 2013
Thanks for the feedback i will test the reoffer.html page on M26 and see if i can recreate it.
Project Member Comment 12 by vikasmarwaha@webrtc.org, Feb 22 2013
Tested on Version 26.0.1410.12 it works fine. Will try on 26.0.1410.5 and see if i can recreate. 
Project Member Comment 13 by vikasmarwaha@webrtc.org, Feb 22 2013
I confirmed reoffer.html doesnot work on 26.0.1410.5 dev but it works fine on 26.0.1410.12. We might have fixed something between this versions. If it is not much trouble i would suggest you to upgrade to 26.0.1410.12. 

/Vikas 
Comment 14 by jmil...@aliax.net, Feb 22 2013
Hi Vikas,

Thanks. There is no problem at all upgrading the version.

Find attached a modified version of the application you provided. As I don't manage ICE trickling (I use SIP for signalling), I wait until all ICE candidates are gathered in order to create and send the offer, and same for the answer.

In order to know whether the ICE gathering has finished, I make use of pc.onicecandidate() handler. I do not use pc.addicecandidate() method at all but advertise candidates through SDP.

Everything goes OK for the first call as can be seen, but in the reoffer process, pc.onicecandidate() does not work as expected. You will see that no 'a=candidate' line figures in the answer and the IP address in the video description is 0.0.0.0 as specified in the issue description.

I hope I'm doing right looking pc.onicecandidate() to know when the ICE gathering has finished.  

Note that even if no 'a=candidate' line is passed in the answer video description, there is video between two peers. 
reoffer_candidates_sdp.html
3.9 KB View Download
Project Member Comment 15 by vikasmarwaha@webrtc.org, Feb 22 2013
Thanks for the code change will take a look at it.
Comment 16 by jmil...@aliax.net, Mar 11 2013
Hi,

Was there any chance to look at this?

Are ICE candidates expected in an answer to a re-negotiation offer even if not necessary due to the use of 'bundle' in SDP?
Hello,
I reproduce this issue (any ICE candidate in SDP provided by createAnswer() call) in version 29.0.1547.76 m and in canary also. Again, any change to get a feedback about that. Please find webrtc internal log in attachment.
Thanks
Laurent


issue-1404-webrtc-internal.log
7.1 KB View Download
Project Member Comment 18 by vikasmarwaha@webrtc.org, Oct 2 2013
Thanks for the feedback, Laurent did you recreate the problem with the test page from comment #14 above? What exactly is the problem you are seeing?
Hello, thanks to have a look on our issue.
No, I don't use the test page from comment 14, I use my own test application on WebRTC framework (https://code.google.com/p/webrtcomm/)with our JAIN SIP javascript stack inside. Initial Alice/Bob call setup is ok (SIP INVITE <-> 200 OK <-> ACK) with initial WebRTC offer/answer but when Bob tries to renegociate the SDP (REINVITE/UDPATE <->, 200OK <->ACK), the sequence SetRemoteDescription(), createAnswer(), SetLocalDesciption() on the Alice side is successfull but the WebRTC SDP answer doesn't have any ICE candidates, audio port is set to 0! It has to be noticed that in the renegociated SDP offer of Bob, @IP and port have not changed, just codec list. I provided the  chrome://webrtc-internals log, do you need additional trace to progress?
Thanks again.
Laurent
Project Member Comment 20 by juberti@webrtc.org, Dec 12 2014
Cc: vikasmarwaha@webrtc.org
Labels: EngTriaged Mstone-43
Owner: pthatcher@webrtc.org
Status: Available
I was able to reproduce this in the demo page from #14. Summarized:
Offer1: has 1 m line, candidates and BUNDLE
Answer1: has 1 m line, candidates and BUNDLE
Offer2: has 2 m lines, candidates on both m lines, duplicated because of BUNDLE
Answer2: has 2 m lines, candidates only on the first m line, and no candidate events.

I think it is OK to not have candidates on the second m line, but we should be consistent (i.e. not do it in the offer), and we should still fire the end-of-candidates callback.
Project Member Comment 21 by vikasmarwaha@webrtc.org, Mar 31 2015
any update, still for M43?
Project Member Comment 22 by pthatcher@webrtc.org, Apr 1 2015
Labels: -Mstone-43 Mstone-44
Project Member Comment 23 by tnakamura@webrtc.org, Jan 29 2016
Cc: -vikasmarwaha@webrtc.org -mallinath@webrtc.org
Labels: -Mstone-44
I don't see any CLs linked to this bug, so I don't think it's been fixed. Removing milestone label since this bug hasn't been updated in quite some time.
Project Member Comment 24 by pthatcher@webrtc.org, Oct 4 2016
Labels: -Pri-2 Pri-3
Sign in to add a comment