1 Feb
2015
1 Feb
'15
10:36 p.m.
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