How to acquire early media streams in 0.15.6?

[andrey....@gmail.com]

It looks like when acquiring early media the sessionDescriptionHandler in the session variable is undefined.

Steps that I receive to reproduce this behavior:

I'm receiving 183 Session progress:

SIP/2.0 183 Session Progress
Via: SIP/2.0/WSS nbqi6bkgbliv.invalid;rport=55209;received=10.0.3.202;branch=z9hG4bK2640220
Call-ID: 4245r9gqgnevk9t2i1f4
From: "Егошин Андрей" <sip:6010@removed>;tag=mk4l91skmn
To: <sip:2593@removed>;tag=58b0e6da-b3b4-4031-a0b6-6fe9a6e3ead9
CSeq: 2 INVITE
Server: Asterisk PBX 15.7.3
Contact: <sip:172.16.1.2:8089;transport=ws>
Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE
Require: 100rel
RSeq: 992
Content-Type: application/sdp
Content-Length:  1655

v=0
o=- 1163309608 1163309608 IN IP4 <removed>
s=Asterisk
c=IN IP4 <removed>
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE audio-0 video-1
m=audio 55038 UDP/TLS/RTP/SAVPF 0 8 101
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 58:C0:19:E3:16:71:E7:99:F7:7E:4F:C9:15:8C:E9:FE:1E:B2:94:35:3C:54:54:07:09:CA:E9:4D:F7:69:37:65
a=ice-ufrag:231bd66525590e7d7bfd471112321b6b
a=ice-pwd:02f334da71c9ab2112db5bb1022a23bc
a=candidate:H505db136 1 UDP 2130706431 <removed again> 55038 typ host
a=candidate:Hac100502 1 UDP 2130706431 172.16.5.2 55038 typ host
a=candidate:Hac100102 1 UDP 2130706431 172.16.1.2 55038 typ host
a=candidate:Hac100702 1 UDP 2130706431 172.16.7.2 55038 typ host
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:1080527366 cname:7f2be0b0-f2e3-4efb-8288-e45838473769
a=msid:725868b0-6429-4666-939e-18ac7d647d7a ca519e71-331c-46e3-8073-31ec2682e940
a=mid:audio-0
m=video 55038 UDP/TLS/RTP/SAVPF 100 99
a=connection:new
a=setup:actpass
a=fingerprint:SHA-256 58:C0:19:E3:16:71:E7:99:F7:7E:4F:C9:15:8C:E9:FE:1E:B2:94:35:3C:54:54:07:09:CA:E9:4D:F7:69:37:65
a=ice-ufrag:231bd66525590e7d7bfd471112321b6b
a=ice-pwd:02f334da71c9ab2112db5bb1022a23bc
a=rtpmap:100 VP8/90000
a=rtpmap:99 H264/90000
a=sendrecv
a=rtcp-mux
a=ssrc:1811108801 cname:82902e1d-0855-440a-9852-c19965cd3f11
a=msid:d5c54bdf-9366-4d08-ae10-734aa2c6f481 e306affb-fec5-41ac-97f5-9ac5e75d6137
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
a=extmap:1 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=mid:video-1

After that there are this logs (logging is debuglevel)

sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invite-dialog | INVITE dialog 4245r9gqgnevk9t2i1f4mk4l91skmn58b0e6da-b3b4-4031-a0b6-6fe9a6e3ead9 constructed
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | SessionDescriptionHandlerOptions: {"constraints":{},"peerConnectionOptions":{}}
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | initPeerConnection
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | New peer connection created
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | initPeerConnection
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | Already have a peer connection for this session. Tearing down.
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | resetIceGatheringComplete
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | ICE Connection State changed to iceConnectionClosed
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | New peer connection created
sip-0.15.6.js:10061 Fri Nov 08 2019 15:25:33 GMT+0300 (Moscow Standard Time) | sip.invitecontext.sessionDescriptionHandler | 4245r9gqgnevk9t2i1f4mk4l91skmn | track added

And then the session's event `trackadded` is called. My code for acquiring media streams is almost identical to the documentation (just with fixes to prevent play errors in chrome):

_currentSession.on('trackAdded', function () {
    var pc = _currentSession.sessionDescriptionHandler.peerConnection;
    // Gets remote tracks
    var receivers = pc.getReceivers();
    if (receivers.length) { // If we don't have receivers, don't do anything
        var remoteStream = new MediaStream();
        receivers.forEach(function(receiver) {
            console.log(receiver);
            if (receiver.track) {
                if (receiver.track.kind === 'audio') {
                    remoteStream.addTrack(receiver.track);
                }
            }
        });
        _remoteAudio.srcObject = remoteStream;
        _remoteAudio.play();
    }
    // Gets local tracks
    var senders = pc.getSenders();
    if (senders.length) { // If we don't have senders, don't do anything
        var localStream = new MediaStream();
        senders.forEach(function(sender) {
            console.log(sender);
            if (sender.track)
            {
                if (sender.track.kind === 'audio') {
                    localStream.addTrack(sender.track);
                }
            }
        });
        _localAudio.srcObject = localStream;
        _localAudio.play();
    }
});

But it bugs out on referencing sessionDescriptionHandler as it is undefined in this situation.

How to acquire correct sessionDescriptionHandler here when it isn't even initialized yet and there is just an early media? How to distinguish the early media trackadded from the normal one?

[James Criscuolo]

In the old or new API, session.sessionDescriptionHandler is not set until the call is confirmed. This is necessary to account for branching scenarios, where we effectively spin up a session description handler per branch (a restriction of the webrtc api, at least back when we wrote in this behavior). It looks like we've moved both APIs to use earlyMediaSessionDescriptionHandlers to track these.

James

[andrey....@gmail.com]

It isn't documented anywhere yet, right? Can you provide me with an example on:

1. How to distinguish trackadded event called from early media from trackadded event called from confirmed call? Can I rely on existance of session.sessionDescriptionHandler? May be early media trackadded should be another event then? Currently it confuses me because it is fired twice - once on earlymedia and another on acquiring media from a confirmed call.

2. How to get handler from earlyMediaSessionDescriptionHandlers? From the code it looks like earlyMediaSessionDescriptionHandlers.get(session.id), but when dumping the session to console I cannot find any mapping to session.id, the key in the earlyMediaDescriptionHandller map is rather long and is not equal to the session.id somehow. May be the session object was modified in the process of a call and id is changed on the fly during the call thus not matching to the earlyMediaDescriptionHandller map anymore?

пятница, 8 ноября 2019 г., 17:31:25 UTC+3 пользователь James Criscuolo написал:

In the old or new API, session.sessionDescriptionHandler is not set until the call is confirmed. This is necessary to account for branching scenarios, where we effectively spin up a session description handler per branch (a restriction of the webrtc api, at least back when we wrote in this behavior). It looks like we've moved both APIs to use earlyMediaSessionDescriptionHandlers to track these.

James