Hi Muhammad Can you comment if initially endpoints are receiving what is necessary to start sending Media at signaling level. For example: Successful ICE and SRTP-SDES/DTLS negotiation.
I see two issues here: a) Establish a successful call b) Once call is established how to deal with packet loss. Check this paper: http://static.googleusercontent.com/media/research.google.com/sv//pubs/archive/41611.pdf >From your email: "Force WebRTC client (running on Chrome / Firefox) to honor SIP INFO message and issue a key-frame in RTP video stream in response to this SIP request?" WebRTC in the browser depends on a upper transport layer in your case a SIP stack. Example: sipml5, sip.js, etc. Hence you need to modify that part there; so your signaling stack should interact with the Browser Media Engine upon recieving SIP INFO. Questions: 1. I would suggest to start a conversation in discuss-webrtc in Google Groups. -Which SIP stack are you using on the WebRTC client side? -Can you upload logs from WebRTC client and SIP client. (WebRTC/SIP/SIP stack) -Topology and browser version -Codec: VP8/H.264. This will help us to understand how media is handled. If you do a packet capture can you still see Browser sending Video to SIP Client after those initial 5-7 seconds. (Check Webrtc logs/packet capture) Some details about WebRTC handling packet loss. https://groups.google.com/forum/#!topic/discuss-webrtc/0ZbxO05a9Zk HTH Thanks -G On Thu, Jan 29, 2015 at 2:56 PM, Muhammad Shahzad <shaherya...@gmail.com> wrote: > Hi, > > This may be a bit out of focus topic for this forum but i am posting it > here anyway with hope that some guru would shed some light on it and point > me to right direction. > > The problem is that i want to establish video call between a webrtc and a > sip client using kamailio (for signalling) and RTPEngine (for media relay). > Both signalling and the audio stream seems to work perfectly fine The > remote video on webrtc client side (i.e. video stream from sip client) > takes about 20-30 seconds to establish but once it starts it works fine. > However, the remote video on sip client side (i.e. video stream from webrtc > client) starts almost immediately (within 3-5 seconds) but it gets stuck > after 1 or 2 seconds, then it goes blank after about 30 seconds. > > After a long discussion with sip client developer, we now understand the > fact that sip client sends a request for so called key-frame, which is > ignored by webrtc client. This request is sent through both RTCP stream and > SIP INFO message. > > The SIP INFO message seems to be pointless as media is internally managed > by chrome/firefox and these browsers don't give us such sophisticated > access and control over media streams. Please let me know if this > assumption is wrong. > > For the RTCP stream based request (RTCP-FIR), i only see "Invalid RTCP > packet type" error message in RTPEngine logs (not sure if it drops this > packet or relay it anyway). > > Does anyone has any idea on how can we either, > > 1. Force WebRTC client (running on Chrome / Firefox) to honor SIP INFO > message and issue a key-frame in RTP video stream in response to this SIP > request? > > OR > > 2. Force RTPEngine to accept RTCP-FIR and issue key-frame in RTP video > stream on webrtc client's behalf? > > If there is any other solution to this, please feel free to share. > > > Thank you. > > > > _______________________________________________ > 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
