27 Jan
2014
27 Jan
'14
10:38 p.m.
Hello Sirs,
I have a problem configuring kamailio with mediaproxy-ng and I'm asking for
help.
I managed to build everything, kamailio find support for mediaproxy-ng
using rtpproxy-ng. When I'm trying to make a call from Web using my phone's
internet provider to my computer's web I get 488 Not Acceptable Here.
Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket
support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log:
mediaproxy-ng[14896]: Returning to SIP proxy:
d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but
unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised
peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised
peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24
n=rtpproxy_manage
11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy
reply: d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known
but unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised
peer addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised
peer addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag
11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25 n=add_rr_param
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled
11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG: t_check_msg:
msg id=2 global id=2 T start=0x7f62174df4e0
11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG: t_check_msg: T
already found!
11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply:
branch=0, save=0, relay=0 icode=0
11(14926) DEBUG: <core> [msg_translator.c:2007]:
generate_res_buf_from_sip_res(): old size: 397, new size: 305
11(14926) DEBUG: <core> [msg_translator.c:2025]:
generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest: 272
msg=
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296
To: <sip:bob@93.187.138.214>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx
message:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296
To: <sip:bob@93.187.138.214>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
Thank you.
Best regards,
Mihai M
29 Jan
29 Jan
12:31 p.m.
Hi!
The problem is different SDP formats between normal SIP
clients/gateways, and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the
conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the "gatewaying",
or the webrtc clients uses eg. an encryption which is not supported by
mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng and
give details about your environment (browser, SIP client ...)
regards
Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs,
I have a problem configuring kamailio with mediaproxy-ng and I'm asking
for help.
I managed to build everything, kamailio find support for mediaproxy-ng
using rtpproxy-ng. When I'm trying to make a call from Web using my
phone's internet provider to my computer's web I get 488 Not Acceptable
Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket
support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log:
mediaproxy-ng[14896]: Returning to SIP proxy:
d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but
unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised
peer addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24
n=rtpproxy_manage
11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply:
d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but
unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised
peer addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag
11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25 n=add_rr_param
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24 n=t_is_canceled
11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG:
t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0
11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG:
t_check_msg: T already found!
11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply:
branch=0, save=0, relay=0 icode=0
11(14926) DEBUG: <core> [msg_translator.c:2007]:
generate_res_buf_from_sip_res(): old size: 397, new size: 305
11(14926) DEBUG: <core> [msg_translator.c:2025]:
generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest:
272 msg=
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296
To: <sip:bob@93.187.138.214
<mailto:sip%3Abob@93.187.138.214>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx
message:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=z9hG4bK8048296
To: <sip:bob@93.187.138.214
<mailto:sip%3Abob@93.187.138.214>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
Thank you.
Best regards,
Mihai M
_______________________________________________
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
12:53 p.m.
Hello,
Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip framework
for sip client - tried sipml5 also. I have attached to this e-mail my
kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from git
- also tried with kamailio 4.1.1. The mediaproxy-ng I'm running using the
command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng --ip=PUBLIC_IP --listen-ng=
127.0.0.1:2222
I also tried the following configuration and I have the same error:
route {
......................
##################################################################################################################
# Use RTP-Proxy
###############################################################################################################
#if (!rtpproxy_offer("arf")) {
# sl_send_reply("503", "No RTP-Relay available");
# exit;
#}
if (is_method("INVITE")) {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
t_on_reply("1");
}
} else {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
}
}
if (is_method("ACK") && sdp_content()) {
rtpproxy_answer();
rtpproxy_manage("cowf","PUBLIC_IP");
}
#t_on_reply("1");
# Relay this statefully
t_relay();
...............................................................
*******************************************************************
onreply_route[1] {
if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT)
&& !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) {
xlog("L_WARN", "SIP response received on $Rp\n");
drop;
exit;
}
if (nat_uac_test(64)) {
# Do NAT traversal stuff for replies to a WebSocket connection
# - even if it is not behind a NAT!
# This won't be needed in the future if Kamailio and the
# WebSocket client support Outbound and Path.
add_contact_alias();
}
# A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy!
if (status=~"(180)|(183)|(2[0-9][0-9])") {
fix_nated_contact();
if (sdp_content()) {
rtpproxy_answer();
}
}
}
If my problem could be caused by a kamalio miss-configuration could you
please send me an example of configuration that should work with
websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible
cause?
Thank you.
Best regards,
Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
Hi!
The problem is different SDP formats between normal SIP clients/gateways,
and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the
conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the "gatewaying", or
the webrtc clients uses eg. an encryption which is not supported by
mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng and
give details about your environment (browser, SIP client ...)
regards
Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs,
I have a problem configuring kamailio with mediaproxy-ng and I'm asking
for help.
I managed to build everything, kamailio find support for mediaproxy-ng
using rtpproxy-ng. When I'm trying to make a call from Web using my
phone's internet provider to my computer's web I get 488 Not Acceptable
Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket
support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log:
mediaproxy-ng[14896]: Returning to SIP proxy:
d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but
unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:
porti48279ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:
porti48280ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised
peer addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:
bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:
errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:
packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=860 a=24
n=rtpproxy_manage
11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply:
d7:createdi1390864117e7:streamslld3:tag10:trhh9viigs6:status34:known but
unconfirmed peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:
porti48279ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48279ee10:local
porti30008ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:address13:213.233.85.554:
porti48280ee23:advertised
peer
addressd6:family4:IPv47:address13:213.233.85.554:porti48280ee10:local
porti30009eeeed3:tag0:6:status20:unknown peer
address5:statsd3:rtpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised
peer addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:countersd7:packetsi0e5:bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:address2:::4:porti0ee23:advertised peer
addressd6:family4:IPv67:address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:inputd3:rtpd7:packetsi0e5:
bytesi0e6:errorsi0ee4:rtcpd7:packetsi0e5:bytesi0e6:
errorsi0eee6:outputd3:rtpd7:packetsi0e5:bytesi0e6:errorsi0ee4:rtcpd7:
packetsi0e5:bytesi0e6:errorsi0eeee6:result2:oke
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=862 a=24 n=is_request
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=866 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=863 a=24 n=has_totag
11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=864 a=25
n=add_rr_param
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=867 a=24 n=is_reply
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=873 a=2 n=return
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=1009 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-advanced.cfg] l=989 a=24
n=t_is_canceled
11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG:
t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0
11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG:
t_check_msg: T already found!
11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG: relay_reply:
branch=0, save=0, relay=0 icode=0
11(14926) DEBUG: <core> [msg_translator.c:2007]:
generate_res_buf_from_sip_res(): old size: 397, new size: 305
11(14926) DEBUG: <core> [msg_translator.c:2025]:
generate_res_buf_from_sip_res(): copied size: orig:125, new: 33, rest:
272 msg=
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=
z9hG4bK8048296
To: <sip:bob@93.187.138.214
<mailto:sip%3Abob@93.187.138.214>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx
message:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=1034;received=213.233.85.55;branch=
z9hG4bK8048296
To: <sip:bob@93.187.138.214
<mailto:sip%3Abob@93.187.138.214>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
Thank you.
Best regards,
Mihai M
_______________________________________________
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
1:57 p.m.
Peter had a talk at Astricon 2013 presenting how it works. I think the
magic lies on the parameters. See this slide (there are some more
interesting slides)
https://www.youtube.com/watch?list=PLighc-2vlRgQHZMBp-8CCFi5otCnw7Lwj&v…
regards
Klaus
On 29.01.2014 12:53, Mihai Marin wrote:
Hello,
Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip
framework for sip client - tried sipml5 also. I have attached to this
e-mail my kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from
git - also tried with kamailio 4.1.1. The mediaproxy-ng I'm running
using the command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng
--ip=PUBLIC_IP --listen-ng=127.0.0.1:2222 <http://127.0.0.1:2222>
I also tried the following configuration and I have the same error:
route {
......................
##################################################################################################################
# Use RTP-Proxy
###############################################################################################################
#if (!rtpproxy_offer("arf")) {
#sl_send_reply("503", "No RTP-Relay available");
#exit;
#}
if (is_method("INVITE")) {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
t_on_reply("1");
}
} else {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
}
}
if (is_method("ACK") && sdp_content()) {
rtpproxy_answer();
rtpproxy_manage("cowf","PUBLIC_IP");
}
#t_on_reply("1");
# Relay this statefully
t_relay();
...............................................................
*******************************************************************
onreply_route[1] {
if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT)
&& !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) {
xlog("L_WARN", "SIP response received on $Rp\n");
drop;
exit;
}
if (nat_uac_test(64)) {
# Do NAT traversal stuff for replies to a WebSocket connection
# - even if it is not behind a NAT!
# This won't be needed in the future if Kamailio and the
# WebSocket client support Outbound and Path.
add_contact_alias();
}
# A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy!
if (status=~"(180)|(183)|(2[0-9][0-9])") {
fix_nated_contact();
if (sdp_content()) {
rtpproxy_answer();
}
}
}
If my problem could be caused by a kamalio miss-configuration could you
please send me an example of configuration that should work with
websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible
cause?
Thank you.
Best regards,
Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>> wrote:
Hi!
The problem is different SDP formats between normal SIP
clients/gateways, and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the
conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the
"gatewaying", or the webrtc clients uses eg. an encryption which is
not supported by mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng
and give details about your environment (browser, SIP client ...)
regards
Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs,
I have a problem configuring kamailio with mediaproxy-ng and I'm
asking
for help.
I managed to build everything, kamailio find support for
mediaproxy-ng
using rtpproxy-ng. When I'm trying to make a call from Web using my
phone's internet provider to my computer's web I get 488 Not
Acceptable
Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added websocket
support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log:
mediaproxy-ng[14896]: Returning to SIP proxy:
d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known
but
unconfirmed peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee10:local
porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee10:local
porti30009eeeed3:tag0:6:__status20:unknown peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer
addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=860 a=24
n=rtpproxy_manage
11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]:
rtpp_function_call():
proxy reply:
d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:__status34:known
but
unconfirmed peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48279ee10:local
porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__porti48280ee10:local
porti30009eeeed3:tag0:6:__status20:unknown peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised peer
addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=862 a=24
n=is_request
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=866 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=863 a=24
n=has_totag
11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=864 a=25
n=add_rr_param
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=24
n=is_reply
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=2
n=return
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=1009 a=16 n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=989 a=24
n=t_is_canceled
11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG:
t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0
11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG:
t_check_msg: T already found!
11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG:
relay_reply:
branch=0, save=0, relay=0 icode=0
11(14926) DEBUG: <core> [msg_translator.c:2007]:
generate_res_buf_from_sip_res(__): old size: 397, new size: 305
11(14926) DEBUG: <core> [msg_translator.c:2025]:
generate_res_buf_from_sip_res(__): copied size: orig:125, new:
33, rest:
272 msg=
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55
<tel:213.233.85.55>;branch=__z9hG4bK8048296
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>
<mailto:sip%3Abob@93.187.138.__214
<mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>
<mailto:sip%3Aalice@93.187.__138.214
<mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit(): Tx
message:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55
<tel:213.233.85.55>;branch=__z9hG4bK8048296
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>
<mailto:sip%3Abob@93.187.138.__214
<mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>
<mailto:sip%3Aalice@93.187.__138.214
<mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
Thank you.
Best regards,
Mihai M
_________________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users
<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 <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users
<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
3 Feb
3 Feb
noon
Hello,
Another weekend struggling to make a call from jssip to another jssip
behind firewall and I still receive 488 - Not Acceptable Here. I tried all
the ideas that I had/received without any success - including catch 488 and
re-invite.
request_route {
# per request initial checks
route(REQINIT);
# websockets
route(WSDETECT);
# NAT detection
route(NATDETECT);
.........
}
route[WITHINDLG] {
if (has_totag()) {
# sequential request withing a dialog should
# take the path determined by record-routing
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
setflag(FLT_ACC); # do accounting ...
setflag(FLT_ACCFAILED); # ... even if the transaction fails
}
else if ( is_method("ACK") ) {
route(NATMANAGE);
.................
}
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
fix_nated_register();
} else {
add_contact_alias();
}
setflag(FLT_NATS);
}
#!endif
return;
}
# RTPProxy control
route[NATMANAGE] {
#!ifdef WITH_NAT
if (is_request()) {
if(has_totag()) {
if(check_route_param("nat=yes")) {
setbflag(FLB_NATB);
}
}
}
if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB)))
return;
#tried this
rtpproxy_manage("+","93.187.138.214");
#tried this too
#if (is_request()) {
# if (is_direction("downstream"))
# rtpproxy_manage("1FOII");
# else
# rtpproxy_manage("1FOIIR");
#} else {
# if (is_direction("downstream"))
# rtpproxy_manage("2FOIIR");
# else
# rtpproxy_manage("2FOII");
#}
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
add_contact_alias();
}
}
#!endif
return;
}
failure_route[MANAGE_FAILURE] {
t_on_failure("UA_FAILURE");
...
}
failure_route[UA_FAILURE] {
if (t_check_status("488") && sdp_content()) {
if (sdp_get_line_startswith("$avp(mline)", "m=")) {
if ($avp(mline) =~ "SAVPF") {
$avp(rtpproxy_offer_flags) = "frocsp";
$avp(rtpproxy_answer_flags) = "froc+SP";
} else {
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "frocsp";
}
# In a production system you probably need to catch
# "RTP/SAVP" and "RTP/AVPF" and handle them correctly
# too
}
append_branch();
rtpproxy_offer($avp(rtpproxy_offer_flags));
t_on_reply("RTPPROXY_REPLY");
route(RELAY);
}
}
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
On Wed, Jan 29, 2014 at 2:57 PM, Klaus Darilion <
klaus.mailinglists(a)pernau.at> wrote:
Peter had a talk at Astricon 2013 presenting how it
works. I think the
magic lies on the parameters. See this slide (there are some more
interesting slides)
https://www.youtube.com/watch?list=PLighc-2vlRgQHZMBp-
8CCFi5otCnw7Lwj&v=rXsVSaRuv20&feature=player_detailpage#t=659
regards
Klaus
On 29.01.2014 12:53, Mihai Marin wrote:
Hello,
Thank you for your answer.
My server is a centos with public ip. I'm using chrome with jssip
framework for sip client - tried sipml5 also. I have attached to this
e-mail my kamailio configuration.
Regarding the kamailio + mediaproxy-ng I took the latest versions from
git - also tried with kamailio 4.1.1. The mediaproxy-ng I'm running
using the command: /tmp/mediaproxy-ng/daemon/mediaproxy-ng
--ip=PUBLIC_IP --listen-ng=127.0.0.1:2222 <http://127.0.0.1:2222>
I also tried the following configuration and I have the same error:
route {
......................
############################################################
######################################################
# Use RTP-Proxy
############################################################
###################################################
#if (!rtpproxy_offer("arf")) {
#sl_send_reply("503", "No RTP-Relay available");
#exit;
#}
if (is_method("INVITE")) {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
t_on_reply("1");
}
} else {
if (sdp_content()) {
if (rtpproxy_offer())
rtpproxy_manage("cowf","PUBLIC_IP");
}
}
if (is_method("ACK") && sdp_content()) {
rtpproxy_answer();
rtpproxy_manage("cowf","PUBLIC_IP");
}
#t_on_reply("1");
# Relay this statefully
t_relay();
...............................................................
*******************************************************************
onreply_route[1] {
if ((($Rp == MY_WS_PORT || $Rp == MY_WSS_PORT)
&& !(proto == WS || proto == WSS)) || $Rp == MY_MSRP_PORT) {
xlog("L_WARN", "SIP response received on $Rp\n");
drop;
exit;
}
if (nat_uac_test(64)) {
# Do NAT traversal stuff for replies to a WebSocket connection
# - even if it is not behind a NAT!
# This won't be needed in the future if Kamailio and the
# WebSocket client support Outbound and Path.
add_contact_alias();
}
# A Transaction from a NATed Client to a NATed Client? Use the RTP-Proxy!
if (status=~"(180)|(183)|(2[0-9][0-9])") {
fix_nated_contact();
if (sdp_content()) {
rtpproxy_answer();
}
}
}
If my problem could be caused by a kamalio miss-configuration could you
please send me an example of configuration that should work with
websockets, rtpproxy-ng->mediaproxy-ng in order to remove one possible
cause?
Thank you.
Best regards,
Mihai M
On Wed, Jan 29, 2014 at 1:31 PM, Klaus Darilion
<klaus.mailinglists(a)pernau.at <mailto:klaus.mailinglists@pernau.at>>
wrote:
Hi!
The problem is different SDP formats between normal SIP
clients/gateways, and WebRTC clients.
You have to instruct mediaproxy-ng to rewrite the SDP and do the
conversion (encryption, ...).
So either the rtpproxy_ng calls lack the commands for the
"gatewaying", or the webrtc clients uses eg. an encryption which is
not supported by mediaproxy-ng.
Please also post the kamailio.cfg snippets when calling rtpproxy_ng
and give details about your environment (browser, SIP client ...)
regards
Klaus
On 27.01.2014 22:38, Mihai Marin wrote:
Hello Sirs,
I have a problem configuring kamailio with mediaproxy-ng and I'm
asking
for help.
I managed to build everything, kamailio find support for
mediaproxy-ng
using rtpproxy-ng. When I'm trying to make a call from Web using
my
phone's internet provider to my computer's web I get 488 Not
Acceptable
Here. Swithing the caller I get no video.
I have used the kamailio-advanced.cfg generated and added
websocket
support. The call in my network is working perfect.
Can you help me with this?
mediaproxy-ng log:
mediaproxy-ng[14896]: Returning to SIP proxy:
d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:
__status34:known
but
unconfirmed peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48279ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48279ee10:local
porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48280ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48280ee10:local
porti30009eeeed3:tag0:6:__status20:unknown peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer
addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__
bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__
errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__
errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke
kamailio:
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=860 a=24
n=rtpproxy_manage
11(14926) DEBUG: rtpproxy-ng [rtpproxy.c:1333]:
rtpp_function_call():
proxy reply:
d7:createdi1390864117e7:__streamslld3:tag10:trhh9viigs6:
__status34:known
but
unconfirmed peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48279ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48279ee10:local
porti30008ee4:rtcpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48280ee23:advertised
peer
addressd6:family4:IPv47:__address13:213.233.85.554:__
porti48280ee10:local
porti30009eeeed3:tag0:6:__status20:unknown peer
address5:statsd3:rtpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30010ee4:rtcpd8:__countersd7:packetsi0e5:__
bytesi0e6:errorsi0ee12:peer
addressd6:family4:IPv67:__address2:::4:porti0ee23:__advertised
peer
addressd6:family4:IPv67:__address2:::4:porti0ee10:local
porti30011eeeeee6:totalsd5:__inputd3:rtpd7:packetsi0e5:__
bytesi0e6:errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__
errorsi0eee6:outputd3:rtpd7:__packetsi0e5:bytesi0e6:__
errorsi0ee4:rtcpd7:__packetsi0e5:bytesi0e6:__errorsi0eeee6:result2:oke
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=16
n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=862 a=24
n=is_request
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=866 a=16
n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=863 a=24
n=has_totag
11(14926) DEBUG: siputils [checks.c:103]: has_totag(): no totag
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=864 a=25
n=add_rr_param
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=16
n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=867 a=24
n=is_reply
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=873 a=2
n=return
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=1009 a=16
n=if
11(14926) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/__kamailio-advanced.cfg] l=989 a=24
n=t_is_canceled
11(14926) DEBUG: tm [t_lookup.c:1071]: t_check_msg(): DEBUG:
t_check_msg: msg id=2 global id=2 T start=0x7f62174df4e0
11(14926) DEBUG: tm [t_lookup.c:1143]: t_check_msg(): DEBUG:
t_check_msg: T already found!
11(14926) DEBUG: tm [t_reply.c:1827]: relay_reply(): DEBUG:
relay_reply:
branch=0, save=0, relay=0 icode=0
11(14926) DEBUG: <core> [msg_translator.c:2007]:
generate_res_buf_from_sip_res(__): old size: 397, new size: 305
11(14926) DEBUG: <core> [msg_translator.c:2025]:
generate_res_buf_from_sip_res(__): copied size: orig:125, new:
33, rest:
272 msg=
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55
<tel:213.233.85.55>;branch=__z9hG4bK8048296
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>
<mailto:sip%3Abob@93.187.138.__214
<mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>
<mailto:sip%3Aalice@93.187.__138.214
<mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
11(14926) DEBUG: websocket [ws_frame.c:713]: ws_frame_transmit():
Tx
message:
SIP/2.0 488 Not Acceptable Here
Via: SIP/2.0/WS
ebhg3v0qb6fm.invalid;rport=__1034;received=213.233.85.55
<tel:213.233.85.55>;branch=__z9hG4bK8048296
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>
<mailto:sip%3Abob@93.187.138.__214
<mailto:sip%253Abob@93.187.138.214>>>;tag=r6dc2287g9
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>
<mailto:sip%3Aalice@93.187.__138.214
<mailto:sip%253Aalice@93.187.138.214>>>;tag=trhh9viigs
Call-ID: fvgga4ikm8vrvuji0g0n
CSeq: 6228 INVITE
Content-Length: 0
Thank you.
Best regards,
Mihai M
_________________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-
router.org>
http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users<
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 <mailto:sr-users@lists.sip-router.org>
http://lists.sip-router.org/__cgi-bin/mailman/listinfo/sr-__users
<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
_______________________________________________
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
4 Feb
4 Feb
1:49 p.m.
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients without video support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
Hello,
Another weekend struggling to make a call from jssip to another jssip
behind firewall and I still receive 488 - Not Acceptable Here. I tried
all the ideas that I had/received without any success - including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
3:28 p.m.
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have attached the logs
from jssip (with and without video support) and logs from kamailio when
trying a call with video support enabled. The kamailio.cfg used is the same
from my previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk <apogrebennyk(a)sipwise.com
wrote:
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients without video
support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
Hello,
Another weekend struggling to make a call from jssip to another jssip
behind firewall and I still receive 488 - Not Acceptable Here. I tried
all the ideas that I had/received without any success - including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
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
9:45 p.m.
There are several problems that need to be addressed in your kamailio.cfg
but let me try to focus only on mediaprxoy-ng related ones.
First instead of engaging mediaproxy in failure route, engage it main route
or branch route. Why wait for failure when we know call will fail anyway if
you try to call webrtc to sip or vice versa.
Secondly you need to keep track of connection type of both caller and
callee and set appropriate mediaproxy-ng flags according to call direction,
e.g. call from webrtc to sip, or sip to webrtc or webrtc to webrtc or sip
to sip, each type of call needs different set of flags for both
rtpproxy_offer and rtpproxy_answer.
How you do this, is pretty simple, to detect if caller is webrtc endpoint
you can use,
if ($avp(mline) =~ "SAVPF") {
# caller is a webrtc endpoint
};
To check if callee is a webrtc endpoint, you can use,
if ($(ru{uri.param,transport}) =~ "ws") {
# callee is a webrtc endpoint
};
For testing purpose, i recommend you only use mediaproxy-ng for bridging
webrtc to sip or vice versa calls, i.e. if both endpoints are using same
transport (e.g. sip to sip or webrtc to webrtc calls) then don't use
mediaproxy-ng at all and allow endpoints to establish media directly (that
would work out the box at least for webrtc to webrtc calls).
Finally use correct flags for each type of call (i recommend doing it in
branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS, which is
required by firefox, so as result your webrtc endpoint MUST be running on
Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin <marinmihai(a)gmail.com> wrote:
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have attached the logs
from jssip (with and without video support) and logs from kamailio when
trying a call with video support enabled. The kamailio.cfg used is the same
from my previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk <
apogrebennyk(a)sipwise.com> wrote:
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients without video
support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
_______________________________________________
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
Hello,
Another weekend struggling to make a call from jssip to another jssip
behind firewall and I still receive 488 - Not Acceptable Here. I tried
all the ideas that I had/received without any success - including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
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
5 Feb
5 Feb
11:17 a.m.
Hello,
Thank you for your detailed explication but I miss some information or I'm
unable to understand it properly. What I'm trying to do is to use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at least
one is behind restrictive firewall). Trying to replicate what you explained
on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is obvious
but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad <shaheryarkh(a)gmail.com>wrote;wrote:
There are several problems that need to be addressed
in your kamailio.cfg
but let me try to focus only on mediaprxoy-ng related ones.
First instead of engaging mediaproxy in failure route, engage it main
route or branch route. Why wait for failure when we know call will fail
anyway if you try to call webrtc to sip or vice versa.
Secondly you need to keep track of connection type of both caller and
callee and set appropriate mediaproxy-ng flags according to call direction,
e.g. call from webrtc to sip, or sip to webrtc or webrtc to webrtc or sip
to sip, each type of call needs different set of flags for both
rtpproxy_offer and rtpproxy_answer.
How you do this, is pretty simple, to detect if caller is webrtc endpoint
you can use,
if ($avp(mline) =~ "SAVPF") {
# caller is a webrtc endpoint
};
To check if callee is a webrtc endpoint, you can use,
if ($(ru{uri.param,transport}) =~ "ws") {
# callee is a webrtc endpoint
};
For testing purpose, i recommend you only use mediaproxy-ng for bridging
webrtc to sip or vice versa calls, i.e. if both endpoints are using same
transport (e.g. sip to sip or webrtc to webrtc calls) then don't use
mediaproxy-ng at all and allow endpoints to establish media directly (that
would work out the box at least for webrtc to webrtc calls).
Finally use correct flags for each type of call (i recommend doing it in
branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS, which is
required by firefox, so as result your webrtc endpoint MUST be running on
Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin <marinmihai(a)gmail.com> wrote:
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have attached the
logs from jssip (with and without video support) and logs from kamailio
when trying a call with video support enabled. The kamailio.cfg used is the
same from my previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk <
apogrebennyk(a)sipwise.com> wrote:
_______________________________________________
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
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients without video
support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
_______________________________________________
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
Hello,
Another weekend struggling to make a call from jssip to another jssip
behind firewall and I still receive 488 - Not Acceptable Here. I tried
all the ideas that I had/received without any success - including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
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
4:41 p.m.
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC endpoint
with a non-WebRTC one, which is usually what people are trying to do.
In your case, the flags "froc" in either direction should be sufficient
to get the job done. If it still doesn't work, can you please post the
rejected SDP body as it appears both on the sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
Hello,
Thank you for your detailed explication but I miss some information or
I'm unable to understand it properly. What I'm trying to do is to use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at least
one is behind restrictive firewall). Trying to replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad <shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>> wrote:
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng related ones.
First instead of engaging mediaproxy in failure route, engage it
main route or branch route. Why wait for failure when we know call
will fail anyway if you try to call webrtc to sip or vice versa.
Secondly you need to keep track of connection type of both caller
and callee and set appropriate mediaproxy-ng flags according to call
direction, e.g. call from webrtc to sip, or sip to webrtc or webrtc
to webrtc or sip to sip, each type of call needs different set of
flags for both rtpproxy_offer and rtpproxy_answer.
How you do this, is pretty simple, to detect if caller is webrtc
endpoint you can use,
if ($avp(mline) =~ "SAVPF") {
# caller is a webrtc endpoint
};
To check if callee is a webrtc endpoint, you can use,
if ($(ru{uri.param,transport}) =~ "ws") {
# callee is a webrtc endpoint
};
For testing purpose, i recommend you only use mediaproxy-ng for
bridging webrtc to sip or vice versa calls, i.e. if both endpoints
are using same transport (e.g. sip to sip or webrtc to webrtc calls)
then don't use mediaproxy-ng at all and allow endpoints to establish
media directly (that would work out the box at least for webrtc to
webrtc calls).
Finally use correct flags for each type of call (i recommend doing
it in branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS, which
is required by firefox, so as result your webrtc endpoint MUST be
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin <marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>> wrote:
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have
attached the logs from jssip (with and without video support)
and logs from kamailio when trying a call with video support
enabled. The kamailio.cfg used is the same from my previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com <mailto:apogrebennyk@sipwise.com>> wrote:
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients
without video support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
Hello,
Another weekend struggling to make a call from jssip to
another jssip
behind firewall and I still receive 488 - Not
Acceptable
Here. I tried
all the ideas that I had/received without any
success -
including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto: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(a)lists.sip-router.org <mailto: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(a)lists.sip-router.org <mailto: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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
5:23 p.m.
Hello,
I'm trying the simplest case first. I don't understand why you are saying
that most of the people don't use mediaproxy-ng for WebRTC to WebRTC calls.
If my firewall is a restrictive one I need to use turn server and
mediaproxy-ng can do turn too? Probably I'm not seeing the big picture.
Regarding the problem with Incompatible SDP I have attached the SDP before
mp-ng and after:
BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
message:
INVITE sip:bob@93.187.138.214 SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214>
From: "Alice Test" <sip:alice@93.187.138.214>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967
v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy
reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host generation
0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx raddr
10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host
Between them, I have some strange logs in kamailio:
14(21473) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ssrc:3207772497
label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]: check_content_type():
type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call(): proxy
reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
Thank you very much for your help and for spending time debugging this
error.
Best regards,
Mihai M
On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC endpoint
with a non-WebRTC one, which is usually what people are trying to do.
In your case, the flags "froc" in either direction should be sufficient
to get the job done. If it still doesn't work, can you please post the
rejected SDP body as it appears both on the sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
Hello,
Thank you for your detailed explication but I miss some information or
I'm unable to understand it properly. What I'm trying to do is to use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at least
one is behind restrictive firewall). Trying to replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad <shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>> wrote:
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng related
ones.
First instead of engaging mediaproxy in failure route, engage it
main route or branch route. Why wait for failure when we know call
will fail anyway if you try to call webrtc to sip or vice versa.
Secondly you need to keep track of connection type of both caller
and callee and set appropriate mediaproxy-ng flags according to call
direction, e.g. call from webrtc to sip, or sip to webrtc or webrtc
to webrtc or sip to sip, each type of call needs different set of
flags for both rtpproxy_offer and rtpproxy_answer.
How you do this, is pretty simple, to detect if caller is webrtc
endpoint you can use,
if ($avp(mline) =~ "SAVPF") {
# caller is a webrtc endpoint
};
To check if callee is a webrtc endpoint, you can use,
if ($(ru{uri.param,transport}) =~ "ws") {
# callee is a webrtc endpoint
};
For testing purpose, i recommend you only use mediaproxy-ng for
bridging webrtc to sip or vice versa calls, i.e. if both endpoints
are using same transport (e.g. sip to sip or webrtc to webrtc calls)
then don't use mediaproxy-ng at all and allow endpoints to establish
media directly (that would work out the box at least for webrtc to
webrtc calls).
Finally use correct flags for each type of call (i recommend doing
it in branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS, which
is required by firefox, so as result your webrtc endpoint MUST be
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin <marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>> wrote:
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have
attached the logs from jssip (with and without video support)
and logs from kamailio when trying a call with video support
enabled. The kamailio.cfg used is the same from my previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com <mailto:apogrebennyk@sipwise.com>>
wrote:
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients
without video support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
Another weekend struggling to make a call from jssip to
another jssip
behind firewall and I still receive 488 - Not
Acceptable
Here. I tried
all the ideas that I had/received without any
success -
including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org <mailto:
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
<mailto: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(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
6 Feb
6 Feb
2:43 p.m.
Hey,
What mediaproxy-ng can do (which other RTP proxies don't do) is
translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
(encrypted RTP from WebRTC), which is what people usually use it for.
Assuming that ICE does its job correctly, two WebRTC endpoints should be
able to communicate directly with each other (without RTP proxy), even
if a firewall is involved. But I understand that in some cases even ICE
might fail.
There's two things I see wrong with the resulting SDP body, both related
to the last stable version of MP-NG not supporting BUNDLE. If you could
try adding an SDP rewrite rule to your kamailio config to remove the
a=group:... line. If that doesn't work, also try disabling video when
making the call.
Alternatively, you can try building MP-NG from this branch:
https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
This is currently under heavy development, but it should support BUNDLE
just enough to make this work.
cheers
On 02/05/14 11:23, Mihai Marin wrote:
Hello,
I'm trying the simplest case first. I don't understand why you are
saying that most of the people don't use mediaproxy-ng
for WebRTC to WebRTC calls. If my firewall is a restrictive one I need
to use turn server and mediaproxy-ng can do turn too? Probably I'm not
seeing the big picture.
Regarding the problem with Incompatible SDP I have attached the SDP
before mp-ng and after:
BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
message:
INVITE sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>>
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967
v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431 93.187.138.214 30409 typ host
Between them, I have some strange logs in kamailio:
14(21473) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ssrc:3207772497
label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:
check_content_type(): type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
Thank you very much for your help and for spending time debugging this
error.
Best regards,
Mihai M
On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>> wrote:
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC endpoint
with a non-WebRTC one, which is usually what people are trying to do.
In your case, the flags "froc" in either direction should be sufficient
to get the job done. If it still doesn't work, can you please post the
rejected SDP body as it appears both on the sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Hello,
Thank you for your detailed explication but I miss some information or
I'm unable to understand it properly. What I'm trying to do is to use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at
least
one is behind restrictive firewall). Trying to
replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad
<shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>
<mailto:shaheryarkh@gmail.com
<mailto:shaheryarkh@gmail.com>>> wrote:
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng
related ones.
First instead of engaging mediaproxy in failure route, engage it
main route or branch route. Why wait for failure when we know call
will fail anyway if you try to call webrtc to sip or vice versa.
Secondly you need to keep track of connection type of both caller
and callee and set appropriate mediaproxy-ng flags according
to call
direction, e.g. call from webrtc to sip, or
sip to webrtc or
webrtc
to webrtc or sip to sip, each type of call
needs different set of
flags for both rtpproxy_offer and rtpproxy_answer.
How you do this, is pretty simple, to detect if caller is webrtc
endpoint you can use,
if ($avp(mline) =~ "SAVPF") {
# caller is a webrtc endpoint
};
To check if callee is a webrtc endpoint, you can use,
if ($(ru{uri.param,transport}) =~ "ws") {
# callee is a webrtc endpoint
};
For testing purpose, i recommend you only use mediaproxy-ng for
bridging webrtc to sip or vice versa calls, i.e. if both endpoints
are using same transport (e.g. sip to sip or webrtc to webrtc
calls)
then don't use mediaproxy-ng at all and
allow endpoints to
establish
media directly (that would work out the box
at least for webrtc to
webrtc calls).
Finally use correct flags for each type of call (i recommend doing
it in branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS,
which
is required by firefox, so as result your
webrtc endpoint MUST be
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin
<marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>
<mailto:marinmihai@gmail.com
<mailto:marinmihai@gmail.com>>>
wrote:
Hello,
Thank you for your support.
Yes, I have the same error without video enabled. I have
attached the logs from jssip (with and without video support)
and logs from kamailio when trying a call with video support
enabled. The kamailio.cfg used is the same from my
previous mail.
I also tried with sipml5 and I have the same behavior.
I'm stuck on this error and I think I'm looking in the wrong
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com
<mailto:apogrebennyk@sipwise.com>
<mailto:apogrebennyk@sipwise.com
<mailto:apogrebennyk@sipwise.com>>> wrote:
Hi,
could you please post also your Chrome js developer log?
Does the problem exist if you start the jssip clients
without video support?
Andrew
On 02/03/2014 12:00 PM, Mihai Marin wrote:
<mailto:sr-users@lists.sip-router.org>
Hello,
Another weekend struggling to make a call from jssip to
another jssip
behind firewall and I still receive 488 - Not
Acceptable
Here. I tried
all the ideas that I had/received without any
success -
including catch
488 and re-invite.
[...]
What do I miss from my configuration?
Thank you.
Best regards,
Mihai M
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto: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(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto: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(a)lists.sip-router.org
<mailto: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(a)lists.sip-router.org <mailto: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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
7:34 p.m.
Hello,
Hope you don't mind if I borrow this topic to place a question or request.
In past days I successfully setup Kamailio in my local network and made
successful WebRTC to WebRTC and SIP to SIP calls. The problem is with WebRTC
to SIP call. I also added mediaproxy-ng by following instructions found on
https://github.com/sipwise/mediaproxy-ng . But I have problems with
configuration. I tried to follow instructions given by Peter at Astricon
2013, but because I’m a bit unexperienced with Kamailio configuration I
couldn’t make successful WebRTC to SIP call.
Is there any working example of kamailio.cfg file for Kamailio with
mediaproxy-ng available?
That would really help me to understand the whole concept. I’m using
Kamailio 4.1.1 and mediaproxy-ng 3.8.0-30-generic.
Thank you.
Regards,
Blaz
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/kamailio-with-mediaproxy-ng-488-Not…
Sent from the Users mailing list archive at Nabble.com.
8:42 p.m.
Great, i would test Bundle right away. Just wondering if this branch also
supports DTLS--SRTP. I would love to test that feature when available.
Thank you.
On Thu, Feb 6, 2014 at 2:43 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
Hey,
What mediaproxy-ng can do (which other RTP proxies don't do) is
translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
(encrypted RTP from WebRTC), which is what people usually use it for.
Assuming that ICE does its job correctly, two WebRTC endpoints should be
able to communicate directly with each other (without RTP proxy), even
if a firewall is involved. But I understand that in some cases even ICE
might fail.
There's two things I see wrong with the resulting SDP body, both related
to the last stable version of MP-NG not supporting BUNDLE. If you could
try adding an SDP rewrite rule to your kamailio config to remove the
a=group:... line. If that doesn't work, also try disabling video when
making the call.
Alternatively, you can try building MP-NG from this branch:
https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
This is currently under heavy development, but it should support BUNDLE
just enough to make this work.
cheers
On 02/05/14 11:23, Mihai Marin wrote:
wrote:
it
of
webrtc to
be
support)
wrong
log?
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
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
sr-users(a)lists.sip-router.org>
Hello,
I'm trying the simplest case first. I don't understand why you are
saying that most of the people don't use mediaproxy-ng
for WebRTC to WebRTC calls. If my firewall is a restrictive one I need
to use turn server and mediaproxy-ng can do turn too? Probably I'm not
seeing the big picture.
Regarding the problem with Incompatible SDP I have attached the SDP
before mp-ng and after:
BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
message:
INVITE sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>>
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967
v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
Between them, I have some strange logs in kamailio:
14(21473) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ssrc:3207772497
label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:
check_content_type(): type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
Thank you very much for your help and for spending time debugging this
error.
Best regards,
Mihai M
On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>> wrote:
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC
endpoint
with a non-WebRTC one, which is usually what
people are trying to do.
In your case, the flags "froc" in either direction should be
sufficient
to get the job done. If it still doesn't
work, can you please post
the
rejected SDP body as it appears both on the
sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
> Hello,
> Thank you for your detailed explication but I miss some
information or
> I'm unable to understand it
properly. What I'm trying to do is to
use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at
least
one is behind restrictive firewall). Trying to
replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad
<shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>
> <mailto:shaheryarkh@gmail.com <mailto:shaheryarkh@gmail.com>>>
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng
related ones.
>
> First instead of engaging mediaproxy in failure route, engage > main route or branch route. Why wait
for failure when we know
call
> will fail anyway if you try to call
webrtc to sip or vice
versa.
>
> Secondly you need to keep track of connection type of both
caller
and
callee and set appropriate mediaproxy-ng flags according
to call
direction, e.g. call from webrtc to sip, or
sip to webrtc or
webrtc
> to webrtc or sip to sip, each type of call needs different set > flags for both rtpproxy_offer and
rtpproxy_answer.
>
> How you do this, is pretty simple, to detect if caller is
webrtc
> endpoint you can use,
>
>
> if ($avp(mline) =~ "SAVPF") {
> # caller is a webrtc endpoint
> };
>
> To check if callee is a webrtc endpoint, you can use,
>
> if ($(ru{uri.param,transport}) =~ "ws") {
> # callee is a webrtc endpoint
> };
>
> For testing purpose, i recommend you only use mediaproxy-ng for
> bridging webrtc to sip or vice versa calls, i.e. if both
endpoints
are
using same transport (e.g. sip to sip or webrtc to webrtc
calls)
then don't use mediaproxy-ng at all and
allow endpoints to
establish
> media directly (that would work out the box at least for > webrtc calls).
>
> Finally use correct flags for each type of call (i recommend
doing
it in
branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS,
which
> is required by firefox, so as result your webrtc endpoint MUST
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin
<marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>
<mailto:marinmihai@gmail.com
<mailto:marinmihai@gmail.com>>>
wrote:
>
> Hello,
> Thank you for your support.
>
> Yes, I have the same error without video enabled. I have
> attached the logs from jssip (with and without video > and logs from kamailio when
trying a call with video
support
enabled. The kamailio.cfg used is the same from my
previous mail.
>
> I also tried with sipml5 and I have the same behavior.
>
> I'm stuck on this error and I think I'm looking in the
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com
<mailto:apogrebennyk@sipwise.com>
<mailto:apogrebennyk@sipwise.com
<mailto:apogrebennyk@sipwise.com>>> wrote:
>
> Hi,
> could you please post also your Chrome js developer > Does the problem exist if
you start the jssip clients
> without video support?
>
> Andrew
>
> On 02/03/2014 12:00 PM, Mihai Marin wrote:
> > Hello,
> >
> > Another weekend struggling to make a call from jssip
to
> another jssip
> > behind firewall and I still receive 488 - Not
Acceptable
> Here. I tried
> > all the ideas that I had/received without any
success -
> including catch
> > 488 and re-invite.
> > [...]
> > What do I miss from my configuration?
> >
> > Thank you.
> >
> > Best regards,
> > Mihai M
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto: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(a)lists.sip-router.org <mailto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
<mailto: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(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
12 Feb
12 Feb
10:41 a.m.
Hello,
I managed to try it out and I have good news and bad news :)
The good news is that always TURN is working perfect. So, if I remove all
the ice-candidates (rtpproxy_manage("+")) everything is perfect. If I just
append turn candidate (rtpproxy_manage()) I have strange errors in kamailio
log and the media won't flow (black image on both parties).
I have attached the logs for both cases:
1. remove previous ice candidates - working - rtpproxy_manage("+")
http://snk.to/f-c7tjwm5k
2. keep ice candidates and append itself - not working - rtpproxy_manage()
http://snk.to/f-c71n29ic
My case and probably a nice feature is to have the possibility to append
the turn server candidate in SDP and let the client to decide what to use -
for WebRTC to WebRTC. Or, make this decision on server side (as it is now)
when you need conversion (RTP/AVP to and from RTP/SAVPF) - WebRTC to SIP,
etc. I'm sorry if I'm telling something wrong.
What I noticed is this line:
14(8465) ERROR: rtpproxy-ng [rtpproxy.c:1339]: rtpp_function_call(): failed
to decode bencoded reply from proxy: d3:sdp4301:v=0
I'm testing with the branch that you told me - pull yesterday.
Thank you.
Best regards,
Mihai M
On Thu, Feb 6, 2014 at 3:43 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
Hey,
What mediaproxy-ng can do (which other RTP proxies don't do) is
translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
(encrypted RTP from WebRTC), which is what people usually use it for.
Assuming that ICE does its job correctly, two WebRTC endpoints should be
able to communicate directly with each other (without RTP proxy), even
if a firewall is involved. But I understand that in some cases even ICE
might fail.
There's two things I see wrong with the resulting SDP body, both related
to the last stable version of MP-NG not supporting BUNDLE. If you could
try adding an SDP rewrite rule to your kamailio config to remove the
a=group:... line. If that doesn't work, also try disabling video when
making the call.
Alternatively, you can try building MP-NG from this branch:
https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
This is currently under heavy development, but it should support BUNDLE
just enough to make this work.
cheers
On 02/05/14 11:23, Mihai Marin wrote:
wrote:
it
of
webrtc to
be
support)
wrong
log?
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
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
sr-users(a)lists.sip-router.org>
Hello,
I'm trying the simplest case first. I don't understand why you are
saying that most of the people don't use mediaproxy-ng
for WebRTC to WebRTC calls. If my firewall is a restrictive one I need
to use turn server and mediaproxy-ng can do turn too? Probably I'm not
seeing the big picture.
Regarding the problem with Incompatible SDP I have attached the SDP
before mp-ng and after:
BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
message:
INVITE sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>>
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967
v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
Between them, I have some strange logs in kamailio:
14(21473) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ssrc:3207772497
label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:
check_content_type(): type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
Thank you very much for your help and for spending time debugging this
error.
Best regards,
Mihai M
On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>> wrote:
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC
endpoint
with a non-WebRTC one, which is usually what
people are trying to do.
In your case, the flags "froc" in either direction should be
sufficient
to get the job done. If it still doesn't
work, can you please post
the
rejected SDP body as it appears both on the
sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
> Hello,
> Thank you for your detailed explication but I miss some
information or
> I'm unable to understand it
properly. What I'm trying to do is to
use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at
least
one is behind restrictive firewall). Trying to
replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad
<shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>
> <mailto:shaheryarkh@gmail.com <mailto:shaheryarkh@gmail.com>>>
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng
related ones.
>
> First instead of engaging mediaproxy in failure route, engage > main route or branch route. Why wait
for failure when we know
call
> will fail anyway if you try to call
webrtc to sip or vice
versa.
>
> Secondly you need to keep track of connection type of both
caller
and
callee and set appropriate mediaproxy-ng flags according
to call
direction, e.g. call from webrtc to sip, or
sip to webrtc or
webrtc
> to webrtc or sip to sip, each type of call needs different set > flags for both rtpproxy_offer and
rtpproxy_answer.
>
> How you do this, is pretty simple, to detect if caller is
webrtc
> endpoint you can use,
>
>
> if ($avp(mline) =~ "SAVPF") {
> # caller is a webrtc endpoint
> };
>
> To check if callee is a webrtc endpoint, you can use,
>
> if ($(ru{uri.param,transport}) =~ "ws") {
> # callee is a webrtc endpoint
> };
>
> For testing purpose, i recommend you only use mediaproxy-ng for
> bridging webrtc to sip or vice versa calls, i.e. if both
endpoints
are
using same transport (e.g. sip to sip or webrtc to webrtc
calls)
then don't use mediaproxy-ng at all and
allow endpoints to
establish
> media directly (that would work out the box at least for > webrtc calls).
>
> Finally use correct flags for each type of call (i recommend
doing
it in
branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS,
which
> is required by firefox, so as result your webrtc endpoint MUST
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin
<marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>
<mailto:marinmihai@gmail.com
<mailto:marinmihai@gmail.com>>>
wrote:
>
> Hello,
> Thank you for your support.
>
> Yes, I have the same error without video enabled. I have
> attached the logs from jssip (with and without video > and logs from kamailio when
trying a call with video
support
enabled. The kamailio.cfg used is the same from my
previous mail.
>
> I also tried with sipml5 and I have the same behavior.
>
> I'm stuck on this error and I think I'm looking in the
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com
<mailto:apogrebennyk@sipwise.com>
<mailto:apogrebennyk@sipwise.com
<mailto:apogrebennyk@sipwise.com>>> wrote:
>
> Hi,
> could you please post also your Chrome js developer > Does the problem exist if
you start the jssip clients
> without video support?
>
> Andrew
>
> On 02/03/2014 12:00 PM, Mihai Marin wrote:
> > Hello,
> >
> > Another weekend struggling to make a call from jssip
to
> another jssip
> > behind firewall and I still receive 488 - Not
Acceptable
> Here. I tried
> > all the ideas that I had/received without any
success -
> including catch
> > 488 and re-invite.
> > [...]
> > What do I miss from my configuration?
> >
> > Thank you.
> >
> > Best regards,
> > Mihai M
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto: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(a)lists.sip-router.org <mailto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
<mailto: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(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
13 Feb
13 Feb
2:37 a.m.
Hello,
Would you mind posting your kamailio configuration file please?
Thanks,
Ashu
--
View this message in context:
http://sip-router.1086192.n5.nabble.com/kamailio-with-mediaproxy-ng-488-Not…
Sent from the Users mailing list archive at Nabble.com.
17 Feb
17 Feb
5:39 p.m.
New subject: Fwd: kamailio with mediaproxy-ng, 488 Not Acceptable Here
Hello Sirs, Sir Richard,
Does anyone has an idea for my previous mail/problem? I think the problem
is in mediaproxy-ng but I can't be sure for that. Has anyone tried the same
scenario before (WebRTC to WebRTC, append mediaproxy-ng as turn candidate
and let client decide)?
Thank you.
Best regards,
Mihai M
---------- Forwarded message ----------
From: Mihai Marin <marinmihai(a)gmail.com>
Date: Wed, Feb 12, 2014 at 11:41 AM
Subject: Re: [SR-Users] kamailio with mediaproxy-ng, 488 Not Acceptable Here
To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.sip-router.org>
Hello,
I managed to try it out and I have good news and bad news :)
The good news is that always TURN is working perfect. So, if I remove all
the ice-candidates (rtpproxy_manage("+")) everything is perfect. If I just
append turn candidate (rtpproxy_manage()) I have strange errors in kamailio
log and the media won't flow (black image on both parties).
I have attached the logs for both cases:
1. remove previous ice candidates - working - rtpproxy_manage("+")
http://snk.to/f-c7tjwm5k
2. keep ice candidates and append itself - not working - rtpproxy_manage()
http://snk.to/f-c71n29ic
My case and probably a nice feature is to have the possibility to append
the turn server candidate in SDP and let the client to decide what to use -
for WebRTC to WebRTC. Or, make this decision on server side (as it is now)
when you need conversion (RTP/AVP to and from RTP/SAVPF) - WebRTC to SIP,
etc. I'm sorry if I'm telling something wrong.
What I noticed is this line:
14(8465) ERROR: rtpproxy-ng [rtpproxy.c:1339]: rtpp_function_call(): failed
to decode bencoded reply from proxy: d3:sdp4301:v=0
I'm testing with the branch that you told me - pull yesterday.
Thank you.
Best regards,
Mihai M
On Thu, Feb 6, 2014 at 3:43 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
Hey,
What mediaproxy-ng can do (which other RTP proxies don't do) is
translate RTP/AVP (from regular SIP endpoints) to and from RTP/SAVPF
(encrypted RTP from WebRTC), which is what people usually use it for.
Assuming that ICE does its job correctly, two WebRTC endpoints should be
able to communicate directly with each other (without RTP proxy), even
if a firewall is involved. But I understand that in some cases even ICE
might fail.
There's two things I see wrong with the resulting SDP body, both related
to the last stable version of MP-NG not supporting BUNDLE. If you could
try adding an SDP rewrite rule to your kamailio config to remove the
a=group:... line. If that doesn't work, also try disabling video when
making the call.
Alternatively, you can try building MP-NG from this branch:
https://github.com/sipwise/mediaproxy-ng/tree/rfuchs/3.0
This is currently under heavy development, but it should support BUNDLE
just enough to make this work.
cheers
On 02/05/14 11:23, Mihai Marin wrote:
wrote:
it
of
webrtc to
be
support)
wrong
log?
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
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
sr-users(a)lists.sip-router.org>
Hello,
I'm trying the simplest case first. I don't understand why you are
saying that most of the people don't use mediaproxy-ng
for WebRTC to WebRTC calls. If my firewall is a restrictive one I need
to use turn server and mediaproxy-ng can do turn too? Probably I'm not
seeing the big picture.
Regarding the problem with Incompatible SDP I have attached the SDP
before mp-ng and after:
BEFORE mediaproxy-ng magic:
14(21473) DEBUG: websocket [ws_frame.c:650]: ws_frame_receive(): Rx SIP
message:
INVITE sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214> SIP/2.0
Via: SIP/2.0/WS an6ikqlgivd7.invalid;branch=z9hG4bK5845620
Max-Forwards: 69
To: <sip:bob@93.187.138.214 <mailto:sip%3Abob@93.187.138.214>>
From: "Alice Test" <sip:alice@93.187.138.214
<mailto:sip%3Aalice@93.187.138.214>>;tag=dt8iuu64l9
Call-ID: bmaapitncfv1jnijrbcf
CSeq: 7318 INVITE
Contact: <sip:sbt6u2o1@an6ikqlgivd7.invalid;transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INVITE
Content-Type: application/sdp
Supported: path, outbound, gruu
User-Agent: JsSIP 0.3.0
Content-Length: 2967
v=0
o=- 1167703101330838157 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 9496 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
m=video 9496 RTP/SAVPF 100 116 117
c=IN IP4 213.233.85.51
a=rtcp:9496 IN IP4 213.233.85.51
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
AFTER mediaproxy-ng magic:
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:
v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
m=audio 30408 RTP/SAVPF 111 103 0 8 106 105 13 126
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
a=ssrc:231261060 cname:aZBL5jB9VQtchKUh
a=ssrc:231261060 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=ssrc:231261060 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:231261060 label:e8c9eb9c-916e-4c30-884f-fd602b2d8c90
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
m=video 30408 RTP/SAVPF 100 116 117
c=IN IP4 93.187.138.214
a=candidate:3511930567 1 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:3511930567 2 udp 2113937151 10.93.108.223 53310 typ host
generation 0
a=candidate:2681221687 1 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:2681221687 2 tcp 1509957375 10.93.108.223 0 typ host
generation 0
a=candidate:1343998067 1 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=candidate:1343998067 2 udp 1845501695 213.233.85.51 9496 typ srflx
raddr 10.93.108.223 rport 53310 generation 0
a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:video
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:uWFSQ5+41i2e12WFnGJKCfe+kuudHy0NurAaT8or
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3207772497 cname:aZBL5jB9VQtchKUh
a=ssrc:3207772497 msid:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
ec757148-040c-479f-adbe-f6bac271fbd6
a=ssrc:3207772497 mslabel:3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
a=ssrc:3207772497 label:ec757148-040c-479f-adbe-f6bac271fbd6
a=rtcp:30409
a=candidate:8JGnwCAu0icAoJnr 1 UDP 2130706432 93.187.138.214 30408 typ
host
a=candidate:8JGnwCAu0icAoJnr 2 UDP 2130706431
93.187.138.214 30409 typ
host
Between them, I have some strange logs in kamailio:
14(21473) ERROR: *** cfgtrace:
c=[/usr/local/etc/kamailio/kamailio-test-media.cfg] l=878 a=25
n=rtpproxy_manage
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [127.0.0.1] in `o=' field
14(21473) DEBUG: <core> [parser/sdp/sdp_helpr_funcs.c:565]:
extract_mediaip(): located IP address [213.233.85.51] in `c=' field
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ice-ufrag:gNml+vA5NqfaRg0w
a=ice-pwd:dQJW2XWJ+g6gTIujfT819g2d
a=ice-options:google-ice
a=mid:audio
...............................................................
14(21473) DEBUG: <core> [parser/sdp/sdp.c:574]: parse_sdp_session():
ignoring unknown type in a= line: `a=ssrc:3207772497
label:ec757148-040c-479f-adbe-f6bac271fbd6
'
14(21473) DEBUG: rtpproxy-ng [rtpproxy_funcs.c:148]:
check_content_type(): type <application/sdp> found valid
14(21473) DEBUG: rtpproxy-ng [rtpproxy.c:1333]: rtpp_function_call():
proxy reply: d3:sdp3046:v=0
o=- 1167703101330838157 2 IN IP4 93.187.138.214
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS 3G8DreUBMks5DpcqNiiE5jXIC4GzIwfd7CUv
Thank you very much for your help and for spending time debugging this
error.
Best regards,
Mihai M
On Wed, Feb 5, 2014 at 5:41 PM, Richard Fuchs <rfuchs(a)sipwise.com
<mailto:rfuchs@sipwise.com>> wrote:
Hey,
If you're trying to connect two WebRTC endpoints with each, you don't
need any of mediaproxy-ng's magic to get it working. All the previous
replies were assuming that you were trying to connect a WebRTC
endpoint
with a non-WebRTC one, which is usually what
people are trying to do.
In your case, the flags "froc" in either direction should be
sufficient
to get the job done. If it still doesn't
work, can you please post
the
rejected SDP body as it appears both on the
sender's side and on the
receiver's side (i.e. both before and after it went through MP-NG).
cheers
On 02/05/14 05:17, Mihai Marin wrote:
> Hello,
> Thank you for your detailed explication but I miss some
information or
> I'm unable to understand it
properly. What I'm trying to do is to
use
mediaproxy-ng as a turn server between 2 WebRTC endpoints (when at
least
one is behind restrictive firewall). Trying to
replicate what you
explained on my needs I tried:
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-SP";
But, unfortunately, I have the same error. Sorry if the solution is
obvious but I can't find it.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 10:45 PM, Muhammad Shahzad
<shaheryarkh(a)gmail.com
<mailto:shaheryarkh@gmail.com>
> <mailto:shaheryarkh@gmail.com <mailto:shaheryarkh@gmail.com>>>
There are several problems that need to be addressed in your
kamailio.cfg but let me try to focus only on mediaprxoy-ng
related ones.
>
> First instead of engaging mediaproxy in failure route, engage > main route or branch route. Why wait
for failure when we know
call
> will fail anyway if you try to call
webrtc to sip or vice
versa.
>
> Secondly you need to keep track of connection type of both
caller
and
callee and set appropriate mediaproxy-ng flags according
to call
direction, e.g. call from webrtc to sip, or
sip to webrtc or
webrtc
> to webrtc or sip to sip, each type of call needs different set > flags for both rtpproxy_offer and
rtpproxy_answer.
>
> How you do this, is pretty simple, to detect if caller is
webrtc
> endpoint you can use,
>
>
> if ($avp(mline) =~ "SAVPF") {
> # caller is a webrtc endpoint
> };
>
> To check if callee is a webrtc endpoint, you can use,
>
> if ($(ru{uri.param,transport}) =~ "ws") {
> # callee is a webrtc endpoint
> };
>
> For testing purpose, i recommend you only use mediaproxy-ng for
> bridging webrtc to sip or vice versa calls, i.e. if both
endpoints
are
using same transport (e.g. sip to sip or webrtc to webrtc
calls)
then don't use mediaproxy-ng at all and
allow endpoints to
establish
> media directly (that would work out the box at least for > webrtc calls).
>
> Finally use correct flags for each type of call (i recommend
doing
it in
branch route), for example,
For WebRTC to SIP call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc-sp";
$avp(rtpproxy_answer_flags) = "froc+SP";
rtpproxy_offer($avp(rtpproxy_offer_flags));
For SIP to WebRTC call use flags (case-sensitive),
$avp(rtpproxy_offer_flags) = "froc+SP";
$avp(rtpproxy_answer_flags) = "froc-sp";
rtpproxy_offer($avp(rtpproxy_offer_flags));
Then in reply route,
rtpproxy_answer($avp(rtpproxy_answer_flags));
Remember, currently mediaproxy-ng does NOT support SRTP/DTLS,
which
> is required by firefox, so as result your webrtc endpoint MUST
running on Chrome.
Hope this helps.
Thank you.
On Tue, Feb 4, 2014 at 3:28 PM, Mihai Marin
<marinmihai(a)gmail.com
<mailto:marinmihai@gmail.com>
<mailto:marinmihai@gmail.com
<mailto:marinmihai@gmail.com>>>
wrote:
>
> Hello,
> Thank you for your support.
>
> Yes, I have the same error without video enabled. I have
> attached the logs from jssip (with and without video > and logs from kamailio when
trying a call with video
support
enabled. The kamailio.cfg used is the same from my
previous mail.
>
> I also tried with sipml5 and I have the same behavior.
>
> I'm stuck on this error and I think I'm looking in the
direction.
Thank you.
Best regards,
Mihai M
On Tue, Feb 4, 2014 at 2:49 PM, Andrew Pogrebennyk
<apogrebennyk(a)sipwise.com
<mailto:apogrebennyk@sipwise.com>
<mailto:apogrebennyk@sipwise.com
<mailto:apogrebennyk@sipwise.com>>> wrote:
>
> Hi,
> could you please post also your Chrome js developer > Does the problem exist if
you start the jssip clients
> without video support?
>
> Andrew
>
> On 02/03/2014 12:00 PM, Mihai Marin wrote:
> > Hello,
> >
> > Another weekend struggling to make a call from jssip
to
> another jssip
> > behind firewall and I still receive 488 - Not
Acceptable
> Here. I tried
> > all the ideas that I had/received without any
success -
> including catch
> > 488 and re-invite.
> > [...]
> > What do I miss from my configuration?
> >
> > Thank you.
> >
> > Best regards,
> > Mihai M
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
mailing list
sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>
<mailto:sr-users@lists.sip-router.org
<mailto: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(a)lists.sip-router.org <mailto:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
list
sr-users(a)lists.sip-router.org
<mailto: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(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
7:35 p.m.
On 02/12/14 04:41, Mihai Marin wrote:
Hello,
I managed to try it out and I have good news and bad news :)
The good news is that always TURN is working perfect. So, if I remove
all the ice-candidates (rtpproxy_manage("+")) everything is perfect.
That's good to hear!
If
I just append turn candidate (rtpproxy_manage()) I have strange errors
in kamailio log and the media won't flow (black image on both parties).
...
2. keep ice candidates and append itself - not working
- rtpproxy_manage()
http://snk.to/f-c71n29ic
Looking at this, there's a very simple problem going on... The SDP body
is getting too large for the receive buffer. :) It gets truncate, so
can't be decoded, and the whole proxying thing fails.
This commit should fix that:
http://goo.gl/fBHfkh
http://goo.gl/o1Pzt8
Please let me know if you're having any luck with that.
cheers
18 Feb
18 Feb
5:12 p.m.
Hello Sirs,
Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive
video but bob won't. If I stop mediaproxy-ng process (without any other
modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA
The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates, video
are the same):
1. offer
1.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
1.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ host
a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ host
2. answer
2.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx
raddr 192.168.0.5 rport 63028 generation 0
a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx
raddr 192.168.0.5 rport 63031 generation 0
2.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Thank you.
Best regards,
Mihai M
On Mon, Feb 17, 2014 at 8:35 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 02/12/14 04:41, Mihai Marin wrote:
Hello,
I managed to try it out and I have good news and bad news :)
The good news is that always TURN is working perfect. So, if I remove
all the ice-candidates (rtpproxy_manage("+")) everything is perfect.
That's good to hear!
If
I just append turn candidate (rtpproxy_manage()) I have strange errors
in kamailio log and the media won't flow (black image on both parties).
...
2. keep ice candidates and append itself - not
working -
rtpproxy_manage()
Looking at this, there's a very simple problem going on... The SDP body
is getting too large for the receive buffer. :) It gets truncate, so
can't be decoded, and the whole proxying thing fails.
This commit should fix that:
http://goo.gl/fBHfkh
http://goo.gl/o1Pzt8
Please let me know if you're having any luck with that.
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
5:43 p.m.
On 02/18/14 11:12, Mihai Marin wrote:
Hello Sirs,
Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive
video but bob won't. If I stop mediaproxy-ng process (without any other
modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA
The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates,
video are the same):
1. offer
1.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
1.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ host
a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431 93.187.138.214 30009 typ host
2. answer
2.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx
raddr 192.168.0.5 rport 63028 generation 0
a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx
raddr 192.168.0.5 rport 63031 generation 0
2.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of
this before, as in our case we only use MP-NG with the '+' flag, which
would eliminate this issue.
What happens is that MP-NG supports rtcp-mux in that it answers to an
rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to
anyone, unless that endpoint is already talking rtcp-mux.
So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and
gladly accepts the offer in the answer sent to Alice. In this case, the
same port is used for RTP and RTCP, which implies that only one ICE
candidate is given for that port (only in the answer though -- in the
offer, two must be given as a fallback).
However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's
answer includes separate ICE candidates for RTP and RTCP (due to
separate ports). As those ICE candidates are left in place by MP-NG when
translating the answer (which will include rtcp-mux), there's now a
disagreement between the ICE candidates from Bob (two per candidate due
to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one
due to rtcp-mux).
There's two possible solutions without resorting to the '+' flag...
Either make MP-NG offer rtcp-mux to Bob initially (who may or may not
accept it -- if he doesn't, nothing is fixed), or make it reject the
rtcp-mux offer coming from Alice (which violates the WebRTC spec).
Another thing that MP-NG could do is to remove the RTCP ICE candidates
in the answer going to Alice, hoping that Bob knows to demultiplex the
RTCP packets coming in on the RTP port, despite rtcp-mux not having been
negotiated.
I can't say I like any of these options :)
cheers
20 Feb
20 Feb
10:15 a.m.
Hello Sirs, Sir Richard,
I understand the problem but I don't understand the behavior. Let me tell
you how I understood the problem and where I misunderstand the behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) - Kamailio
- MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows that bob
request rtcp-mux but ignore it by removing "a=rtcp-mux" line from SDP and
add 2 ICE Candidates with different ports .
ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC
(alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer, MP-NG
knows that bob accept rtcp-mux, ignore it first time, but still accept
alice's answer with rtcp-mux (accepting the RTP and RTCP multiplexing) -
offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by alice
does not contain rtcp-mux and has 2 ICE Candidates with different ports and
the answer contains a=rtcp-mux and has 1 ICE Candidates for bundle.
The most important part (for this problem) from RFC 5761 I think is the
following
5.1.3 <http://tools.ietf.org/html/rfc5761#section-5.1.3>. Interactions with
ICE
It is common to use the Interactive Connectivity Establishment (ICE)
[19 <http://tools.ietf.org/html/rfc5761#ref-19>] methodology to
establish RTP sessions in the presence of Network
Address Translation (NAT) devices or other middleboxes. If RTP and
RTCP are sent on separate ports, the RTP media stream comprises two
components in ICE (one for RTP and one for RTCP), with connectivity
checks being performed for each component. If RTP and RTCP are to be
multiplexed on the same port some of these connectivity checks can be
avoided, reducing the overhead of ICE.
If it is desired to use both ICE and multiplexed RTP and RTCP, the
initial offer MUST contain an "a=rtcp-mux" attribute to indicate that
RTP and RTCP multiplexing is desired and MUST contain "a=candidate:"
lines for both RTP and RTCP along with an "a=rtcp:" line indicating a
fallback port for RTCP in the case that the answerer does not support
RTP and RTCP multiplexing. This MUST be done for each media where
RTP and RTCP multiplexing is desired.
If the answerer wishes to multiplex RTP and RTCP on a single port, it
MUST generate an answer containing an "a=rtcp-mux" attribute and a
single "a=candidate:" line corresponding to the RTP port (i.e., there
is no candidate for RTCP) for each media where it is desired to use
RTP and RTCP multiplexing. The answerer then performs connectivity
checks for that media as if the offer had contained only a single
candidate for RTP. If the answerer does not want to multiplex RTP
and RTCP on a single port, it MUST NOT include the "a=rtcp-mux"
attribute in its answer and MUST perform connectivity checks for all
offered candidates in the usual manner.
On receipt of the answer, the offerer looks for the presence of the
"a=rtcp-mux" line for each media where multiplexing was offered. If
this is present, then connectivity checks proceed as if only a single
candidate (for RTP) were offered, and multiplexing is used once the
session is established. If the "a=rtcp-mux" line is not present, the
session proceeds with connectivity checks using both RTP and RTCP
candidates, eventually leading to a session being established with
RTP and RTCP on separate ports (as signalled by the "a=rtcp:"
attribute).
My thought is that the cause why is not working in my example is that I'm
in a LAN (no restrictive network with friendly NAT) where TURN is not
needed and I have no a=rtcp-mux but 2 ICE STUN Candidates with the same
port.
Another question is why MP-NG does not offer rtcp-mux event is it knows
from the original SDP that rtcp-mux is prefered, at least for the "no +"
case? Can't we put a rule like: ok, if we want "no + case" - decision moved
to client side - and original SDP has a=rtcp-mux we generate candidates
according to that. Why changing client preferences when switching to "no +
- client decision"?
I hope I don't say stupid things and sorry if I do that.
Thank you.
Best regards,
Mihai M
On Tue, Feb 18, 2014 at 6:43 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 02/18/14 11:12, Mihai Marin wrote:
Hello Sirs,
Thank you, one step forward but still buggy - half buggy :)
Now, it's working just one way. If bob calls alice, alice will receive
video but bob won't. If I stop mediaproxy-ng process (without any other
modification) and redo the call, everything is just fine.
The invite sdp that alice receives is here http://pastebin.com/BgZZbbEA
The sdp from OK that bob receive is here http://pastebin.com/ADGt3D3E
I noticed something strange in those 2 SDPs (just audio candidates,
video are the same):
1. offer
1.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
a=candidate:1855365925 2 udp 1845501695 188.215.94.132 63015 typ srflx
raddr 192.168.0.5 rport 63015 generation 0
1.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30008 typ
host
a=candidate:Om0baCmE7kgKNPvv 2 UDP 2130706431
93.187.138.214 30009 typ
host
2. answer
2.a. stun candidates
a=candidate:1855365925 1 udp 1845501695 188.215.94.132 63028 typ srflx
raddr 192.168.0.5 rport 63028 generation 0
a=candidate:1855365925 2 udp 1845501694 188.215.94.132 63031 typ srflx
raddr 192.168.0.5 rport 63031 generation 0
2.b. turn candidates
a=candidate:Om0baCmE7kgKNPvv 1 UDP 2130706432 93.187.138.214 30010 typ
host
No bundle in sdp but:
- offer has 1 single port for stun candidates and 2 for turn candidates
- answer has 2 ports for stun candidates and 1 for turn candidates
The kamailio log can be accessed at http://pastebin.com/tVgE3BGt
Do you have any idea why this behavior?
Yes, this is caused by MP-NG demultiplexing RTCP. I haven't thought of
this before, as in our case we only use MP-NG with the '+' flag, which
would eliminate this issue.
What happens is that MP-NG supports rtcp-mux in that it answers to an
rtcp-mux offer and handles it correctly, but it never offers rtcp-mux to
anyone, unless that endpoint is already talking rtcp-mux.
So from Alice's offer, MP-NG knows that Alice supports rtcp-mux and
gladly accepts the offer in the answer sent to Alice. In this case, the
same port is used for RTP and RTCP, which implies that only one ICE
candidate is given for that port (only in the answer though -- in the
offer, two must be given as a fallback).
However, MP-NG doesn't offer rtcp-mux to Bob, which means that Bob's
answer includes separate ICE candidates for RTP and RTCP (due to
separate ports). As those ICE candidates are left in place by MP-NG when
translating the answer (which will include rtcp-mux), there's now a
disagreement between the ICE candidates from Bob (two per candidate due
to lack of rtcp-mux) and the ICE candidate inserted by MP-NG (only one
due to rtcp-mux).
There's two possible solutions without resorting to the '+' flag...
Either make MP-NG offer rtcp-mux to Bob initially (who may or may not
accept it -- if he doesn't, nothing is fixed), or make it reject the
rtcp-mux offer coming from Alice (which violates the WebRTC spec).
Another thing that MP-NG could do is to remove the RTCP ICE candidates
in the answer going to Alice, hoping that Bob knows to demultiplex the
RTCP packets coming in on the RTP port, despite rtcp-mux not having been
negotiated.
I can't say I like any of these options :)
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
1:44 p.m.
On 02/20/14 04:15, Mihai Marin wrote:
Hello Sirs, Sir Richard,
I understand the problem but I don't understand the behavior. Let me
tell you how I understood the problem and where I misunderstand the
behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) -
Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows
that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line
from SDP and add 2 ICE Candidates with different ports .
ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC
(alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer,
MP-NG knows that bob accept rtcp-mux, ignore it first time, but still
accept alice's answer with rtcp-mux (accepting the RTP and RTCP
multiplexing) - offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by
alice does not contain rtcp-mux and has 2 ICE Candidates with different
ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for
bundle.
Let me try to put it in a more concise way then.
Bob is calling Alice. Bob is offering to Alice, and Alice is answering
to Bob.
Bob's point of view: Bob offers rtcp-mux. He also includes ICE
candidates for RTCP as fallback, as required. Bob receives an answer
accepting rtcp-mux. Thus, Bob will talk rtcp-mux and as such, the answer
must not include separate ICE candidates for RTCP.
Alice's point of view: Alice receives offer without rtcp-mux. Since
rtcp-mux wasn't offered, it can't be negotiated nor offered nor
accepted. Alice therefore allocates a separate port for RTCP and
includes separate ICE candidates for RTCP, as required.
Mediaproxy's point of view: Bob offers rtcp-mux and mediaproxy accepts
it in its answer. Thus, Bob will talk rtcp-mux and therefore mediaproxy
won't include a separate ICE candidate for RTCP, as required.
The problem is that Alice doesn't know that Bob talks rtcp-mux, only
mediaproxy knows. Alice therefore includes separate ICE candidates for
RTCP, while mediaproxy doesn't. Bob now sees separate ICE candidates for
RTCP coming from Alice, although Bob is talking rtcp-mux and so those
shouldn't be there.
Another question is why MP-NG does not offer rtcp-mux
event is it knows
from the original SDP that rtcp-mux is prefered, at least for the "no +"
case? Can't we put a rule like: ok, if we want "no + case" - decision
moved to client side - and original SDP has a=rtcp-mux we generate
candidates according to that. Why changing client preferences when
switching to "no + - client decision"?
The reason is that not all RTP clients support rtcp-mux and since
mediaproxy has no real benefit from muxing RTCP, the chances of
establishing media flow are higher if rtcp-mux is left out. To the
offering client, it normally makes no difference (Bob sees his rtcp-mux
offer accepted, as required by WebRTC, so all is good) and we are
conservative with what we're sending to the answering client. You never
know what a client which doesn't understand rtcp-mux will do...
If mediaproxy knew that the answering client is also WebRTC, then it
would be safe to include rtcp-mux in the offer. But, it doesn't know that.
As mentioned earlier, the fact that this causes problems when ICE
candidates are only inserted and not deleted is something that hasn't
occurred to me before (mediaproxy's design is primarily based on it
being used to unconditionally proxy the media, and not to merely serve
as a fallback). I can envision something like an "rtcp-mux pass-through"
mode, where mediaproxy's offering and answering of rtcp-mux depends on
what the other client does. This is something that still needs to be
implemented though.
I'm not sure what the default mode of operation ought to be: should the
default be to always try to demux RTCP unless specified otherwise, or
should the default be to go along with what the clients do unless demux
is specifically requested? Any opinions on this?
cheers
22 Feb
22 Feb
1:07 p.m.
Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux , include separate
ICE candidates for RTCP for media proxy too and forward as it is to alice.
If callee accept it (or not) you will receive the OK with alice sdp, modify
it (depending on her choices) and forward to bob. In this way, we cover all
the cases. Eventually we can add another parameter to always ignore
rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that
some SIP clients not to respond properly to an SDP with rtcp-mux and that's
why you are removing it - or for '+' case where delay will be added?
Thank you for sharing it with me and again, sorry if
I misunderstood something.
Have a nice weekend.
Best regards,
Mihai M
On Thu, Feb 20, 2014 at 2:44 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 02/20/14 04:15, Mihai Marin wrote:
Hello Sirs, Sir Richard,
I understand the problem but I don't understand the behavior. Let me
tell you how I understood the problem and where I misunderstand the
behavior.
BOB sens an offer to Alice with rtcp-mux. The flow is: UAC (bob) -
Kamailio - MP-NG - Kamailio - UAS (alice). From the offer, MP-NG knows
that bob request rtcp-mux but ignore it by removing "a=rtcp-mux" line
from SDP and add 2 ICE Candidates with different ports .
ALICE sends answer to BOB's offer without rtcp-mux. The flow is: UAC
(alice) - Kamailio - MP-NG - Kamailio - UAS (bob). From the offer,
MP-NG knows that bob accept rtcp-mux, ignore it first time, but still
accept alice's answer with rtcp-mux (accepting the RTP and RTCP
multiplexing) - offering rtcp-mux in response (answer).
First, I don't understand why is not working :). Offer received by
alice does not contain rtcp-mux and has 2 ICE Candidates with different
ports and the answer contains a=rtcp-mux and has 1 ICE Candidates for
bundle.
Let me try to put it in a more concise way then.
Bob is calling Alice. Bob is offering to Alice, and Alice is answering
to Bob.
Bob's point of view: Bob offers rtcp-mux. He also includes ICE
candidates for RTCP as fallback, as required. Bob receives an answer
accepting rtcp-mux. Thus, Bob will talk rtcp-mux and as such, the answer
must not include separate ICE candidates for RTCP.
Alice's point of view: Alice receives offer without rtcp-mux. Since
rtcp-mux wasn't offered, it can't be negotiated nor offered nor
accepted. Alice therefore allocates a separate port for RTCP and
includes separate ICE candidates for RTCP, as required.
Mediaproxy's point of view: Bob offers rtcp-mux and mediaproxy accepts
it in its answer. Thus, Bob will talk rtcp-mux and therefore mediaproxy
won't include a separate ICE candidate for RTCP, as required.
The problem is that Alice doesn't know that Bob talks rtcp-mux, only
mediaproxy knows. Alice therefore includes separate ICE candidates for
RTCP, while mediaproxy doesn't. Bob now sees separate ICE candidates for
RTCP coming from Alice, although Bob is talking rtcp-mux and so those
shouldn't be there.
Another question is why MP-NG does not offer
rtcp-mux event is it knows
from the original SDP that rtcp-mux is prefered, at least for the "no +"
case? Can't we put a rule like: ok, if we want "no + case" - decision
moved to client side - and original SDP has a=rtcp-mux we generate
candidates according to that. Why changing client preferences when
switching to "no + - client decision"?
The reason is that not all RTP clients support rtcp-mux and since
mediaproxy has no real benefit from muxing RTCP, the chances of
establishing media flow are higher if rtcp-mux is left out. To the
offering client, it normally makes no difference (Bob sees his rtcp-mux
offer accepted, as required by WebRTC, so all is good) and we are
conservative with what we're sending to the answering client. You never
know what a client which doesn't understand rtcp-mux will do...
If mediaproxy knew that the answering client is also WebRTC, then it
would be safe to include rtcp-mux in the offer. But, it doesn't know that.
As mentioned earlier, the fact that this causes problems when ICE
candidates are only inserted and not deleted is something that hasn't
occurred to me before (mediaproxy's design is primarily based on it
being used to unconditionally proxy the media, and not to merely serve
as a fallback). I can envision something like an "rtcp-mux pass-through"
mode, where mediaproxy's offering and answering of rtcp-mux depends on
what the other client does. This is something that still needs to be
implemented though.
I'm not sure what the default mode of operation ought to be: should the
default be to always try to demux RTCP unless specified otherwise, or
should the default be to go along with what the clients do unless demux
is specifically requested? Any opinions on this?
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
1:31 p.m.
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux ,
include separate ICE candidates for RTCP for media proxy too and forward
as it is to alice. If callee accept it (or not) you will receive the OK
with alice sdp, modify it (depending on her choices) and forward to bob.
In this way, we cover all the cases. Eventually we can add another
parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that
some SIP clients not to respond properly to an SDP with rtcp-mux and
that's why you are removing it - or for '+' case where delay will be added?
Compatibility is exactly the reason. I don't have any exact numbers, but
I'm sure that there's a large number of SIP/RTP clients out there (I'd
say the vast majority) which don't support rtcp-mux at all. Some of them
might start misbehaving if they receive an rtcp-mux offer (even though
as per RFC, they shouldn't, but experience shows that RFC compliance is
often just wishful thinking). Since from our point of view (always
either '+' or '-') there's no disadvantage in always demuxing RTCP,
this
was what was implemented.
In any case, I'll see if I can get a solution implemented in the near
future.
cheers
24 Feb
24 Feb
5:21 p.m.
Just in case someone is interested, I created a sample script that could
help new comers having the same problem.
I will write a blog entry explaining how this works, but in a nutshell:
- this script is configured to run behind NAT, port TCP 10080 and TCP/UDP
5090 are exposed to the Internet
- you have to create valid users using, preferably, "kamctl add ..."
- RTP ports should be open in range 30k-35k, inclusive
- I used jssip as WEBRTC SIP UA: http://tryit.jssip.net/
- Always disable video before placing a call from jssip UA
- I tested calls between:
- jssip to csipsimple
- csipsimple to jssip
- csipsimple to csipsimple
Link to the scripts: https://github.com/caruizdiaz/kamailio-ws
Regards,
On Sat, Feb 22, 2014 at 9:31 AM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 02/22/14 07:07, Mihai Marin wrote:
--
Carlos
http://caruizdiaz.com
http://ngvoice.com
+595981146623
Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux ,
include separate ICE candidates for RTCP for media proxy too and forward
as it is to alice. If callee accept it (or not) you will receive the OK
with alice sdp, modify it (depending on her choices) and forward to bob.
In this way, we cover all the cases. Eventually we can add another
parameter to always ignore rtcp-mux offers.
What are the disadvantages on doing that? Is there any possibility that
some SIP clients not to respond properly to an SDP with rtcp-mux and
that's why you are removing it - or for '+' case where delay will be
added?
Compatibility is exactly the reason. I don't have any exact numbers, but
I'm sure that there's a large number of SIP/RTP clients out there (I'd
say the vast majority) which don't support rtcp-mux at all. Some of them
might start misbehaving if they receive an rtcp-mux offer (even though
as per RFC, they shouldn't, but experience shows that RFC compliance is
often just wishful thinking). Since from our point of view (always
either '+' or '-') there's no disadvantage in always demuxing RTCP,
this
was what was implemented.
In any case, I'll see if I can get a solution implemented in the near
future.
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
8:39 p.m.
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux ,
include separate ICE candidates for RTCP for media proxy too and forward
as it is to alice. If callee accept it (or not) you will receive the OK
with alice sdp, modify it (depending on her choices) and forward to bob.
In this way, we cover all the cases. Eventually we can add another
parameter to always ignore rtcp-mux offers.
Alright, can you please update your 3.0 branch from git and try with
this. The rtcp-mux default now is to go along with the client's choice,
which I believe should fix your use case.
On the other hand, it may break the usual WebRTC<>non-WebRTC bridging
case, depending on how picky the WebRTC client is. To accommodate for
this, there's a set of new flags within the control protocol to do
things like accepting rtcp-mux when the other client doesn't accept it,
removing an rtcp-mux offer from SDP, offering it when it wasn't offered,
offering it but rejecting it on the other side, and all kinds of other
scenarios (which may or may not collide with how ICE candidates are
handled). I'll see if I can get those implemented into the rtpproxy-ng
module soon for those who may need them.
cheers
26 Feb
26 Feb
5:22 p.m.
Hello Sirs, Sir Richard,
This is working perfect. I have tried the following test cases:
1. WS - WS in intranet; PASSED
2. WS - WS in different networks, both with restrictive firewalls: PASSED
3. WS - SIP Client (Boghe, Jitsi) in intranet: PASSED
4. WS - IMSDroid, both with restrictive firewalls: PASSED
5. WS - Linphone (intranet/internet): FAILED, video not receiving from WS
to Linphone (Linphone does not receive video)
6. Linphone - Linphone in different networks, both with restrictive
firewalls: PASSED
So, we have very good results. I'm loving it :)
I'll dig into the problem with Linphone to try to figure out what's the
problem. I'll be back with news but until now looks very good.
Thank you.
Best regards,
Mihai M
On Mon, Feb 24, 2014 at 9:39 PM, Richard Fuchs <rfuchs(a)sipwise.com> wrote:
On 02/22/14 07:07, Mihai Marin wrote:
Hello Sirs, Sir Richard,
Thank you for your detailed explication.
I'm still thinking on that but I would say to act as the caller and keep
caller decision. If caller makes an offer with rtcp-mux ,
include separate ICE candidates for RTCP for media proxy too and forward
as it is to alice. If callee accept it (or not) you will receive the OK
with alice sdp, modify it (depending on her choices) and forward to bob.
In this way, we cover all the cases. Eventually we can add another
parameter to always ignore rtcp-mux offers.
Alright, can you please update your 3.0 branch from git and try with
this. The rtcp-mux default now is to go along with the client's choice,
which I believe should fix your use case.
On the other hand, it may break the usual WebRTC<>non-WebRTC bridging
case, depending on how picky the WebRTC client is. To accommodate for
this, there's a set of new flags within the control protocol to do
things like accepting rtcp-mux when the other client doesn't accept it,
removing an rtcp-mux offer from SDP, offering it when it wasn't offered,
offering it but rejecting it on the other side, and all kinds of other
scenarios (which may or may not collide with how ICE candidates are
handled). I'll see if I can get those implemented into the rtpproxy-ng
module soon for those who may need them.
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
3715
days inactive
3745
days old
27 comments
8 participants
participants (8)
-
Andrew Pogrebennyk -
ashutosh -
Carlos Ruiz Díaz -
Klaus Darilion -
Mihai Marin -
Muhammad Shahzad -
prevelikzalogaj -
Richard Fuchs