Problem changing the SDP origin after a failure route

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Problem changing the SDP origin after a failure route

Pascal Poudrier

Hi, first of all, here's the architecture of what I'm trying to do :

Public client --> Kamailio and there is a private freeswitch behind  kamailio. I use rtpproxy to connect the client and the freeswitch that is used at media server.

If a call is not answered from userA to userB and userB doesn't have a voicemail configured, I route the Invite to FreeSwitch and I change the destination user to 666666 that take care of playing a nice message that the user doesn't have a voicemail.

My problem is that the SDP Connection doesn't get updated to the right IP. It get changed to the external IP instead of the internal.

Here's the original INVITE Packet :

13:21:22.824290 IP 8.8.8.16.30893 > 8.8.8.18.5060: SIP: INVITE sip:[hidden email] SIP/2.0
Eh....@.?...........x......mINVITE sip:[hidden email] SIP/2.0
Via: SIP/2.0/UDP 192.168.0.236:5060;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: 3ae5b914-591b8732@192.168.0.236
CSeq: 101 INVITE
Max-Forwards: 70
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 263
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 192.168.0.236
s=-
c=IN IP4 192.168.0.236
t=0 0
m=audio 16396 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Note that 192.168.0.x in the internal network of the clients and 8.8.8.16 is the public IP of the client and 8.8.8.18 is the kamailio ip.

Here's the INVITE packet sent from kamailio to Freeswitch

13:21:32.947196 IP 172.16.0.18.5060 > 172.16.0.19.5080: SIP: INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
E... ...@.      ...e...e.......P1INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
Record-Route: <sip:8.8.8.18;lr=on;ftag=cacbdfac40ddd17ao0;did=f3f.205>
Test-Pascal: SDP avec freeswitch
Via: SIP/2.0/UDP 172.16.0.18;branch=z9hG4bK31ea.e52b370f8248032680211fc7c253902a.1
Via: SIP/2.0/UDP 192.168.0.236:5060;rport=30893;received=8.8.8.16;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: 3ae5b914-591b8732@192.168.0.236
CSeq: 101 INVITE
Max-Forwards: 69
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 279
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 8.8.8.18
s=-
c=IN IP4 8.8.8.18
t=0 0
m=audio 46134 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=nortpproxy:yes

Note that 172.16.0.18 is the internal IP of kamailio and 172.16.0.19 is the internal IP of FreeSwitch

Here's the revealing par of kamailio configuration that us use when falling back to freeswitch :

failure_route[TOVOICEMAIL] {

$ru = "sip:666666666666666@" + $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
$du = "sip:666666666666666@"+ $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
force_send_socket(udp:172.16.0.18:5060);

if (is_request()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Request");
       if(has_totag()) {
           if(check_route_param("nat=yes")) {
               setbflag(FLT_NATS);
           }
       }
   }

       if(nat_uac_test("8")) {
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","SDP Body avant : $fu --> $du | $ru");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : NAT SDP");
           rtpproxy_manage("1cowei",'192.168.101.18');
           insert_hf("Test-Pascal: SDP avec freeswitch\r\n");
           xlog("L_INFO","---------------------------------------------------");
       }    
       else {
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : PAS DE NAT SDP");
           rtpproxy_manage("cowrei");
       }    
   if (is_reply()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Reply");
       if(isbflagset(FLT_NATS)) {
           if(is_first_hop())
               set_contact_alias();

       }
       if ( $si == $sel(cfg_get.freeswitch.bindip) && is_method("SUBSCRIBE") ) {
           remove_hf("Contact");
           insert_hf("Contact: \[hidden email]\r\n","Expires");

       }
       else {
           fix_nated_contact();
       }

   }

if ( is_method("INVITE") )
       setflag(FLT_DIALOG);

if (!t_relay()) {
       xlog("L_INFO","$ft -- ERROR Relay : $rc");
       sl_reply_error();
   }

------------------------------------------------

This configuration is working if the call is not going through failure_route

I use Kamailio version 5.0.1 on Debian.

Thank you


Pascal


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem changing the SDP origin after a failure route

John Petrini
You might try using the fix_nated_sdp function from the nathelper module to rewrite the c line in the SDP body.

___

John Petrini

NOC Systems Administrator   //   CoreDial, LLC   //   coredial.com   //   Twitter   LinkedIn   Google Plus   Blog 
Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422 
P: 215.297.4400 x232   //   F: 215.297.4401   //   E: [hidden email]


Interested in sponsoring PartnerConnex 2017? Learn more.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission,  dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.


On Wed, Jun 14, 2017 at 5:00 PM, Pascal Poudrier <[hidden email]> wrote:

Hi, first of all, here's the architecture of what I'm trying to do :

Public client --> Kamailio and there is a private freeswitch behind  kamailio. I use rtpproxy to connect the client and the freeswitch that is used at media server.

If a call is not answered from userA to userB and userB doesn't have a voicemail configured, I route the Invite to FreeSwitch and I change the destination user to 666666 that take care of playing a nice message that the user doesn't have a voicemail.

My problem is that the SDP Connection doesn't get updated to the right IP. It get changed to the external IP instead of the internal.

Here's the original INVITE Packet :

13:21:22.824290 IP 8.8.8.16.30893 > 8.8.8.18.5060: SIP: INVITE sip:[hidden email] SIP/2.0
Eh....@.?...........x......mINVITE sip:[hidden email] SIP/2.0
Via: SIP/2.0/UDP 192.168.0.236:5060;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: [hidden email]
CSeq: 101 INVITE
Max-Forwards: 70
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 263
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 192.168.0.236
s=-
c=IN IP4 192.168.0.236
t=0 0
m=audio 16396 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Note that 192.168.0.x in the internal network of the clients and 8.8.8.16 is the public IP of the client and 8.8.8.18 is the kamailio ip.

Here's the INVITE packet sent from kamailio to Freeswitch

13:21:32.947196 IP 172.16.0.18.5060 > 172.16.0.19.5080: SIP: INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
E... ...@.      ...e...e.......P1INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
Record-Route: <sip:8.8.8.18;lr=on;ftag=cacbdfac40ddd17ao0;did=f3f.205>
Test-Pascal: SDP avec freeswitch
Via: SIP/2.0/UDP 172.16.0.18;branch=z9hG4bK31ea.e52b370f8248032680211fc7c253902a.1
Via: SIP/2.0/UDP 192.168.0.236:5060;rport=30893;received=8.8.8.16;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: [hidden email]
CSeq: 101 INVITE
Max-Forwards: 69
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 279
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 8.8.8.18
s=-
c=IN IP4 8.8.8.18
t=0 0
m=audio 46134 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=nortpproxy:yes

Note that 172.16.0.18 is the internal IP of kamailio and 172.16.0.19 is the internal IP of FreeSwitch

Here's the revealing par of kamailio configuration that us use when falling back to freeswitch :

failure_route[TOVOICEMAIL] {

$ru = "sip:666666666666666@" + $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
$du = "sip:666666666666666@"+ $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
force_send_socket(udp:172.16.0.18:5060);

if (is_request()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Request");
       if(has_totag()) {
           if(check_route_param("nat=yes")) {
               setbflag(FLT_NATS);
           }
       }
   }

       if(nat_uac_test("8")) {
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","SDP Body avant : $fu --> $du | $ru");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : NAT SDP");
           rtpproxy_manage("1cowei",'192.168.101.18');
           insert_hf("Test-Pascal: SDP avec freeswitch\r\n");
           xlog("L_INFO","---------------------------------------------------");
       }    
       else {
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : PAS DE NAT SDP");
           rtpproxy_manage("cowrei");
       }    
   if (is_reply()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Reply");
       if(isbflagset(FLT_NATS)) {
           if(is_first_hop())
               set_contact_alias();

       }
       if ( $si == $sel(cfg_get.freeswitch.bindip) && is_method("SUBSCRIBE") ) {
           remove_hf("Contact");
           insert_hf("Contact: \[hidden email]\r\n","Expires");

       }
       else {
           fix_nated_contact();
       }

   }

if ( is_method("INVITE") )
       setflag(FLT_DIALOG);

if (!t_relay()) {
       xlog("L_INFO","$ft -- ERROR Relay : $rc");
       sl_reply_error();
   }

------------------------------------------------

This configuration is working if the call is not going through failure_route

I use Kamailio version 5.0.1 on Debian.

Thank you


Pascal


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Reply | Threaded
Open this post in threaded view
|

Re: Problem changing the SDP origin after a failure route

Pascal Poudrier

Thank you John for your idea but it seem that when rtpproxy_manage change the SDP, it also change the RTP port that fit the rtpproxy session.

So basically, I need to call rtpproxy_manage with the invite to change the SDP attribute but when falling back to the failure_route, I need to destroy the current rtpproxy session and create a new one base on the new parameters of the session (the changed user and destination ip) for the RTP stream.

So to manage this correctly, I may need to destroy the first created rtpproxy session and create a new one with the new invite parameters.

I will try to work on this.

On June 14, 2017 at 5:19 PM John Petrini <[hidden email]> wrote:

You might try using the fix_nated_sdp function from the nathelper module to rewrite the c line in the SDP body.

___

John Petrini

NOC Systems Administrator   //   CoreDial, LLC   //   coredial.com   //   Twitter   LinkedIn   Google Plus   Blog 
Hillcrest I, 751 Arbor Way, Suite 150, Blue Bell PA, 19422 
P: 215.297.4400 x232   //   F: 215.297.4401   //   E: [hidden email]


Interested in sponsoring PartnerConnex 2017? Learn more.

The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission,  dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.


On Wed, Jun 14, 2017 at 5:00 PM, Pascal Poudrier <[hidden email]> wrote:

Hi, first of all, here's the architecture of what I'm trying to do :

Public client --> Kamailio and there is a private freeswitch behind  kamailio. I use rtpproxy to connect the client and the freeswitch that is used at media server.

If a call is not answered from userA to userB and userB doesn't have a voicemail configured, I route the Invite to FreeSwitch and I change the destination user to 666666 that take care of playing a nice message that the user doesn't have a voicemail.

My problem is that the SDP Connection doesn't get updated to the right IP. It get changed to the external IP instead of the internal.

Here's the original INVITE Packet :

13:21:22.824290 IP 8.8.8.16.30893 > 8.8.8.18.5060: SIP: INVITE sip:[hidden email] SIP/2.0
Eh....@.?...........x......mINVITE sip:[hidden email] SIP/2.0
Via: SIP/2.0/UDP 192.168.0.236:5060;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: [hidden email]
CSeq: 101 INVITE
Max-Forwards: 70
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 263
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 192.168.0.236
s=-
c=IN IP4 192.168.0.236
t=0 0
m=audio 16396 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Note that 192.168.0.x in the internal network of the clients and 8.8.8.16 is the public IP of the client and 8.8.8.18 is the kamailio ip.

Here's the INVITE packet sent from kamailio to Freeswitch

13:21:32.947196 IP 172.16.0.18.5060 > 172.16.0.19.5080: SIP: INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
E... ...@.      ...e...e.......P1INVITE sip:666666666666666@172.16.0.19:5080 SIP/2.0
Record-Route: <sip:8.8.8.18;lr=on;ftag=cacbdfac40ddd17ao0;did=f3f.205>
Test-Pascal: SDP avec freeswitch
Via: SIP/2.0/UDP 172.16.0.18;branch=z9hG4bK31ea.e52b370f8248032680211fc7c253902a.1
Via: SIP/2.0/UDP 192.168.0.236:5060;rport=30893;received=8.8.8.16;branch=z9hG4bK-3e3b9e22
From: [hidden email];tag=cacbdfac40ddd17ao0
To: <sip:[hidden email]>
Remote-Party-ID: [hidden email];screen=yes;party=calling
Call-ID: [hidden email]
CSeq: 101 INVITE
Max-Forwards: 69
Contact: [hidden email]
Expires: 240
User-Agent: Cisco/SPA122-1.3.5r(003)
Content-Length: 279
Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER
Supported: replaces
Content-Type: application/sdp

v=0
o=- 16833207 16833207 IN IP4 8.8.8.18
s=-
c=IN IP4 8.8.8.18
t=0 0
m=audio 46134 RTP/AVP 0 100 101
a=rtpmap:0 PCMU/8000
a=rtpmap:100 NSE/8000
a=fmtp:100 192-193
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
a=nortpproxy:yes

Note that 172.16.0.18 is the internal IP of kamailio and 172.16.0.19 is the internal IP of FreeSwitch

Here's the revealing par of kamailio configuration that us use when falling back to freeswitch :

failure_route[TOVOICEMAIL] {

$ru = "sip:666666666666666@" + $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
$du = "sip:666666666666666@"+ $sel(cfg_get.freeswitch.bindip)
+ ":" + $sel(cfg_get.freeswitch.bindport);
force_send_socket(udp:172.16.0.18:5060);

if (is_request()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Request");
       if(has_totag()) {
           if(check_route_param("nat=yes")) {
               setbflag(FLT_NATS);
           }
       }
   }

       if(nat_uac_test("8")) {
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","SDP Body avant : $fu --> $du | $ru");
           xlog("L_INFO","---------------------------------------------------");
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : NAT SDP");
           rtpproxy_manage("1cowei",'192.168.101.18');
           insert_hf("Test-Pascal: SDP avec freeswitch\r\n");
           xlog("L_INFO","---------------------------------------------------");
       }    
       else {
           xlog("L_INFO","$ft -- RTPMANAGE(FreeSwitch) : PAS DE NAT SDP");
           rtpproxy_manage("cowrei");
       }    
   if (is_reply()) {
       xlog("L_INFO","$ft -- NATMANAGE -- Reply");
       if(isbflagset(FLT_NATS)) {
           if(is_first_hop())
               set_contact_alias();

       }
       if ( $si == $sel(cfg_get.freeswitch.bindip) && is_method("SUBSCRIBE") ) {
           remove_hf("Contact");
           insert_hf("Contact: \[hidden email]\r\n","Expires");

       }
       else {
           fix_nated_contact();
       }

   }

if ( is_method("INVITE") )
       setflag(FLT_DIALOG);

if (!t_relay()) {
       xlog("L_INFO","$ft -- ERROR Relay : $rc");
       sl_reply_error();
   }

------------------------------------------------

This configuration is working if the call is not going through failure_route

I use Kamailio version 5.0.1 on Debian.

Thank you


Pascal


_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



_______________________________________________
Kamailio (SER) - Users Mailing List
[hidden email]
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users