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>

        Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes>

        Max-Forwards: 16

        From: 00Bnumber <sip:00Bnumber@ServerIP:ServerPort>;tag=eihmt4yopie2j4fq.i

        To: <sip:XliteAnumber@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@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>

        Route: <sip:ServerIP:ServerPort;transport=tcp;r2=on;lr=on;nat=yes>

        Max-Forwards: 16

        From: <sip:00Bnumber@ServerIP:ServerPort>;tag=2yapycnnrb7yjgwj.i

        To: <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>

        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