16 May
2014
16 May
'14
9:45 a.m.
Hello!
During a call from classical SIP softphone to WebRTC there's no media from
the browser (Mozilla, the same result is for Chrome). In case of a call
from the browser to the softphone there's media flow from both sides.
The snippets from kamailio.cfg related to the problem case (SIP-->WebRTC)
are below.
OFFER:
$var(rtpp_flags) = "trust-address symmetric replace-origin
replace-session-connection";
$var(rtpp_flags) = $var(rtpp_flags) + " ICE=force";
$var(rtpp_flags) = $var(rtpp_flags) + " RTP/SAVPF";
rtpengine_offer($var(rtpp_flags));
ANSWER:
$var(rtpp_flags) = "trust-address symmetric replace-origin
replace-session-connection";
$var(rtpp_flags) = $var(rtpp_flags) + " ICE=remove";
$var(rtpp_flags) = $var(rtpp_flags) + " RTP/AVP";
rtp.log is attached.
Any help on this issue would be very appreciated.
with best regards,
Alexey
16 May
16 May
1:53 p.m.
On 05/16/14 02:45, Alexey Rybalko wrote:
Hello!
During a call from classical SIP softphone to WebRTC there's no media
from the browser (Mozilla, the same result is for Chrome). In case of a
call from the browser to the softphone there's media flow from both sides.
The snippets from kamailio.cfg related to the problem case
(SIP-->WebRTC) are below.
There's nothing wrong with the SDP bodies that I can see. I recall that
Firefox had or still has a problem with ICE role switching when ice-lite
is offered. It never completes ICE negotiation (never sends an STUN
packet with "use candidate") and so never starts DTLS handshake.
You can confirm that by doing a packet capture including the RTP ports
and inspecting the STUN packets. Chrome shouldn't have that problem
though, perhaps do another test run with it? You can send those capture
files to me if you'd like me to have a look.
cheers
17 May
17 May
3:30 a.m.
Hi Richard!
Just have tried an outgoing call to Chrome and Opera and it works fine.
Thank you for the clarification regarding ICE! Dump files and rtp logs
(Firefox, Chrome) I've sent to your email.
My little investigation brings the following :
- browsers (Firefox, Chrome and Opera) don't use "a=ice-lite" in their
SDP;
- Chrome and Opera take the role of ICE-CONTROLLING and provide
USE-CANDIDATE for the ICE-Lite peer (mediaproxy) for both "offer" and
"answer" cases;
- Firefox takes the role of ICE-CONTROLLING and provide USE-CANDIDATE in
case of the "offer" while it takes the role of ICE-CONTROLLED during the
"answer";
/means no media from WebRTC UA in the latter case/
Some other remarks.
During the call from Fire I saw a lot of "SRTP output wanted, but no crypto
suite was negotiated" messages from rtpengine. However DTLS is finally was
established. Is that one more issue of Firefox?
Looking in STUN section of the dump files I wonder why Chrome use more than
10 binding request (USE-CANDIDATE) for each candidate while Mozilla does
it just once.
regards,
Alexey
2014-05-16 14:53 GMT+04:00 Richard Fuchs <rfuchs(a)sipwise.com>om>:
There's nothing wrong with the SDP bodies that I can see. I recall that
Firefox had or still has a problem with ICE role switching when ice-lite
is offered. It never completes ICE negotiation (never sends an STUN
packet with "use candidate") and so never starts DTLS handshake.
You can confirm that by doing a packet capture including the RTP ports
and inspecting the STUN packets. Chrome shouldn't have that problem
though, perhaps do another test run with it? You can send those capture
files to me if you'd like me to have a look.
2:42 p.m.
Hi,
There finally was some progress on the ice-lite issue in Firefox over
the last week or two (after the bug report got stuck for months), so I'd
expect Firefox nightly to properly work with ice-lice in a couple of
days or so.
Andreas
On 05/17/2014 02:30 AM, Alexey Rybalko wrote:
Hi Richard!
Just have tried an outgoing call to Chrome and Opera and it works fine.
Thank you for the clarification regarding ICE! Dump files and rtp logs
(Firefox, Chrome) I've sent to your email.
My little investigation brings the following :
- browsers (Firefox, Chrome and Opera) don't use "a=ice-lite" in their
SDP;
- Chrome and Opera take the role of ICE-CONTROLLING and provide
USE-CANDIDATE for the ICE-Lite peer (mediaproxy) for both "offer" and
"answer" cases;
- Firefox takes the role of ICE-CONTROLLING and provide USE-CANDIDATE in
case of the "offer" while it takes the role of ICE-CONTROLLED during the
"answer";
/means no media from WebRTC UA in the latter case/
Some other remarks.
During the call from Fire I saw a lot of "SRTP output wanted, but no
crypto suite was negotiated" messages from rtpengine. However DTLS is
finally was established. Is that one more issue of Firefox?
Looking in STUN section of the dump files I wonder why Chrome use more
than 10 binding request (USE-CANDIDATE) for each candidate while
Mozilla does it just once.
regards,
Alexey
2014-05-16 14:53 GMT+04:00 Richard Fuchs <rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>>:
There's nothing wrong with the SDP bodies that I can see. I recall that
Firefox had or still has a problem with ICE role switching when ice-lite
is offered. It never completes ICE negotiation (never sends an STUN
packet with "use candidate") and so never starts DTLS handshake.
You can confirm that by doing a packet capture including the RTP ports
and inspecting the STUN packets. Chrome shouldn't have that problem
though, perhaps do another test run with it? You can send those capture
files to me if you'd like me to have a look.
_______________________________________________
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
20 May
20 May
3:15 p.m.
On 05/16/14 20:30, Alexey Rybalko wrote:
During the call from Fire I saw a lot of "SRTP
output wanted, but no
crypto suite was negotiated" messages from rtpengine. However DTLS is
finally was established. Is that one more issue of Firefox?
Some DTLS-SRTP endpoints seem to be slow with starting or accepting the
DTLS handshake. What I've seen in my tests was that some "active"
endpoints have a delay of a few seconds before they start the DTLS
handshake, while some "passive" endpoints only start accepting the DTLS
handshake after they've received the signalling answer (while the RFC
requires them to accept DTLS right away after sending the offer).
Both of these cases somewhat eliminate one of the advantages that
DTLS-SRTP has over SDES: it still breaks early media. If your RTP side
sends media before the SRTP side has finished the DTLS handshake, you
will lose packets and see those messages popping up. But I hope that
these issues will disappear as the code matures.
Looking in STUN section of the dump files I wonder why
Chrome use more
than 10 binding request (USE-CANDIDATE) for each candidate while
Mozilla does it just once.
I've noticed that too and I have no idea why it does that. Doesn't seem
to be causing any problems though.
cheers
16 May
16 May
3:09 p.m.
Hello Alexey,
I am uncertain as to whether rtpengine_offer()/answer() support
pseudovariable arguments. But if they do, you'll need to wrap them in a
string literal:
rtpengine_offer("$var(rtpp_flags)");
If they don't support PV arguments at all, you may be stuck with having
to provide a static argument:
rtpengine_offer("trust-address symmetric replace-origin
replace-session-connection ICE=force RTP/SAVPF");
-- Alex
On 05/16/2014 02:45 AM, Alexey Rybalko wrote:
Hello!
During a call from classical SIP softphone to WebRTC there's no media
from the browser (Mozilla, the same result is for Chrome). In case of a
call from the browser to the softphone there's media flow from both sides.
The snippets from kamailio.cfg related to the problem case
(SIP-->WebRTC) are below.
OFFER:
$var(rtpp_flags) = "trust-address symmetric replace-origin
replace-session-connection";
$var(rtpp_flags) = $var(rtpp_flags) + " ICE=force";
$var(rtpp_flags) = $var(rtpp_flags) + " RTP/SAVPF";
rtpengine_offer($var(rtpp_flags));
ANSWER:
$var(rtpp_flags) = "trust-address symmetric replace-origin
replace-session-connection";
$var(rtpp_flags) = $var(rtpp_flags) + " ICE=remove";
$var(rtpp_flags) = $var(rtpp_flags) + " RTP/AVP";
rtp.log is attached.
Any help on this issue would be very appreciated.
with best regards,
Alexey
_______________________________________________
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
--
Alex Balashov - Principal
Evariste Systems LLC
235 E Ponce de Leon Ave
Suite 106
Decatur, GA 30030
United States
Tel: +1-678-954-0670
Web: http://www.evaristesys.com/, http://www.alexbalashov.com/
17 May
17 May
3:34 a.m.
Hi, Alex!
I'm not experienced in Kamailio, but that code works well :)
Is there any difference between feeding the function with variable (AVP?)
or string literal?
best regards,
Alexey
2014-05-16 16:09 GMT+04:00 Alex Balashov <abalashov(a)evaristesys.com>om>:
Hello Alexey,
I am uncertain as to whether rtpengine_offer()/answer() support
pseudovariable arguments. But if they do, you'll need to wrap them in a
string literal:
rtpengine_offer("$var(rtpp_flags)");
If they don't support PV arguments at all, you may be stuck with having to
provide a static argument:
rtpengine_offer("trust-address symmetric replace-origin
replace-session-connection ICE=force RTP/SAVPF");
-- Alex
3842
days inactive
3846
days old
6 comments
4 participants
participants (4)
-
Alex Balashov -
Alexey Rybalko -
Andreas Granig -
Richard Fuchs