Sorry I thought I attached the complete trace, I captured it with wireshark on the server machine so I hope it is enough since you can see both sides. Yes I realized the alias is added on the invite from the Kamailio to the PSTN GW: Contact: <sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp>;alias=PublicAndroi dIP~35986~2 but it is not present on the BYE the PSTNGW send back to kamailio. But kamailio has the information on the database, so I though it may be able to send the message anyway. Thanks Helena From: sr-users-bounces(a)lists.sip-router.org [mailto:sr-users-bounces@lists.sip-router.org] On Behalf Of Daniel-Constantin Mierla Sent: jueves, 29 de agosto de 2013 14:44 To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Server silently droping Bye message. Hello, the BYE does not have information about the public ip of the nat router behind which is located the android device. With the default config of kamailio, that should be stored as alias parameter in the contact header. You should send the full signaling from first invite to the bye for the case that does not work, in order to see if something goes wrong there and what party is responsible for that. You should use ngrep to take the trace on kamailio server, because it easy to read and captures the both sides. A sample command would be: ngrep -d any -qt -W byline port 5060 Of course you can replace IP addresses with suggestive tokens. Cheers, Daniel On 8/29/13 2:00 PM, Helena Garcia-Nieto wrote: Hello, Thanks in advanced for the help. I am absolutely new with kamailio and still struggling through silly problems so please forgive me if the solutions is so obvious. I have a network like Devices --à Kamailio --à pstn GW The PSTN GW is more or less out of my reach for changing the behaivour. As devices I have xlite, 3cx and an android app Kamailio is on version 4.0.2 I have problems with the calls to PSTN, When A is the Android app the server is not able to relay the Bye coming from the pstngw so the android app does not disconnect the call. This do not happened when A are xlite or 3cx. Bye is correctly sent to the PSTNGW if it comes from the android app. For calls inside the kamailio server there is no problem with the devices and all the byes are sent ok. When I call from the android app I have to drop some of the parameters on the Contact header because the pstngw do not like them and drop the call otherwise (responding with a 500 IRP error) I droped the parameters using: subst('/^Contact: (.*)>.*$/Contact: \1>/i'); #delete the parameter that is anoying pstnGW on contact header I also change request uri deleting the 00, but I do this modification on all the calls. I have tried without this ruri modification and the resoult is the same xlite ok android ko so I do not think that is affecting. subst_uri('/^sip:00(.*)/sip:\1/i'); # delete the 00 Searching on the kamailio log I found that in the android call: DEBUG: tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=113 , global msg id=112 , T on entrance=0xffffffffffffffff DEBUG: tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start searching: hash=30121, isACK=0 DEBUG: tm [t_lookup.c:492]: matching_3261(): DEBUG: RFC3261 transaction matching failed DEBUG: tm [t_lookup.c:716]: t_lookup_request(): DEBUG: t_lookup_request: no transaction found DEBUG: tm [t_hooks.c:374]: run_reqin_callbacks_internal(): DBG: trans=0x7f60cadc8d10, callback type 1, id 0 entered While on the xlite call I can see tm [t_lookup.c:1395]: t_newtran(): DEBUG: t_newtran: msg id=116 , global msg id=115 , T on entrance=(nil) tm [t_lookup.c:534]: t_lookup_request(): t_lookup_request: start searching: hash=64449, isACK=0 tm [t_lookup.c:477]: matching_3261(): DEBUG: RFC3261 transaction matched, tid=1cbf.617b985b6620c855b501dfbfced5f7a4.0 tm [t_lookup.c:733]: t_lookup_request(): DEBUG: t_lookup_request: transaction found (T=0x7f60cadb2510) When processing the BYE. So I’m thinking that the problem is that Kamailio do not know where to send it. I’m not sure that is the problem. I’ve checked and tags and session information seem ok to me, so I do not understand what is wrong with the Bye so the server cannot find where it should be sent to. I attached a trace with both calls first xlite and then android This is the Bye on the XLite call Frame 59: 788 bytes on wire (6304 bits), 788 bytes captured (6304 bits) Ethernet II, Src: Cisco_67:50:00 (macAdd), Dst: FujitsuT_80:7d:d8 (macAdd) Internet Protocol Version 4, Src: PSTNGWIP (PSTNGWIP), Dst: ServerIP (ServerIP) User Datagram Protocol, Src Port: sip (5060), Dst Port: ServerPort (ServerPort) Session Initiation Protocol (BYE) Request-Line: BYE sip:XliteAnumber@publicXliteIP:55838;transport=tcp SIP/2.0 Method: BYE Request-URI: sip:XliteAnumber@publicXliteIP:55838;transport=tcp [Resent Packet: False] Message Header Via: SIP/2.0/UDP PSTNGWIP;branch=z9hG4bK5d4.f93633a612aca237ad1f5c341c1b2986.0 Via: SIP/2.0/UDP PSTNGWIP:5061;branch=z9hG4bK-fat3ctwlimdw3lkb;rport=5061 Route: <sip:ServerIP:ServerPort;r2=on;lr=on;nat=yes> <sip:ServerIP:ServerPort;r2=on;lr=on;nat=yes> Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes> <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes> Max-Forwards: 16 From: 00Bnumber <sip:00Bnumber@ServerIP:ServerPort> <sip:00Bnumber@ServerIP:ServerPort>;tag=eihmt4yopie2j4fq.i To: <sip:XliteAnumber@ServerIP:ServerPort> <sip:XliteAnumber@ServerIP:ServerPort>;tag=2b8f312e Call-ID: NGZlMDU3OWE2YjM1ZGQ1OTEyM2NiNmI0YjM1MjA0YTg CSeq: 515 BYE Sequence Number: 515 Method: BYE Contact: Anonymous <sip:PSTNGWIP:5061> <sip:PSTNGWIP:5061> User-Agent: Sippy cisco-GUID: 521708479-278139363-3214082078-3387785402 h323-conf-id: 521708479-278139363-3214082078-3387785402 and that one is the one on the Android one: Frame 115: 766 bytes on wire (6128 bits), 766 bytes captured (6128 bits) Ethernet II, Src: Cisco_67:50:00 (macAdd), Dst: FujitsuT_80:7d:d8 (macAdd) Internet Protocol Version 4, Src: PSTNGWIP (PSTNGWIP), Dst: ServerIP (ServerIP) User Datagram Protocol, Src Port: sip (5060), Dst Port: ServerPort (ServerPort) Session Initiation Protocol (BYE) Request-Line: BYE sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp SIP/2.0 Method: BYE Request-URI: sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp [Resent Packet: False] Message Header Via: SIP/2.0/UDP PSTNGWIP;branch=z9hG4bKf0a2.679a023eeebfc2b9acae8c683386146f.0 Via: SIP/2.0/UDP PSTNGWIP:5061;branch=z9hG4bK-ge57vxpelnqy57yg;rport=5061 Route: <sip:ServerIP:ServerPort;r2=on;lr=on;nat=yes> <sip:ServerIP:ServerPort;r2=on;lr=on;nat=yes> Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes> <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes> Max-Forwards: 16 From: <sip:00Bnumber@ServerIP:ServerPort> <sip:00Bnumber@ServerIP:ServerPort>;tag=2yapycnnrb7yjgwj.i To: <sip:AndroidAnumber@ServerIP:ServerPort> <sip:AndroidAnumber@ServerIP:ServerPort>;tag=652340227 Call-ID: fa8e5892-e88f-fd9b-8f99-0545ac8e9e8e CSeq: 438 BYE Sequence Number: 438 Method: BYE Contact: Anonymous <sip:PSTNGWIP:5061> <sip:PSTNGWIP:5061> User-Agent: Sippy cisco-GUID: 521708482-278139363-3214082078-3387785402 h323-conf-id: 521708482-278139363-3214082078-3387785402 Both Devices are behind NAT. I hope I explained my problem correctly but do not hesitate to ask any other thing. Thanks in advanced Helena _______________________________________________ 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 -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com -

Thanks! Thank you very very much for your help. I'll add the ngrep next time! I'm absolutely new at kamailio and I'm doing the Subs on the main config file (/usr/local/etc/kamailio/kamailio.cfg) on the PSTN call detection route[PSTN] {: if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } if (strempty($sel(cfg_get.pstn.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port); } # modifications to acces env5 subst_uri('/^sip:00(.*)/sip:\1/i'); #append delete the 00 subst('/^Contact: (.*)>.*$/Contact: \1>/i');#delete the parameter that is anoying env5 on contact header And I cannot find the msg_apply_changes(); part on that file, can you tell me where I can better do the subs, in which file? I'm not actually moving the > just droping everything after it. I'm sure there is a better option to change the contact header, would you have any suggestion? Thanks in advanced Helena From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: jueves, 29 de agosto de 2013 15:49 To: Helena Garcia-Nieto; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Server silently droping Bye message. ngrep output is preferred, because expanded wireshark has to much garbage around actuall sip message content. If you have the wireshark capture, then you can export pcap file and then use 'ngrep -qt -W byline -I file.pcap' to get pure text format for sip messages (then replace your ip addresses as needed). Anyhow, for this case the problem resides in the contact header you send out. The alias parameter has to be before the '>' but your subst() moves the '>' after the initial contact uri, leaving the new parameter alias out of URI itself, resulting in being a header parameter. One solution is to do subst() before record_route() in the config and after it execute: msg_apply_changes(); Cheers, Daniel On 8/29/13 3:31 PM, Helena Garcia-Nieto wrote: Sorry I thought I attached the complete trace, I captured it with wireshark on the server machine so I hope it is enough since you can see both sides. Yes I realized the alias is added on the invite from the Kamailio to the PSTN GW: Contact: <sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp> <sip:AndroidAnumber@PrivateAndroidIP:35986;transport=tcp>;alias=PublicAndroi dIP~35986~2 but it is not present on the BYE the PSTNGW send back to kamailio. But kamailio has the information on the database, so I though it may be able to send the message anyway. Thanks Helena -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com -

Thanks again Daniel I've been reading deeply the module info and learning a lot. Your easy solution worked thou, using the subst_hf function instead of the normal subst the alias is added correctly and then the following bye is also correctly handled. The final line I use is: subst_hf("Contact", "/>.*$/>/", "a"); Thanks again for this great user mailing list! And for the kamailio itself BR, Helena From: Daniel-Constantin Mierla [mailto:miconda@gmail.com] Sent: viernes, 30 de agosto de 2013 9:48 To: Helena Garcia-Nieto; 'Kamailio (SER) - Users Mailing List' Subject: Re: [SR-Users] Server silently droping Bye message. Hello, On 8/29/13 5:24 PM, Helena Garcia-Nieto wrote: Thanks! Thank you very very much for your help. I'll add the ngrep next time! I'm absolutely new at kamailio and I'm doing the Subs on the main config file (/usr/local/etc/kamailio/kamailio.cfg) on the PSTN call detection route[PSTN] {: if(!($rU=~"^(\+|00)[1-9][0-9]{3,20}$")) return; # only local users allowed to call if(from_uri!=myself) { sl_send_reply("403", "Not Allowed"); exit; } if (strempty($sel(cfg_get.pstn.gw_port))) { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip); } else { $ru = "sip:" + $rU + "@" + $sel(cfg_get.pstn.gw_ip) + ":" + $sel(cfg_get.pstn.gw_port); } # modifications to acces env5 subst_uri('/^sip:00(.*)/sip:\1/i'); #append delete the 00 subst('/^Contact: (.*)>.*$/Contact: \1>/i');#delete the parameter that is anoying env5 on contact header And I cannot find the msg_apply_changes(); part on that file, can you tell me where I can better do the subs, in which file? msg_apply_changes() is not used in default config file, you have to add it yourself -- it is part of textopsx module which is loaded in default config file -- see its readme for more details. I'm not actually moving the > just droping everything after it. Better said, you remove the contact header and then add only the part up to might expect, by using data lumps (if you search in mailing list archive you can find more details). I'm sure there is a better option to change the contact header, would you have any suggestion? You can give a try with: subst_hf("Contact", ">.*$", ">"); but might result in same troubles, because alias parameter is added after this operation. So you have to use msg_apply_changes(). But don't forget to move the record_route() after msg_apply_changes(). Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Trainings - Berlin, Oct 21-24; Miami, Nov 11-13, 2013 - more details about Kamailio trainings at http://www.asipto.com -