Webrtc call hold-unhold

[Sheel Patel]

Hi,

Trying to perform hold-resume for audio/video webrtc call.

As per the ICE-restart description in the ICE rfc 5245, ICE restart is not required and just the streams are being marked as inactive/sendonly.

Although while processing re-invite SDP, webrtc client doesn't update c-line IP and m-line port to the previously nominated during ICE connectivity

and keeps the one as per the candidate gathering order (instead of highest priority As per ICE rfc 5245 9.1.2.2)

Similar behavior for unhold, as the c and m line IP:Port is used to update the streams later, when ICE-restart is not performed.

Also, after unhold, SRTP packets are not present, if captured in wireshark, but the sendPkt count increments with the new ssrc_xxxx_send in webrtc-internal logs.

Am I missing something during renegotiation? As the stream should be setup without ICE-DTLS processing for this scenario.

Thanks,

Sheel

[Sheel Patel]

Providing some more details.

Attached are 3 sets of SDPs (Initial offer-answer, hold offer-answer and unhold offer-answer)

Please, note that. This is only one side of the call session, which is between webrtc client A and GW. the other end is omitted here, but which is triggering hold/unhold requests.

Also, the GW is in ICE-Lite mode, as present in SDP.

Some more observations:

1. When hold Offer-Answer is completed successfully ICE goes into ICEConnectionStateDisconnected and eventually into ICEConnectionStateFailed.

which looks to be an issue, but finding it difficult to identify this behavior. Not finding appropriate error logs.

chrome://webrtc-internals prints following error log,

ERROR 4540 17176 16:05:11-404 c:\b\build\slave\win\build\src\third_party\webrtc\p2p\base\port.cc 296 Jingle:Port[07300D70:audio:1:0::Net[{4FEC2AA5-E2D5-434E-B9C5-BDB57DAF6E3F}:172.16.110.x/24:Wifi]]: Received non-STUN packet from unknown address

Any help much appreciated.

Thanks!

[Taylor Brandstetter]

When the call is put on hold, does the gateway still respond to STUN binding requests? If not, that's probably why the ICE state is going to "disconnected" and then "failed".

--

---
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-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/3448861d-7416-40ab-b960-4d79994152d0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sheel Patel]

Thanks Taylor, You were spot on! I have fixed the STUN keepalive and it is working now.

Although, if ICEconnection gets closed, during re-invite, shouldn't it trigger for ICE-restart? As it destroyed the connection

and would expect to re-negotiation candidates and establish again. In this case, it was still sending same ice-ufrag and ice-pwd.

Some clients seems to terminate the call in this case and others didn't. I am not sure what could be the expected behavior.

Cheers! [It is almost Friday even]

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

An ICE restart won't occur by default, even if ICE is failed or disconnected. The endpoint that generates the new offer needs to call `createOffer` with `iceRestart` set to `true`, which will generate an offer with a new ice-ufrag/ice-pwd.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/4934cd0d-39c8-4404-b310-8db94e56a3d5%40googlegroups.com.