[SR-Users] Server silently droping Bye message.

Daniel-Constantin Mierla miconda at gmail.com
Thu Aug 29 14:43:48 CEST 2013


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 at publicXliteIP:55838;transport=tcp SIP/2.0
>
>         Method: BYE
>
>         Request-URI: sip:XliteAnumber at 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>
>
>         Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes>
>
>         Max-Forwards: 16
>
>         From: 00Bnumber 
> <sip:00Bnumber at ServerIP:ServerPort>;tag=eihmt4yopie2j4fq.i
>
>         To: <sip:XliteAnumber at ServerIP:ServerPort>;tag=2b8f312e
>
>         Call-ID: NGZlMDU3OWE2YjM1ZGQ1OTEyM2NiNmI0YjM1MjA0YTg
>
>         CSeq: 515 BYE
>
>             Sequence Number: 515
>
>             Method: BYE
>
>         Contact: Anonymous <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 at PrivateAndroidIP:35986;transport=tcp SIP/2.0
>
>         Method: BYE
>
>         Request-URI: 
> sip:AndroidAnumber at 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>
>
>         Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes>
>
>         Max-Forwards: 16
>
>         From: <sip:00Bnumber at ServerIP:ServerPort>;tag=2yapycnnrb7yjgwj.i
>
>         To: <sip:AndroidAnumber at ServerIP:ServerPort>;tag=652340227
>
> Call-ID: fa8e5892-e88f-fd9b-8f99-0545ac8e9e8e
>
> CSeq: 438 BYE
>
>             Sequence Number: 438
>
>             Method: BYE
>
>         Contact: Anonymous <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 at 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 -

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130829/f7cb0e84/attachment-0001.html>


More information about the sr-users mailing list