30 Jan
2015
30 Jan
'15
3:56 a.m.
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.
1 Feb
1 Feb
12:04 p.m.
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/arch…
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 <shaheryarkh(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:17 p.m.
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.
Thank you.
On Sun, Feb 1, 2015 at 8:04 AM, Gonzalo Gasca Meza <gascagonzalo(a)gmail.com>
wrote:
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/arch…
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 <shaheryarkh(a)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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2 Feb
2 Feb
2:36 a.m.
New subject: Video Key-Frame Request using RTCP FIR or SIP INFO message
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
11:38 a.m.
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 <rfuchs(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
2:28 a.m.
On 29 Jan 2015, at 23:56, Muhammad Shahzad <shaheryarkh(a)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?
Talk with the SIP
stack developer. I don't know if it's possible at all and I think using SIP info
for this is
more or less the old way. Sending it in the actual media stream feels like a more modern
and better way.
OR
2. Force RTPEngine to accept RTCP-FIR and issue key-frame in RTP video stream on webrtc
client's behalf?
File a bug report with the RTPengine team. It's clearly
something they need to support.
/O
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
3381
days inactive
3385
days old
5 comments
4 participants
participants (4)
-
Gonzalo Gasca Meza -
Muhammad Shahzad -
Olle E. Johansson -
Richard Fuchs