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