Broken Reinvite/Unhold on Chrome 76 #728
Description
Describe the bug
The SDP in latest chrome have changed from Plan B to Unified plan.
“Unified Plan” Transition Guide (JavaScript)
This causes to have many audios when switch from a device to another when do a reinvite or a unhold as described in issue #664.
Yes we can use the sender.replaceTrack API for that purpose (what I use now as a workaround) but this does not change the fact that the reinvite is now broken if the constraints options have changed when do reinvite or unhold And even if replaceTrack work, I have to acquire the user media by myself, If I use sessionDecriptionHandler.acquire it broke the sender because it try to remove the previous track and then there is no chance to replace it, adding the track without reinvite it simply does not work. Also after acquire the user media I have to manually trigger the trackAdded and userMedia event. If I don't do that sipjs don't understand that the user media has changed and don't stop it correctly when terminate.
Here is my workaround code:
session.sessionDescriptionHandler.WebRTC.getUserMedia(constraints).then(streams => {
streams.getTracks().forEach(track => {
session.sessionDescriptionHandler.peerConnection.getSenders().forEach(sender => {
sender.track && sender.track.kind === track.kind && sender.replaceTrack(track)
})
session.sessionDescriptionHandler.observer.trackAdded()
session.sessionDescriptionHandler.emit('userMedia', streams)
})
})Logs
v=0
o=- 1025239875102185327 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS 7D2NrImu3kLms1dLkhRwl10RsyVV1xF0TCdL
m=audio 62611 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 172.16.39.93
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:299851297 1 udp 2122260223 172.16.39.93 62611 typ host generation 0 network-id 1
a=ice-ufrag:Lb7r
a=ice-pwd:JvCyppp+emtwF01gDfLX9NJx
a=ice-options:trickle
a=fingerprint:sha-256 65:3C:9E:35:63:86:41:47:32:14:CA:B8:8B:86:FD:B6:87:D2:7F:DD:37:97:91:1E:39:39:57:73:9D:FE:35:22
a=setup:actpass
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=msid:7D2NrImu3kLms1dLkhRwl10RsyVV1xF0TCdL 86a884a8-915b-43e6-b9b2-eef848ec9d70
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:4009328187 cname:tEKkzyFtv2z9vxcA
a=ssrc:4009328187 msid:7D2NrImu3kLms1dLkhRwl10RsyVV1xF0TCdL 86a884a8-915b-43e6-b9b2-eef848ec9d70
a=ssrc:4009328187 mslabel:7D2NrImu3kLms1dLkhRwl10RsyVV1xF0TCdL
a=ssrc:4009328187 label:86a884a8-915b-43e6-b9b2-eef848ec9d70
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Lb7r
a=ice-pwd:JvCyppp+emtwF01gDfLX9NJx
a=ice-options:trickle
a=fingerprint:sha-256 65:3C:9E:35:63:86:41:47:32:14:CA:B8:8B:86:FD:B6:87:D2:7F:DD:37:97:91:1E:39:39:57:73:9D:FE:35:22
a=setup:actpass
a=mid:1
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:jnxyznbOkzjOBETtQ9w1sqxQgfXR5KgmVU7s f7254bfb-a34e-465a-9b15-ad431c5c679d
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:3155171097 cname:tEKkzyFtv2z9vxcA
a=ssrc:3155171097 msid:jnxyznbOkzjOBETtQ9w1sqxQgfXR5KgmVU7s f7254bfb-a34e-465a-9b15-ad431c5c679d
a=ssrc:3155171097 mslabel:jnxyznbOkzjOBETtQ9w1sqxQgfXR5KgmVU7s
a=ssrc:3155171097 label:f7254bfb-a34e-465a-9b15-ad431c5c679d
To Reproduce (if possible)
Steps to reproduce the behavior:
- Invite with a constraint.
- Change constraint.
- Do a reinvite or an unhold.
- There is no more outgoing audio.
Expected behavior
When do a reinvite or and unhold with another constraint, sipjs automatically acquire the new media and trigger the track added event.
Observed behavior
The outgoing audio is lost.
Environment Information
- Asterisk 13
- Chrome 76
Additional context
Also, in latest Chrome unified plan, there is no candidates on new audios when do a reinvite. I have tried to create a modifier to correct this but I had not good results for now. This is may related to this #711