<div dir="ltr"><div>Thank you so much guys for this insight into the issue. Let me talk to the SIP client developers and see what is their point-of-view on this.<br><br>Thank you<br></div><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 1, 2015 at 10:36 PM, Richard Fuchs <span dir="ltr"><<a href="mailto:rfuchs@sipwise.com" target="_blank">rfuchs@sipwise.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 02/01/15 09:17, Muhammad Shahzad wrote:<br>
> Thanks for detailed reply and sharing the valuable information. You are<br>
> right i should also post this on discuss-webrtc forum, will do after i<br>
> get a fresh call trace, possibly tomorrow.<br>
><br>
> Regarding your questions, yes the call establishes successfully at<br>
> signalling level and audio stream works perfectly fine. I see DTLS<br>
> certificates generated, sent, received, accepted etc. in RTPEngine logs.<br>
> Both SIP and WebRTC clients successfully negotiate ICE and choose<br>
> RTPEngine for media relay. However, the SIP client looses video after<br>
> 1-2 seconds of call establishment, the audio still works during the<br>
> entire call. So, i am convinced that problem is entirely related to<br>
> video as far as the call establishment is concerned.<br>
><br>
> The WebRTC client is based on JSSIP but i am not aware of any config or<br>
> method that may give us such control over media in response to this SIP<br>
> INFO method. Any experienced JSSIP users / developers out there who may<br>
> help on this?<br>
><br>
> The SIP client is based on a commercial SIP SDK. Both WebRTC and SIP<br>
> clients work perfectly fine as long as other end is same, i.e. SIP to<br>
> SIP and WebRTC to WebRTC video calls work as expected under same network<br>
> conditions. Each client has only one video codec enabled, which is VP8,<br>
> without any trans-coding etc. involved in between.<br>
<br>
</span>To my (limited) knowledge, requests for key frames are sent as<br>
AVPF-profile RTCP packets. Meanwhile, most regular SIP clients don't<br>
speak AVPF but rather AVP only, and so don't support these requests for<br>
key frames. Which results in the AVPF client never sending any key<br>
frames because nobody requests any.<br>
<br>
To allow interoperability, the translating agent (rtpengine) would need<br>
to support and understand the video codec in use (VP8) at least to a<br>
minimal extent and simulate AVPF key frame requests. Which it currently<br>
doesn't.<br>
<br>
cheers<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
</div></div></blockquote></div><br></div>