8 Oct
2012
8 Oct
'12
2:18 p.m.
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the param "c"
in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will set up different IP to
send RTP depend on media type.
I have tested this function, but it rewrites always all the "c" parameter with
the same value.
Is there any option to use the function or to rewrite "c" value for each media
type independently?
Many thanks.
Br,
Marina
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica
de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
8 Oct
8 Oct
4:25 p.m.
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset
for non existent c values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached
patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the
param "c" in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will
set up different IP to send RTP depend on media type.
I have tested this function, but it rewrites always all the "c"
parameter with the same value.
Is there any option to use the function or to rewrite "c" value for
each media type independently?
Many thanks.
Br,
Marina
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
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:04 p.m.
Hello,
I understood that Marina is looking for the option of being able to use
different IP addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second
parameter (or taken for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of
ip addresses in the second parameter. For now the solution is to use
rtpproxy to rewrite all the IP addresses in c= lines with the IP address
of the rtpproxy. RTPProxy will then dispatch RTP to the right IP address
assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset
for non existent c values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached
patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the
param "c" in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will
set up different IP to send RTP depend on media type.
I have tested this function, but it rewrites always all the "c"
parameter with the same value.
Is there any option to use the function or to rewrite "c" value for
each media type independently?
Many thanks.
Br,
Marina
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
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:05 p.m.
New subject: how to use fix_nated_sdp("2") with multiple media types
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this case, it
replaces all the c= lines with this public IP, included c=lines in media descriptions and
then, the rtp traffic is not routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through rtpproxy in sip server and
then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando
<vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>, Marina
Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
I understood that Marina is looking for the option of being able to use different IP
addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second parameter (or taken
for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of ip addresses in the
second parameter. For now the solution is to use rtpproxy to rewrite all the IP addresses
in c= lines with the IP address of the rtpproxy. RTPProxy will then dispatch RTP to the
right IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset for non existent c
values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the param "c"
in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will set up different IP to
send RTP depend on media type.
I have tested this function, but it rewrites always all the "c" parameter with
the same value.
Is there any option to use the function or to rewrite "c" value for each media
type independently?
Many thanks.
Br,
Marina
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
9 Oct
9 Oct
1:18 a.m.
Hello,
you should not set the second parameter of rtpproxy_manage(...), let it
be the one returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be
replaced by the rtpproxy ip, but providing different ports for each
media stream.
Practically the rtp streams are going from end device to rtpproxy and
then based on port will be delivered to different IPs of the MCU. Also,
the MCU will send from different IPs to RTPProxy on different ports and
from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this case,
it replaces all the c= lines with this public IP, included c=lines in
media descriptions and then, the rtp traffic is not routing to the
right IP in MCU.
Have I to set up any value/param….to route rtp traffic through
rtpproxy in sip server and then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando <vhernando(a)systemonenoc.com
<mailto:vhernando@systemonenoc.com>>, Marina Serrano Montes
<marinas(a)tid.es <mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
I understood that Marina is looking for the option of being able to
use different IP addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second
parameter (or taken for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of
ip addresses in the second parameter. For now the solution is to use
rtpproxy to rewrite all the IP addresses in c= lines with the IP
address of the rtpproxy. RTPProxy will then dispatch RTP to the right
IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing
list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly
reset for non existent c values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the
attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when
we have an scenario with multiple media types (audio and video) and
the param "c" in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will
set up different IP to send RTP depend on media type.
I have tested this function, but it rewrites always all the "c"
parameter with the same value.
Is there any option to use the function or to rewrite "c" value for
each media type independently?
Many thanks.
Br,
Marina
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo
electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
11:57 a.m.
New subject: how to use fix_nated_sdp("2") with multiple media types
Hi Daniel,
Thanks. But, I think there is any think I have not understand.
I have my route[MCU] module with the following code:
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8"); //where 195.235.93.8 -->public
IP of sip server with rtpproxy
}
}
}
}
If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic from MCU to
rtpproxy is received (testing using tcpdump), but traffic from endpoint to rtpproxy is not
received and therefore, input traffic MCU is null. In this case, using only:
rtpproxy_manage(), the IP in SDP are not replaced by rtpproxy IP.
If I don't comment t_on_reply("CHANGE_SDP"), in this case, I force to
replace IP using "fix_nated_sdp("2", publicIP)" and I can observe
using tcpdump in server than traffic from endpoint from rtpproxy is received, but traffic
from rtpproxy to MCU is not received and traffic from MCU to rtpproxy is not received.
My question is, how can I set up using "rtpproxy_manage(),…."to allow all there
traffic will be routed rightly through rtpproxy?
Should I add any new line in my config file? Anything to change?
Many thanks.
I attach part of the full route file:
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
# NAT detection
route(NATDETECT);
### only initial requests (no To tag)
t_check_trans();
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE"))
record_route_preset("195.235.93.8:5070;transport=TCP");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
# account only INVITEs
if (is_method("INVITE"))
{
setflag(FLT_ACC); # do accounting
}
#ggb: TCP connection reuse
if (proto != UDP) {
add_contact_alias();
}
# dispatch requests to foreign domains
route(SIPOUT);
### requests for my local domains
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(MCU);
route(RELAY);
}
route[RELAY] {
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_on_failure("MANAGE_FAILURE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
xlog("fix_nated_register");
fix_nated_register();
} else {
xlog("fix_nated_contact");
fix_nated_contact();
}
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;
rtpproxy_manage("", "195.235.93.8");
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
# Routing to foreign domains
route[SIPOUT] {
if (!uri==myself)
{
append_hf("P-hint: outbound\r\n");
route(RELAY);
}
}
# manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
#ggb: TCP connection reuse
add_contact_alias();
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8");
}
}
}
}
# manage failure routing cases
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
#!ifdef WITH_BLOCK3XX
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404","Not found");
exit;
}
#!endif
}
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 00:18
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
you should not set the second parameter of rtpproxy_manage(...), let it be the one
returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be replaced by the rtpproxy
ip, but providing different ports for each media stream.
Practically the rtp streams are going from end device to rtpproxy and then based on port
will be delivered to different IPs of the MCU. Also, the MCU will send from different IPs
to RTPProxy on different ports and from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this case, it
replaces all the c= lines with this public IP, included c=lines in media descriptions and
then, the rtp traffic is not routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through rtpproxy in sip server and
then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando
<vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>, Marina
Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
I understood that Marina is looking for the option of being able to use different IP
addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second parameter (or taken
for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of ip addresses in the
second parameter. For now the solution is to use rtpproxy to rewrite all the IP addresses
in c= lines with the IP address of the rtpproxy. RTPProxy will then dispatch RTP to the
right IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset for non existent c
values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the param "c"
in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will set up different IP to
send RTP depend on media type.
I have tested this function, but it rewrites always all the "c" parameter with
the same value.
Is there any option to use the function or to rewrite "c" value for each media
type independently?
Many thanks.
Br,
Marina
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
12:47 p.m.
Hello,
in the onreply_route block use rtpproxy_manage(), not fix_nated_sdp().
Cheers,
Daniel
On 10/9/12 10:57 AM, MARINA SERRANO MONTES wrote:
Hi Daniel,
Thanks. But, I think there is any think I have not understand.
I have my route[MCU] module with the following code:
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
*fix_nated_sdp("2", "195.235.93.8"); *//where 195.235.93.8
-->public
IP of sip server with rtpproxy
}
}
}
}
If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic from
MCU to rtpproxy is received (testing using tcpdump), but traffic from
endpoint to rtpproxy is not received and therefore, input traffic MCU
is null. In this case, using only: rtpproxy_manage(),* the IP in SDP
are not replaced by rtpproxy IP.*
If I don't comment t_on_reply("CHANGE_SDP"), in this case, I force to
replace IP using "fix_nated_sdp("2", publicIP)" and I can observe
using tcpdump in server than traffic from endpoint from rtpproxy is
received, but traffic from rtpproxy to MCU is not received and traffic
from MCU to rtpproxy is not received.
My question is, how can I set up using "rtpproxy_manage(),…."to allow
all there traffic will be routed rightly through rtpproxy?
Should I add any new line in my config file? Anything to change?
Many thanks.
I attach part of the full route file:
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
# NAT detection
route(NATDETECT);
### only initial requests (no To tag)
t_check_trans();
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE"))
record_route_preset("195.235.93.8:5070;transport=TCP");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
# account only INVITEs
if (is_method("INVITE"))
{
setflag(FLT_ACC); # do accounting
}
#ggb: TCP connection reuse
if (proto != UDP) {
add_contact_alias();
}
# dispatch requests to foreign domains
route(SIPOUT);
### requests for my local domains
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(MCU);
route(RELAY);
}
route[RELAY] {
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_on_failure("MANAGE_FAILURE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
xlog("fix_nated_register");
fix_nated_register();
} else {
xlog("fix_nated_contact");
fix_nated_contact();
}
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;
rtpproxy_manage("", "195.235.93.8");
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
# Routing to foreign domains
route[SIPOUT] {
if (!uri==myself)
{
append_hf("P-hint: outbound\r\n");
route(RELAY);
}
}
# manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
#ggb: TCP connection reuse
add_contact_alias();
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8");
}
}
}
}
# manage failure routing cases
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
#!ifdef WITH_BLOCK3XX
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404","Not found");
exit;
}
#!endif
}
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
*
*
Br,
Marina
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 00:18
To: Marina Serrano Montes <marinas(a)tid.es <mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>, Vicente Hernando
<vhernando(a)systemonenoc.com <mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
you should not set the second parameter of rtpproxy_manage(...), let
it be the one returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be
replaced by the rtpproxy ip, but providing different ports for each
media stream.
Practically the rtp streams are going from end device to rtpproxy and
then based on port will be delivered to different IPs of the MCU.
Also, the MCU will send from different IPs to RTPProxy on different
ports and from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this
case, it replaces all the c= lines with this public IP, included
c=lines in media descriptions and then, the rtp traffic is not
routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through
rtpproxy in sip server and then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando <vhernando(a)systemonenoc.com
<mailto:vhernando@systemonenoc.com>>, Marina Serrano Montes
<marinas(a)tid.es <mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
I understood that Marina is looking for the option of being able to
use different IP addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second
parameter (or taken for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list
of ip addresses in the second parameter. For now the solution is to
use rtpproxy to rewrite all the IP addresses in c= lines with the IP
address of the rtpproxy. RTPProxy will then dispatch RTP to the right
IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing
list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly
reset for non existent c values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the
attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when
we have an scenario with multiple media types (audio and video) and
the param "c" in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will
set up different IP to send RTP depend on media type.
I have tested this function, but it rewrites always all the "c"
parameter with the same value.
Is there any option to use the function or to rewrite "c" value for
each media type independently?
Many thanks.
Br,
Marina
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo
electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only
send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
1:57 p.m.
New subject: how to use fix_nated_sdp("2") with multiple media types
Hi Daniel,
I'm sorry, but the traffic between rtpproxy and MCU and from MCU to rtpproxy is not
received.
I have used "rtpproxy_manage()" in onreply_route[ ]…and I can observe traffic
from endpoint to RTPPROXY is sent and received but, from rtpproxy to MCU and from MCU to
rtpproxy I cannot receive any traffic.
Is it possible RTPPROXY don't know where must send traffic to MCU?
Many thanks.
Br,
Marina
I attach the SIP messages:
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: <sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bK6525.28425344.0;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 347.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.94.142.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 6448 RTP/AVP 0 101.
c=IN IP4 10.95.94.142.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 10046 RTP/AVP 96.
c=IN IP4 10.95.94.143.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
T 10.95.92.94:5070 -> 88.30.60.53:49220 [AP]
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: <sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 363.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.92.94.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 15460 RTP/AVP 0 101.
c=IN IP4 10.95.92.94.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 15018 RTP/AVP 96.
c=IN IP4 10.95.92.94.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
a=nortpproxy:yes.
T 88.30.60.53:49220 -> 10.95.92.94:5070 [AP]
ACK sip:831234@10.95.94.142:5070 SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.68:49220;rport;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 70.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Content-Length: 0.
.
U 10.95.92.94:5070 -> 10.95.94.142:5070
ACK sip:831234@10.95.94.142:5070 SIP/2.0.
Via: SIP/2.0/UDP 195.235.93.8:5070;branch=z9hG4bKcydzigwkX;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 69.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Content-Length: 0.
.
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 11:47
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
in the onreply_route block use rtpproxy_manage(), not fix_nated_sdp().
Cheers,
Daniel
On 10/9/12 10:57 AM, MARINA SERRANO MONTES wrote:
Hi Daniel,
Thanks. But, I think there is any think I have not understand.
I have my route[MCU] module with the following code:
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8"); //where 195.235.93.8 -->public
IP of sip server with rtpproxy
}
}
}
}
If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic from MCU to
rtpproxy is received (testing using tcpdump), but traffic from endpoint to rtpproxy is not
received and therefore, input traffic MCU is null. In this case, using only:
rtpproxy_manage(), the IP in SDP are not replaced by rtpproxy IP.
If I don't comment t_on_reply("CHANGE_SDP"), in this case, I force to
replace IP using "fix_nated_sdp("2", publicIP)" and I can observe
using tcpdump in server than traffic from endpoint from rtpproxy is received, but traffic
from rtpproxy to MCU is not received and traffic from MCU to rtpproxy is not received.
My question is, how can I set up using "rtpproxy_manage(),…."to allow all there
traffic will be routed rightly through rtpproxy?
Should I add any new line in my config file? Anything to change?
Many thanks.
I attach part of the full route file:
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
# NAT detection
route(NATDETECT);
### only initial requests (no To tag)
t_check_trans();
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE"))
record_route_preset("195.235.93.8:5070;transport=TCP");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
# account only INVITEs
if (is_method("INVITE"))
{
setflag(FLT_ACC); # do accounting
}
#ggb: TCP connection reuse
if (proto != UDP) {
add_contact_alias();
}
# dispatch requests to foreign domains
route(SIPOUT);
### requests for my local domains
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(MCU);
route(RELAY);
}
route[RELAY] {
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_on_failure("MANAGE_FAILURE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
xlog("fix_nated_register");
fix_nated_register();
} else {
xlog("fix_nated_contact");
fix_nated_contact();
}
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;
rtpproxy_manage("", "195.235.93.8");
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
# Routing to foreign domains
route[SIPOUT] {
if (!uri==myself)
{
append_hf("P-hint: outbound\r\n");
route(RELAY);
}
}
# manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
#ggb: TCP connection reuse
add_contact_alias();
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8");
}
}
}
}
# manage failure routing cases
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
#!ifdef WITH_BLOCK3XX
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404","Not found");
exit;
}
#!endif
}
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 00:18
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
you should not set the second parameter of rtpproxy_manage(...), let it be the one
returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be replaced by the rtpproxy
ip, but providing different ports for each media stream.
Practically the rtp streams are going from end device to rtpproxy and then based on port
will be delivered to different IPs of the MCU. Also, the MCU will send from different IPs
to RTPProxy on different ports and from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this case, it
replaces all the c= lines with this public IP, included c=lines in media descriptions and
then, the rtp traffic is not routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through rtpproxy in sip server and
then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando
<vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>, Marina
Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
I understood that Marina is looking for the option of being able to use different IP
addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second parameter (or taken
for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of ip addresses in the
second parameter. For now the solution is to use rtpproxy to rewrite all the IP addresses
in c= lines with the IP address of the rtpproxy. RTPProxy will then dispatch RTP to the
right IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset for non existent c
values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the param "c"
in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will set up different IP to
send RTP depend on media type.
I have tested this function, but it rewrites always all the "c" parameter with
the same value.
Is there any option to use the function or to rewrite "c" value for each media
type independently?
Many thanks.
Br,
Marina
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
2:11 p.m.
Hello,
from the trace it seems that mcu is on a private network. Also, rtpproxy
seems to be configured to listen on a private address. But then the
response is sent to a public address.
First, is the routing between the two networks configured on the server
where kamailio/rtpproxy runs? rtproxy should be on public interface to
be able to talk with the clients on the public network.
Then, with rtpproxy, each side has to send a packet in order to know
where to send the packets. Does MCU send packets? If not you can try to
add flag 'r' for messages coming from it.
If the networks are not interconnected at ip layer, then you should use
rtpproxy in bridge mode. That requires more flags to rtpproxy_manage()
parameter as well as extra command line parameter for rtpproxy application.
One example of doing bridging with kamailio and rtpproxy is presented in
the tutorial:
- http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6
Should give a better view of how to do it, practically you have to
listen on a second ipv4 address instead of ipv6.
For the future, if you give the ngrep, give also the INVITE requests
along with the 200ok, in that way we can spot what is wrong with the
call better.
Cheers,
Daniel
On 10/9/12 12:57 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I'm sorry, but the traffic between rtpproxy and MCU and from MCU to
rtpproxy is not received.
I have used "rtpproxy_manage()" in onreply_route[ ]…and I can observe
traffic from endpoint to RTPPROXY is sent and received but, from
rtpproxy to MCU and from MCU to rtpproxy I cannot receive any traffic.
Is it possible RTPPROXY don't know where must send traffic to MCU?
Many thanks.
Br,
Marina
I attach the SIP messages:
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
<sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bK6525.28425344.0;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 347.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.94.142.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 6448 RTP/AVP 0 101.
c=IN IP4 10.95.94.142.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 10046 RTP/AVP 96.
c=IN IP4 10.95.94.143.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
T 10.95.92.94:5070 -> 88.30.60.53:49220 [AP]
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
<sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 363.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.92.94.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 15460 RTP/AVP 0 101.
c=IN IP4 10.95.92.94.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 15018 RTP/AVP 96.
c=IN IP4 10.95.92.94.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
a=nortpproxy:yes.
T 88.30.60.53:49220 -> 10.95.92.94:5070 [AP]
ACK sip:831234@10.95.94.142:5070 SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.68:49220;rport;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 70.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Content-Length: 0.
.
U 10.95.92.94:5070 -> 10.95.94.142:5070
ACK sip:831234@10.95.94.142:5070 SIP/2.0.
Via: SIP/2.0/UDP 195.235.93.8:5070;branch=z9hG4bKcydzigwkX;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 69.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To: sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Content-Length: 0.
.
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 11:47
To: Marina Serrano Montes <marinas(a)tid.es <mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>, Vicente Hernando
<vhernando(a)systemonenoc.com <mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
in the onreply_route block use rtpproxy_manage(), not fix_nated_sdp().
Cheers,
Daniel
On 10/9/12 10:57 AM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
Hi Daniel,
Thanks. But, I think there is any think I have not understand.
I have my route[MCU] module with the following code:
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
*fix_nated_sdp("2", "195.235.93.8"); *//where 195.235.93.8
-->public
IP of sip server with rtpproxy
}
}
}
}
If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic
from MCU to rtpproxy is received (testing using tcpdump), but traffic
from endpoint to rtpproxy is not received and therefore, input
traffic MCU is null. In this case, using only:
rtpproxy_manage(),* the IP in SDP are not replaced by rtpproxy IP.*
If I don't comment t_on_reply("CHANGE_SDP"), in this case, I force
to replace IP using "fix_nated_sdp("2", publicIP)" and I can observe
using tcpdump in server than traffic from endpoint from rtpproxy is
received, but traffic from rtpproxy to MCU is not received and
traffic from MCU to rtpproxy is not received.
My question is, how can I set up using "rtpproxy_manage(),…."to allow
all there traffic will be routed rightly through rtpproxy?
Should I add any new line in my config file? Anything to change?
Many thanks.
I attach part of the full route file:
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
# NAT detection
route(NATDETECT);
### only initial requests (no To tag)
t_check_trans();
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE"))
record_route_preset("195.235.93.8:5070;transport=TCP");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
# account only INVITEs
if (is_method("INVITE"))
{
setflag(FLT_ACC); # do accounting
}
#ggb: TCP connection reuse
if (proto != UDP) {
add_contact_alias();
}
# dispatch requests to foreign domains
route(SIPOUT);
### requests for my local domains
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(MCU);
route(RELAY);
}
route[RELAY] {
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_on_failure("MANAGE_FAILURE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
xlog("fix_nated_register");
fix_nated_register();
} else {
xlog("fix_nated_contact");
fix_nated_contact();
}
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;
rtpproxy_manage("", "195.235.93.8");
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
# Routing to foreign domains
route[SIPOUT] {
if (!uri==myself)
{
append_hf("P-hint: outbound\r\n");
route(RELAY);
}
}
# manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
#ggb: TCP connection reuse
add_contact_alias();
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8");
}
}
}
}
# manage failure routing cases
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
#!ifdef WITH_BLOCK3XX
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404","Not found");
exit;
}
#!endif
}
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
*
*
Br,
Marina
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 00:18
To: Marina Serrano Montes <marinas(a)tid.es <mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>, Vicente Hernando
<vhernando(a)systemonenoc.com <mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
you should not set the second parameter of rtpproxy_manage(...), let
it be the one returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be
replaced by the rtpproxy ip, but providing different ports for each
media stream.
Practically the rtp streams are going from end device to rtpproxy and
then based on port will be delivered to different IPs of the MCU.
Also, the MCU will send from different IPs to RTPProxy on different
ports and from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this
case, it replaces all the c= lines with this public IP, included
c=lines in media descriptions and then, the rtp traffic is not
routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through
rtpproxy in sip server and then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda(a)gmail.com
<mailto:miconda@gmail.com>>
Reply-To: "miconda(a)gmail.com <mailto:miconda@gmail.com>"
<miconda(a)gmail.com <mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) -
Users Mailing List" <sr-users(a)lists.sip-router.org
<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando <vhernando(a)systemonenoc.com
<mailto:vhernando@systemonenoc.com>>, Marina Serrano Montes
<marinas(a)tid.es <mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple
media types
Hello,
I understood that Marina is looking for the option of being able to
use different IP addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second
parameter (or taken for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list
of ip addresses in the second parameter. For now the solution is to
use rtpproxy to rewrite all the IP addresses in c= lines with the IP
address of the rtpproxy. RTPProxy will then dispatch RTP to the
right IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev
mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo electrónico
en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly
reset for non existent c values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the
attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
> Hi,
>
> I have a doubt about how to use "fix_nated_sdp("2")" function
when
> we have an scenario with multiple media types (audio and video)
> and the param "c" in sdp for each media type has a different IP.
> We are using a SCOPIA 400 MCU to multi-party in a call, and it
> will set up different IP to send RTP depend on media type.
>
> I have tested this function, but it rewrites always all the "c"
> parameter with the same value.
>
> Is there any option to use the function or to rewrite "c" value
> for each media type independently?
>
> Many thanks.
>
> Br,
> Marina
>
> ------------------------------------------------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede
> consultar nuestra política de envío y recepción de correo
> electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only
> send and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -http://www.asipto.comhttp://twitter.com/#!/miconda
-http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 -http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 -http://asipto.com/u/katu
------------------------------------------------------------------------
Este mensaje se dirige exclusivamente a su destinatario. Puede
consultar nuestra política de envío y recepción de correo
electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send
and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
2:36 p.m.
New subject: how to use fix_nated_sdp("2") with multiple media types
Hi Daniel:
The network is:
* MCU is running in a private network with IP's (10.95.94.142 and 10.95.94.143)
and public IP's 195.235.93.166 and 195.235.93.161.
* SIP server and rtpproxy are running in another network: 10.95.94.92, with public IP:
195.235.93.8.
* SIP server, rtpproxy and MCU has visibility between them.
* Clients have not visibility with sip server and MCU, and they try register,
invite,….using the public IP: 195.235.93.8 (public IP of rtpproxy)
* When I have not use MCU, only 2 participants, the video and audio is routing OK.
* I can verify using web browser conference in MCU that it is sending RTP traffic (out
traffic).
Thank you very much.
Br,
Marina
I attach the sip messages of a call with/without MCU:
WITHOUT MCU:
T 88.30.60.53:49605 -> 10.95.92.94:5070 [AP]
INVITE sip:34625721615@yarn.com<mailto:34625721615@yarn.com> SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Max-Forwards: 70.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To: sip:34625721615@yarn.com<mailto:34625721615@yarn.com>.
Contact: "iPhone de Marina Serrano Montes"
<sip:34625827802@192.168.1.71<mailto:34625827802@192.168.1.71>:49604;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000a84e595a>".
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
CSeq: 3285 INVITE.
Route: <sip:xmpp.reflections.tid.es:5070;transport=TCP;lr>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: on.
GeoPosition: 37.160355 -3.608621.
Comm-Type: videoCall.
Content-Type: application/sdp.
Content-Length: 521.
.
v=0.
o=- 3558762206 3558762206 IN IP4 192.168.1.71.
s=pjmedia.
c=IN IP4 192.168.1.71.
t=0 0.
a=X-nat:0.
m=audio 40000 RTP/AVP 104 3 0 8 96.
c=IN IP4 192.168.1.71.
a=rtcp:40001 IN IP4 192.168.1.71.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 40002 RTP/AVP 96.
c=IN IP4 192.168.1.71.
a=rtcp:40003 IN IP4 192.168.1.71.
a=sendrecv.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2;MaxBR=1920.
T 10.95.92.94:5070 -> 88.30.60.53:49605 [AP]
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2;received=88.30.60.53.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To: sip:34625721615@yarn.com<mailto:34625721615@yarn.com>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
CSeq: 3285 INVITE.
Server: kamailio (3.2.0 (x86_64/linux)).
Content-Length: 0.
.
T 10.95.92.94:5070 -> 88.30.60.53:49207 [A]
INVITE
sip:34625721615@192.168.1.68<mailto:34625721615@192.168.1.68>:49162;transport=TCP;ob
SIP/2.0.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Via: SIP/2.0/TCP 195.235.93.8:5070;branch=z9hG4bK7f3e.5b307fb4.0;i=42.
Via: SIP/2.0/TCP
192.168.1.71:49605;received=88.30.60.53;rport=49605;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Max-Forwards: 69.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To: sip:34625721615@yarn.com<mailto:34625721615@yarn.com>.
Contact: "iPhone de Marina Serrano Montes"
<sip:34625827802@88.30.60.53<mailto:34625827802@88.30.60.53>:49605;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000a84e595a>".
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
CSeq: 3285 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: on.
GeoPosition: 37.160355 -3.608621.
Comm-Type: videoCall.
Content-Type: application/sdp.
Content-Length: 499.
.
v=0.
o=- 3558762206 3558762206 IN IP4 195.235.93.8.
s=pjmedia.
c=IN IP4 192.168.1.71.
t=0 0.
a=X-nat:0.
m=audio 12204 RTP/AVP 104 3 0 8 96.
c=IN IP4 195.235.93.8.
a=rtcp:12205.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 13428 RTP/AVP 96.
c=IN IP4 195.235.93.8.
a=rtcp:13429.
a=sen
T 10.95.92.94:5070 -> 88.30.60.53:49207 [AP]
drecv.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2;MaxBR=1920.
a=nortpproxy:yes.
T 10.95.92.94:5070 -> 88.30.60.53:49207 [A]
INVITE
sip:34625721615@192.168.1.68<mailto:34625721615@192.168.1.68>:49162;transport=TCP;ob
SIP/2.0.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Via: SIP/2.0/TCP 195.235.93.8:5070;branch=z9hG4bK7f3e.5b307fb4.0;i=42.
Via: SIP/2.0/TCP
192.168.1.71:49605;received=88.30.60.53;rport=49605;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Max-Forwards: 69.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To: sip:34625721615@yarn.com<mailto:34625721615@yarn.com>.
Contact: "iPhone de Marina Serrano Montes"
<sip:34625827802@88.30.60.53<mailto:34625827802@88.30.60.53>:49605;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000a84e595a>".
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
CSeq: 3285 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: on.
GeoPosition: 37.160355 -3.608621.
Comm-Type: videoCall.
Content-Type: application/sdp.
Content-Length: 499.
.
v=0.
o=- 3558762206 3558762206 IN IP4 195.235.93.8.
s=pjmedia.
c=IN IP4 192.168.1.71.
t=0 0.
a=X-nat:0.
m=audio 12204 RTP/AVP 104 3 0 8 96.
c=IN IP4 195.235.93.8.
a=rtcp:12205.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 13428 RTP/AVP 96.
c=IN IP4 195.235.93.8.
a=rtcp:13429.
a=sen
T 88.30.60.53:49207 -> 10.95.92.94:5070 [AP]
SIP/2.0 100 Trying.
Via: SIP/2.0/TCP
195.235.93.8:5070;received=195.235.93.8;branch=z9hG4bK7f3e.5b307fb4.0;i=42.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;received=88.30.60.53;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To: <sip:34625721615@yarn.com<mailto:34625721615@yarn.com>>.
CSeq: 3285 INVITE.
Content-Length: 0.
.
T 88.30.60.53:49207 -> 10.95.92.94:5070 [AP]
SIP/2.0 180 Ringing.
Via: SIP/2.0/TCP
195.235.93.8:5070;received=195.235.93.8;branch=z9hG4bK7f3e.5b307fb4.0;i=42.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;received=88.30.60.53;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To:
<sip:34625721615@yarn.com<mailto:34625721615@yarn.com>>;tag=MqvoM-k8VyY78sSmvFhTc3hBCviTxJX..
CSeq: 3285 INVITE.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@192.168.1.68<mailto:34625721615@192.168.1.68>:49162;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Content-Length: 0.
T 10.95.92.94:5070 -> 88.30.60.53:49605 [AP]
SIP/2.0 180 Ringing.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;received=88.30.60.53;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To:
<sip:34625721615@yarn.com<mailto:34625721615@yarn.com>>;tag=MqvoM-k8VyY78sSmvFhTc3hBCviTxJX..
CSeq: 3285 INVITE.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@88.30.60.53<mailto:34625721615@88.30.60.53>:49207;transport=TCP;ob;alias=88.30.60.53~49207~2>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Content-Length: 0.
T 88.30.60.53:49207 -> 10.95.92.94:5070 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
195.235.93.8:5070;received=195.235.93.8;branch=z9hG4bK7f3e.5b307fb4.0;i=42.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;received=88.30.60.53;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To:
<sip:34625721615@yarn.com<mailto:34625721615@yarn.com>>;tag=MqvoM-k8VyY78sSmvFhTc3hBCviTxJX..
CSeq: 3285 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@192.168.1.68<mailto:34625721615@192.168.1.68>:49162;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: off.
GeoPosition: 37.160417 -3.608510.
Comm-Type: call.
Content-Type: application/sdp.
Content-Length: 342.
.
v=0.
o=- 3558762206 3558762208 IN IP4 192.168.1.68.
s=pjmedia.
c=IN IP4 192.168.1.68.
t=0 0.
a=X-nat:0.
m=audio 40008 RTP/AVP 104 96.
c=IN IP4 192.168.1.68.
a=rtcp:40009 IN IP4 192.168.1.68.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 0 RTP/AVP 96.
c=IN IP4 192.168.1.68.
T 10.95.92.94:5070 -> 88.30.60.53:49605 [AP]
SIP/2.0 200 OK.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport=49605;received=88.30.60.53;branch=z9hG4bKPjnmOelOoYbCla7mCU1ZZwIzdQgdON9n.2.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To:
<sip:34625721615@yarn.com<mailto:34625721615@yarn.com>>;tag=MqvoM-k8VyY78sSmvFhTc3hBCviTxJX..
CSeq: 3285 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@88.30.60.53<mailto:34625721615@88.30.60.53>:49207;transport=TCP;ob;alias=88.30.60.53~49207~2>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: off.
GeoPosition: 37.160417 -3.608510.
Comm-Type: call.
Content-Type: application/sdp.
Content-Length: 340.
.
v=0.
o=- 3558762206 3558762208 IN IP4 195.235.93.8.
s=pjmedia.
c=IN IP4 192.168.1.68.
t=0 0.
a=X-nat:0.
m=audio 13054 RTP/AVP 104 96.
c=IN IP4 195.235.93.8.
a=rtcp:13055.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 0 RTP/AVP 96.
c=IN IP4 195.235.93.8.
a=nortpproxy:yes.
T 88.30.60.53:49605 -> 10.95.92.94:5070 [AP]
ACK
sip:34625721615@88.30.60.53<mailto:34625721615@88.30.60.53>:49207;transport=TCP;ob;alias=88.30.60.53~49207~2
SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.71:49605;rport;branch=z9hG4bKPj1wkmjQjqE5tBkJDPhdE0pxH1P8Ourw8a.
Max-Forwards: 70.
From: "iPhone de Marina Serrano Montes"
<sip:34625827802@yarn.com<mailto:34625827802@yarn.com>>;tag=m9-qrLO0Itty8c7TEo5fZDLswOd1pAYX.
To:
sip:34625721615@yarn.com<mailto:34625721615@yarn.com>;tag=MqvoM-k8VyY78sSmvFhTc3hBCviTxJX..
Call-ID: bBNsUTKBEuqIPP2MgpotcpSJzYJTqRz9.
CSeq: 3285 ACK.
Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Content-Length: 0.
WITH MCU
T 88.30.60.53:49288 -> 10.95.92.94:5070 [AP]
INVITE sip:831234@yarn.com SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.68:49288;rport;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Max-Forwards: 70.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: sip:831234@yarn.com.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@192.168.1.68:49162;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Route: <sip:xmpp.reflections.tid.es:5070;transport=TCP;lr>.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: on.
GeoPosition: 37.160370 -3.608576.
Comm-Type: videoCall.
Content-Type: application/sdp.
Content-Length: 521.
.
v=0.
o=- 3558771315 3558771315 IN IP4 192.168.1.68.
s=pjmedia.
c=IN IP4 192.168.1.68.
t=0 0.
a=X-nat:0.
m=audio 40022 RTP/AVP 104 3 0 8 96.
c=IN IP4 192.168.1.68.
a=rtcp:40023 IN IP4 192.168.1.68.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 40024 RTP/AVP 96.
c=IN IP4 192.168.1.68.
a=rtcp:40025 IN IP4 192.168.1.68.
a=sendrecv.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2;MaxBR=1920.
T 10.95.92.94:5070 -> 88.30.60.53:49288 [AP]
SIP/2.0 100 trying -- your call is important to us.
Via: SIP/2.0/TCP
192.168.1.68:49288;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo;received=88.30.60.53.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: sip:831234@yarn.com.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Server: kamailio (3.2.0 (x86_64/linux)).
Content-Length: 0.
.
U 10.95.92.94:5070 -> 10.95.94.142:5070
INVITE sip:831234@10.95.94.142:5070 SIP/2.0.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Via: SIP/2.0/UDP 195.235.93.8:5070;branch=z9hG4bKad5f.9a00a88.0;i=63.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Max-Forwards: 69.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: sip:831234@yarn.com.
Contact: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@88.30.60.53:49288;transport=TCP;ob>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000bcd83dda>".
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, SUBSCRIBE, NOTIFY, REFER, MESSAGE,
OPTIONS.
Supported: replaces, 100rel, timer, norefersub.
Comm-Logging: on.
GeoPosition: 37.160370 -3.608576.
Comm-Type: videoCall.
Content-Type: application/sdp.
Content-Length: 521.
.
v=0.
o=- 3558771315 3558771315 IN IP4 192.168.1.68.
s=pjmedia.
c=IN IP4 192.168.1.68.
t=0 0.
a=X-nat:0.
m=audio 40022 RTP/AVP 104 3 0 8 96.
c=IN IP4 192.168.1.68.
a=rtcp:40023 IN IP4 192.168.1.68.
a=sendrecv.
a=rtpmap:104 iLBC/8000.
a=fmtp:104 mode=30.
a=rtpmap:3 GSM/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=rtpmap:96 telephone-event/8000.
a=fmtp:96 0-15.
m=video 40024 RTP/AVP 96.
c=IN IP4 192.168.1.68.
a=rtcp:40025 IN IP4 192.168.1.68.
a=sendrecv.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2;MaxBR=1920.
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 100 Trying.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: <sip:831234@yarn.com>.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bKad5f.9a00a88.0;i=63.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Supported: replaces.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Length: 0.
.
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 180 Ringing.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: <sip:831234@yarn.com>;tag=96e0830-a5f5e8e-13ce-45026-11b83-3ae1923-11b83.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bKad5f.9a00a88.0;i=63.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Supported: replaces.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Length: 0.
.
T 10.95.92.94:5070 -> 88.30.60.53:49288 [AP]
SIP/2.0 180 Ringing.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: <sip:831234@yarn.com>;tag=96e0830-a5f5e8e-13ce-45026-11b83-3ae1923-11b83.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Supported: replaces.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Length: 0.
.
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: <sip:831234@yarn.com>;tag=96e0830-a5f5e8e-13ce-45026-11b83-3ae1923-11b83.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bKad5f.9a00a88.0;i=63.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 347.
.
v=0.
o=RV-MCU 72580140 72580140 IN IP4 10.95.94.142.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 6448 RTP/AVP 0 101.
c=IN IP4 10.95.94.142.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 10064 RTP/AVP 96.
c=IN IP4 10.95.94.143.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
T 10.95.92.94:5070 -> 88.30.60.53:49288 [AP]
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com>;tag=OsVGQ2ankjVlh6um7sY6XT85Xw8iZ6Jr.
To: <sip:831234@yarn.com>;tag=96e0830-a5f5e8e-13ce-45026-11b83-3ae1923-11b83.
Call-ID: W9-vrfxNkjewLu7.ZV.CDlE9UVzLexuI.
CSeq: 28670 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/TCP
192.168.1.68:49288;received=88.30.60.53;rport=49288;branch=z9hG4bKPj6p9mKJtxQYThQTWoy5kT8XiZndLpe0qo.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 363.
.
v=0.
o=RV-MCU 72580140 72580140 IN IP4 10.95.92.94.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 10154 RTP/AVP 0 101.
c=IN IP4 10.95.92.94.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 16952 RTP/AVP 96.
c=IN IP4 10.95.92.94.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
a=nortpproxy:yes.
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 13:11
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
from the trace it seems that mcu is on a private network. Also, rtpproxy seems to be
configured to listen on a private address. But then the response is sent to a public
address.
First, is the routing between the two networks configured on the server where
kamailio/rtpproxy runs? rtproxy should be on public interface to be able to talk with the
clients on the public network.
Then, with rtpproxy, each side has to send a packet in order to know where to send the
packets. Does MCU send packets? If not you can try to add flag 'r' for messages
coming from it.
If the networks are not interconnected at ip layer, then you should use rtpproxy in bridge
mode. That requires more flags to rtpproxy_manage() parameter as well as extra command
line parameter for rtpproxy application.
One example of doing bridging with kamailio and rtpproxy is presented in the tutorial:
- http://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6
Should give a better view of how to do it, practically you have to listen on a second ipv4
address instead of ipv6.
For the future, if you give the ngrep, give also the INVITE requests along with the 200ok,
in that way we can spot what is wrong with the call better.
Cheers,
Daniel
On 10/9/12 12:57 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I'm sorry, but the traffic between rtpproxy and MCU and from MCU to rtpproxy is not
received.
I have used "rtpproxy_manage()" in onreply_route[ ]…and I can observe traffic
from endpoint to RTPPROXY is sent and received but, from rtpproxy to MCU and from MCU to
rtpproxy I cannot receive any traffic.
Is it possible RTPPROXY don't know where must send traffic to MCU?
Many thanks.
Br,
Marina
I attach the SIP messages:
U 10.95.94.142:5070 -> 10.95.92.94:5070
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com><mailto:sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
<sip:831234@yarn.com><mailto:sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/UDP
195.235.93.8:5070;received=10.95.92.94;branch=z9hG4bK6525.28425344.0;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070><mailto:sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 347.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.94.142.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 6448 RTP/AVP 0 101.
c=IN IP4 10.95.94.142.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 10046 RTP/AVP 96.
c=IN IP4 10.95.94.143.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
T 10.95.92.94:5070 -> 88.30.60.53:49220 [AP]
SIP/2.0 200 OK.
From: "iPhone 4S de Marina Serrano
Montes"<sip:34625721615@yarn.com><mailto:sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
<sip:831234@yarn.com><mailto:sip:831234@yarn.com>;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 INVITE.
User-Agent: OTT VIDEO MCU Ver 5.
Supported: replaces.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjx56lPnLFFvtElMX6Tw1Yc7pJglWsTHl3.
Record-Route: <sip:195.235.93.8:5070;transport=TCP;lr=on>.
Contact: <sip:831234@10.95.94.142:5070><mailto:sip:831234@10.95.94.142:5070>.
Content-Type: application/sdp.
Content-Length: 363.
.
v=0.
o=RV-MCU 64398330 64398330 IN IP4 10.95.92.94.
s=RV MCU Session.
b=CT:128.
t=0 0.
m=audio 15460 RTP/AVP 0 101.
c=IN IP4 10.95.92.94.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=sendrecv.
m=video 15018 RTP/AVP 96.
c=IN IP4 10.95.92.94.
b=TIAS:64000.
a=rtpmap:96 H263-1998/90000.
a=fmtp:96 QCIF=2.
a=sendrecv.
a=nortpproxy:yes.
T 88.30.60.53:49220 -> 10.95.92.94:5070 [AP]
ACK sip:831234@10.95.94.142:5070<mailto:sip:831234@10.95.94.142:5070> SIP/2.0.
Via: SIP/2.0/TCP
192.168.1.68:49220;rport;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 70.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com><mailto:sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d<mailto:sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d>.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Route: <sip:195.235.93.8:5070;transport=TCP;lr>.
Content-Length: 0.
.
U 10.95.92.94:5070 -> 10.95.94.142:5070
ACK sip:831234@10.95.94.142:5070<mailto:sip:831234@10.95.94.142:5070> SIP/2.0.
Via: SIP/2.0/UDP 195.235.93.8:5070;branch=z9hG4bKcydzigwkX;i=1.
Via: SIP/2.0/TCP
192.168.1.68:49220;received=88.30.60.53;rport=49220;branch=z9hG4bKPjFfoWDPVHXuFQpNkwdK8MaC.O81exyyN6.
Max-Forwards: 69.
From: "iPhone 4S de Marina Serrano Montes"
<sip:34625721615@yarn.com><mailto:sip:34625721615@yarn.com>;tag=fjT80oh1Dk4JR7KfLisjcIKO6o4YDjgI.
To:
sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d<mailto:sip:831234@yarn.com;tag=96d7fa0-a5f5e8e-13ce-45026-fb8d-51adfd08-fb8d>.
Call-ID: a9nOyGQ906Farr1Ayrk4vgoJvKXv87Le.
CSeq: 14479 ACK.
Content-Length: 0.
.
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 11:47
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
in the onreply_route block use rtpproxy_manage(), not fix_nated_sdp().
Cheers,
Daniel
On 10/9/12 10:57 AM, MARINA SERRANO MONTES wrote:
Hi Daniel,
Thanks. But, I think there is any think I have not understand.
I have my route[MCU] module with the following code:
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8"); //where 195.235.93.8 -->public
IP of sip server with rtpproxy
}
}
}
}
If I comment t_on_reply("CHANGE_SDP") line, I can observe traffic from MCU to
rtpproxy is received (testing using tcpdump), but traffic from endpoint to rtpproxy is not
received and therefore, input traffic MCU is null. In this case, using only:
rtpproxy_manage(), the IP in SDP are not replaced by rtpproxy IP.
If I don't comment t_on_reply("CHANGE_SDP"), in this case, I force to
replace IP using "fix_nated_sdp("2", publicIP)" and I can observe
using tcpdump in server than traffic from endpoint from rtpproxy is received, but traffic
from rtpproxy to MCU is not received and traffic from MCU to rtpproxy is not received.
My question is, how can I set up using "rtpproxy_manage(),…."to allow all there
traffic will be routed rightly through rtpproxy?
Should I add any new line in my config file? Anything to change?
Many thanks.
I attach part of the full route file:
# Main SIP request routing logic
# - processing of any incoming SIP request starts with this route
# - note: this is the same as route { ... }
request_route {
# NAT detection
route(NATDETECT);
### only initial requests (no To tag)
t_check_trans();
# record routing for dialog forming requests (in case they are routed)
# - remove preloaded route headers
remove_hf("Route");
if (is_method("INVITE"))
record_route_preset("195.235.93.8:5070;transport=TCP");
if (is_method("INVITE|SUBSCRIBE"))
record_route();
# account only INVITEs
if (is_method("INVITE"))
{
setflag(FLT_ACC); # do accounting
}
#ggb: TCP connection reuse
if (proto != UDP) {
add_contact_alias();
}
# dispatch requests to foreign domains
route(SIPOUT);
### requests for my local domains
if ($rU==$null)
{
# request with no Username in RURI
sl_send_reply("484","Address Incomplete");
exit;
}
route(MCU);
route(RELAY);
}
route[RELAY] {
# enable additional event routes for forwarded requests
# - serial forking, RTP relaying handling, a.s.o.
if (is_method("INVITE|SUBSCRIBE")) {
t_on_branch("MANAGE_BRANCH");
t_on_reply("MANAGE_REPLY");
}
if (is_method("INVITE")) {
t_on_failure("MANAGE_FAILURE");
}
if (!t_relay()) {
sl_reply_error();
}
exit;
}
# Caller NAT detection route
route[NATDETECT] {
#!ifdef WITH_NAT
force_rport();
if (nat_uac_test("19")) {
if (is_method("REGISTER")) {
xlog("fix_nated_register");
fix_nated_register();
} else {
xlog("fix_nated_contact");
fix_nated_contact();
}
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;
rtpproxy_manage("", "195.235.93.8");
if (is_request()) {
if (!has_totag()) {
add_rr_param(";nat=yes");
}
}
if (is_reply()) {
if(isbflagset(FLB_NATB)) {
fix_nated_contact();
}
}
#!endif
return;
}
# Routing to foreign domains
route[SIPOUT] {
if (!uri==myself)
{
append_hf("P-hint: outbound\r\n");
route(RELAY);
}
}
# manage outgoing branches
branch_route[MANAGE_BRANCH] {
xdbg("new branch [$T_branch_idx] to $ru\n");
route(NATMANAGE);
}
# manage incoming replies
onreply_route[MANAGE_REPLY] {
xdbg("incoming reply\n");
#ggb: TCP connection reuse
add_contact_alias();
if(status=~"[12][0-9][0-9]")
route(NATMANAGE);
}
onreply_route[CHANGE_SDP] {
xlog("CHANGE_SDP");
if(t_check_status("(200)|(183)"))
{
if(has_body("application/sdp"))
{
if(search("IN IP4 10.95.94.142"))
{
xlog("search IN IP4 .142");
fix_nated_sdp("2", "195.235.93.8");
}
}
}
}
# manage failure routing cases
failure_route[MANAGE_FAILURE] {
route(NATMANAGE);
if (t_is_canceled()) {
exit;
}
#!ifdef WITH_BLOCK3XX
# block call redirect based on 3xx replies.
if (t_check_status("3[0-9][0-9]")) {
t_reply("404","Not found");
exit;
}
#!endif
}
route [MCU]{
if (uri=~"^sip:[7,8][0-9]+@"){
xlog("Forward to MCU");
rewritehost("10.95.94.142");
rewriteport("5070");
rtpproxy_manage();
t_relay();
t_on_reply("CHANGE_SDP");
xlog("after forward to MCU");
exit;
}
}
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 00:18
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>, Vicente
Hernando <vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
you should not set the second parameter of rtpproxy_manage(...), let it be the one
returned by rtpproxy.
And yes, all the occurrences of IP addresses in c= lines will be replaced by the rtpproxy
ip, but providing different ports for each media stream.
Practically the rtp streams are going from end device to rtpproxy and then based on port
will be delivered to different IPs of the MCU. Also, the MCU will send from different IPs
to RTPProxy on different ports and from there to the end device.
Cheers,
Daniel
On 10/8/12 6:05 PM, MARINA SERRANO MONTES wrote:
Hi Daniel,
I have tested using "rtpproxy_manage("", public IP), but in this case, it
replaces all the c= lines with this public IP, included c=lines in media descriptions and
then, the rtp traffic is not routing to the right IP in MCU.
Have I to set up any value/param….to route rtp traffic through rtpproxy in sip server and
then it will dispatch RTP packets to MCU?
Thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: lunes 8 de octubre de 2012 16:04
To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>
Cc: Vicente Hernando
<vhernando@systemonenoc.com<mailto:vhernando@systemonenoc.com>>, Marina
Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
I understood that Marina is looking for the option of being able to use different IP
addresses for updating various c= lines in SDP.
fix_nated_sdp(...) can work only with one IP address given as second parameter (or taken
for source address of the packet).
Perhaps fix_nated_sdp(...) can be easily extended to support a list of ip addresses in the
second parameter. For now the solution is to use rtpproxy to rewrite all the IP addresses
in c= lines with the IP address of the rtpproxy. RTPProxy will then dispatch RTP to the
right IP address assigned for each media stream.
Regarding the patch sent by Vicente, I just replied on sr-dev mailing list.
Cheers,
Daniel
On 10/8/12 3:25 PM, Vicente Hernando wrote:
Hello Marina,
there is a bug in sdp parser about c IPs which are not correctly reset for non existent c
values in streams.
I have still not uploaded it to master branch, sorry.
May be it is related to your issue, in this link you have the attached patch.
http://lists.sip-router.org/pipermail/sr-dev/2012-September/016440.html
Kind regards,
Vicente.
On 10/08/2012 01:18 PM, MARINA SERRANO MONTES wrote:
Hi,
I have a doubt about how to use "fix_nated_sdp("2")" function when we
have an scenario with multiple media types (audio and video) and the param "c"
in sdp for each media type has a different IP.
We are using a SCOPIA 400 MCU to multi-party in a call, and it will set up different IP to
send RTP depend on media type.
I have tested this function, but it rewrites always all the "c" parameter with
the same value.
Is there any option to use the function or to rewrite "c" value for each media
type independently?
Many thanks.
Br,
Marina
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
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@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla -
http://www.asipto.comhttp://twitter.com/#!/miconda<http://twitter.com/#%…
- http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
3:30 p.m.
Hello,
the signaling shows traffic going from public IP (caller) to private IP
(kamailio) then back to public IP (callee). So it is a bit of complex
routing if you keep it like this. The best is to get it done working
with kamailio, rtpproxy and mcu on their public ip, because they have
such already. Then you can think of moving to use some private networks.
Your fourth bullet below is not clear for me: the clients should have
visibility to sip server in order to register and call, but you say not,
maybe just a typo.
Also, I would recommend to start with latest kamailio 3.3.1 version,
3.2.0 is very old, if you really want that release series, the use
latest 3.2.x, not 3.2.0.
Cheers,
Daniel
On 10/9/12 1:36 PM, MARINA SERRANO MONTES wrote:
Hi Daniel:
The network is:
* MCU is running in a private network with IP's (10.95.94.142 and
10.95.94.143) and public IP's 195.235.93.166 and 195.235.93.161.
* SIP server and rtpproxy are running in another network:
10.95.94.92, with public IP: 195.235.93.8.
* SIP server, rtpproxy and MCU has visibility between them.
* Clients have not visibility with sip server and MCU, and they try
register, invite,….using the public IP: 195.235.93.8 (public IP of
rtpproxy)
* When I have not use MCU, only 2 participants, the video and audio
is routing OK.
* I can verify using web browser conference in MCU that it is
sending RTP traffic (out traffic).
Thank you very much.
Br,
Marina
I attach the sip messages of a call with/without MCU:
...
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
10 Oct
10 Oct
9:33 a.m.
New subject: how to use fix_nated_sdp("2") with multiple media types
Hi Daniel,
I have tested using "rtpproxy_manage()" before rewritehost(ip public-MCU) and
then, in the 200 OK response, using rtpproxy _manage(public ip rtpproxy) and it works.
Endpoint sends ftp traffic to MCU through rtpproxy and MCU sends ftp traffic to endpoint
through rtpproxy.
I am going to update kamailio version too.
Many thanks.
Br,
Marina
From: Daniel-Constantin Mierla <miconda@gmail.com<mailto:miconda@gmail.com>>
Reply-To: "miconda@gmail.com<mailto:miconda@gmail.com>"
<miconda@gmail.com<mailto:miconda@gmail.com>>
Date: martes 9 de octubre de 2012 14:30
To: Marina Serrano Montes <marinas@tid.es<mailto:marinas@tid.es>>
Cc: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - Users Mailing
List"
<sr-users@lists.sip-router.org<mailto:sr-users@lists.sip-router.org>>
Subject: Re: [SR-Users] how to use fix_nated_sdp("2") with multiple media types
Hello,
the signaling shows traffic going from public IP (caller) to private IP (kamailio) then
back to public IP (callee). So it is a bit of complex routing if you keep it like this.
The best is to get it done working with kamailio, rtpproxy and mcu on their public ip,
because they have such already. Then you can think of moving to use some private
networks.
Your fourth bullet below is not clear for me: the clients should have visibility to sip
server in order to register and call, but you say not, maybe just a typo.
Also, I would recommend to start with latest kamailio 3.3.1 version, 3.2.0 is very old, if
you really want that release series, the use latest 3.2.x, not 3.2.0.
Cheers,
Daniel
On 10/9/12 1:36 PM, MARINA SERRANO MONTES wrote:
Hi Daniel:
The network is:
* MCU is running in a private network with IP's (10.95.94.142 and 10.95.94.143)
and public IP's 195.235.93.166 and 195.235.93.161.
* SIP server and rtpproxy are running in another network: 10.95.94.92, with public IP:
195.235.93.8.
* SIP server, rtpproxy and MCU has visibility between them.
* Clients have not visibility with sip server and MCU, and they try register,
invite,….using the public IP: 195.235.93.8 (public IP of rtpproxy)
* When I have not use MCU, only 2 participants, the video and audio is routing OK.
* I can verify using web browser conference in MCU that it is sending RTP traffic (out
traffic).
Thank you very much.
Br,
Marina
I attach the sip messages of a call with/without MCU:
...
--
Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda -
http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Nov 5-8, 2012 - http://asipto.com/u/kat
Kamailio Advanced Training, Miami, USA, Nov 12-14, 2012 - http://asipto.com/u/katu
________________________________
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política
de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on
the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
4430
days inactive
4432
days old
11 comments
3 participants
participants (3)
-
Daniel-Constantin Mierla -
MARINA SERRANO MONTES -
Vicente Hernando