Hello Bogdan, The confusion was we received request timeout in two cases .. 1- Gateway did not respond at all not even a trying. (We may take action to disable gateway if too many of such cases) 2- Gateway sent trying and ringing but B party did not answer the call and it timed out. (This is no fault of gateway)
This was solved for me by checking which timer expired (fr_timer or fr_inv_timer) I was able to solve it by using your old post. Regards John On Sat, Apr 23, 2016 at 1:52 PM, Bogdan-Andrei Iancu <bog...@opensips.org> wrote: > Hi John, > > A Request Terminated is generated in response of a received CANCEL > request. In the scenario of a local timeout, there is not received cancel - > it is a timeout event. I do not see any confusion in the reason string in > CDR. > > Regards, > > Bogdan-Andrei Iancu > OpenSIPS Founder and Developerhttp://www.opensips-solutions.com > > On 19.04.2016 17:49, John Nash wrote: > > Ok got it thanks. I also noticed that transactions cancelled because of > fr_inv_timeout , CDR records as "Request timeout". It is quite confusion, > shouldnt it be "Request Terminated"? or I am doing something wrong > > On Tue, Apr 19, 2016 at 6:46 PM, Julian Santer <julian.san...@rolmail.net> > wrote: > >> Hi John, >> >> the commit was: >> >> commit 8133656de9503a122a72c0f80d11eff975bc43f1 >> Author: Bogdan-Andrei Iancu <bog...@opensips.org> >> Date: Thu Feb 11 14:58:41 2016 +0200 >> >> Fix proper callig in local cancels with TH. >> >> Extend the coverage of the preocessing context and TM context over >> the cancel_branch() function (in the timeout handler) so the TH callbacks >> can reach back the dialog and do the TH related changes. >> Reported by Julian Santer on mailing list. >> >> Kind regards, >> Julian Santer >> Raiffeisen OnLine >> >> Am 18.04.2016 um 22:35 schrieb John Nash: >> >>> which revision this was fixed?...I am also using OpenSips 2.1.2 and want >>> to update only this change for the time being (2.2 has many changes) >>> >>> On Thu, Feb 11, 2016 at 7:19 PM, Julian Santer < >>> <julian.san...@rolmail.net>julian.san...@rolmail.net <mailto: >>> julian.san...@rolmail.net>> wrote: >>> >>> Bogdan, >>> >>> we tried now the latest GIT release and it works like a charm ;-) >>> Thank you for quick fix. >>> >>> Kind regards, >>> Julian Santer >>> Raiffeisen OnLine >>> >>> Am 11.02.2016 um 14:02 schrieb Bogdan-Andrei Iancu: >>> >>> Julian, >>> >>> Please update from GIT repo and give it a new try. It should >>> work now (at least it does for me). >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 11.02.2016 12:07, Julian Santer wrote: >>> >>> Hi Bogdan, >>> >>> thank you for your time. If you need further informations >>> (config files etc.) let me know. >>> >>> Kind regards, >>> Julian Santer >>> Raiffeisen OnLine >>> >>> Am 11.02.2016 um 10:26 schrieb Bogdan-Andrei Iancu: >>> >>> Hi Julian, >>> >>> I will have to test this and come back to you. >>> >>> Regards, >>> >>> Bogdan-Andrei Iancu >>> OpenSIPS Founder and Developer >>> http://www.opensips-solutions.com >>> >>> On 10.02.2016 17:45, Julian Santer wrote: >>> >>> Hi guys, >>> >>> we seem to got the same issue like John Nash on >>> 2015/08/12. >>> We use OpenSips 2.1.2 with the latest revision from >>> git repo. >>> >>> Like John we are not sure if it is a bug or our >>> mistake ;-) >>> >>> We are using topology hiding and the Call ID in the >>> CANCEL, generated by the TM module, is not the same, as the call ID in the >>> initial INVITE. >>> >>> The call flow looks like: >>> PSTN carrier -> gw-carrier (topo hiding) -> core >>> (topo hiding) -> gw-consumer (topo-hiding) -> UAC consumer >>> >>> The CANCEL generated by the TM module of the core, >>> sended to the gw-consumer is rejected by the gw-consumer. >>> >>> The CANCEL starts on the core. So let me show you >>> 1) the initial INVITE, which the core receives from >>> the gw-carrier (Call-ID: GW-CARRIER) >>> 2) the initial INVITE, which the core and sends to >>> the gw-consumer (Call-ID: Core) >>> 3) the CANCEL generated by the core after >>> $T_fr_inv_timeout (Call-ID: GW-CARRIER) >>> >>> 1) >>> INVITE sip:12345@IP_CORE SIP/2.0 >>> Via: SIP/2.0/UDP >>> IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0 >>> From: <sip:+396789@domain>;tag=E3AE5C5C-1A42 >>> To: <sip:12345@domain> >>> Call-ID: >>> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE >>> CSeq: 101 INVITE >>> Max-Forwards: 8 >>> Remote-Party-ID: <sip:+396789@IP_CARRIER >>> >;party=calling;screen=yes;privacy=off >>> Contact: >>> <sip:+396789@IP_GW-CARRIER;rdlg=3db.94186637> >>> <sip:+396789@IP_GW-CARRIER;rdlg=3db.94186637> >>> Expires: 180 >>> Content-Type: application/sdp >>> Content-Length: 474 >>> sdp ... >>> >>> 2) >>> INVITE sip:12345@IP_UAC:PORT_UAC SIP/2.0 >>> Via: SIP/2.0/UDP >>> IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0 >>> Route: <sip:IP_GW-CONSUMER;lr> >>> From: <sip:+396789@domain>;tag=E3AE5C5C-1A42 >>> To: <sip:12345@domain> >>> Call-ID: >>> Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG >>> CSeq: 101 INVITE >>> Max-Forwards: 7 >>> Remote-Party-ID: <sip:+396789@IP_CARRIER >>> >;party=calling;screen=yes;privacy=off >>> Contact: <sip:+396789@IP_CORE;rdlg=28e.bad6c124> >>> <sip:+396789@IP_CORE;rdlg=28e.bad6c124> >>> Expires: 180 >>> Content-Type: application/sdp >>> Content-Length: 426 >>> sdp ... >>> >>> 3) >>> CANCEL sip:12345@IP_UAC:PORT_UAC SIP/2.0 >>> Via: SIP/2.0/UDP >>> IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0 >>> From: <sip:+396789@domain>;tag=E3AE5C5C-1A42 >>> Call-ID: >>> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE >>> To: <sip:12345@domain> >>> CSeq: 101 CANCEL >>> Max-Forwards: 70 >>> Route: <sip:IP_GW-CONSUMER;lr> >>> Reason: SIP;cause=480;text="NO_ANSWER" >>> User-Agent: OpenSIPS (2.1.2 (x86_64/linux)) >>> Content-Length: 0 >>> >>> Kind regards, >>> Julian Santer >>> Raiffeisen OnLine >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org <mailto: >>> Users@lists.opensips.org> >>> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org <mailto:Users@lists.opensips.org> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opensips.org <mailto:Users@lists.opensips.org> >>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> > > > > _______________________________________________ > Users mailing > listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users > > > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users