[OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout

Bogdan-Andrei Iancu bogdan at opensips.org
Sat Apr 30 12:25:57 CEST 2016


Hi John,

That is difference between a locally generated timeout (your scenario 1) 
and a received timeout (scenario 2) - to see which one is, in failure 
route you can use the t_local_replied() function from tm :
http://www.opensips.org/html/docs/modules/2.2.x/tm.html#id295063

Regards,

Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com

On 24.04.2016 09:58, John Nash wrote:
> 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 
> <bogdan at opensips.org <mailto:bogdan at 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 Developer
>     http://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.santer at rolmail.net <mailto:julian.santer at rolmail.net>> wrote:
>>
>>         Hi John,
>>
>>         the commit was:
>>
>>         commit 8133656de9503a122a72c0f80d11eff975bc43f1
>>         Author: Bogdan-Andrei Iancu <bogdan at opensips.org
>>         <mailto:bogdan at 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.santer at rolmail.net
>>             <mailto:julian.santer at rolmail.net>
>>             <mailto:julian.santer at rolmail.net
>>             <mailto:julian.santer at 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 at IP_CORE SIP/2.0
>>                                 Via: SIP/2.0/UDP
>>             IP_GW-CARRIER:5060;branch=z9hG4bK6aa2.7710f555.0
>>                                 From:
>>             <sip:+396789 at domain>;tag=E3AE5C5C-1A42
>>                                 To: <sip:12345 at domain>
>>                                 Call-ID:
>>             GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
>>                                 CSeq: 101 INVITE
>>                                 Max-Forwards:  8
>>                                 Remote-Party-ID:
>>             <sip:+396789 at IP_CARRIER>;party=calling;screen=yes;privacy=off
>>                                 Contact:
>>             <sip:+396789 at IP_GW-CARRIER;rdlg=3db.94186637>
>>             <mailto:sip:+396789 at IP_GW-CARRIER;rdlg=3db.94186637>
>>                                 Expires: 180
>>                                 Content-Type: application/sdp
>>                                 Content-Length: 474
>>                                 sdp ...
>>
>>                                 2)
>>                                 INVITE sip:12345 at 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 at domain>;tag=E3AE5C5C-1A42
>>                                 To: <sip:12345 at domain>
>>                                 Call-ID:
>>             Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
>>                                 CSeq: 101 INVITE
>>                                 Max-Forwards:  7
>>                                 Remote-Party-ID:
>>             <sip:+396789 at IP_CARRIER>;party=calling;screen=yes;privacy=off
>>                                 Contact:
>>             <sip:+396789 at IP_CORE;rdlg=28e.bad6c124>
>>             <mailto:sip:+396789 at IP_CORE;rdlg=28e.bad6c124>
>>                                 Expires: 180
>>                                 Content-Type: application/sdp
>>                                 Content-Length: 426
>>                                 sdp ...
>>
>>                                 3)
>>                                 CANCEL sip:12345 at IP_UAC:PORT_UAC SIP/2.0
>>                                 Via: SIP/2.0/UDP
>>             IP_CORE:5060;branch=z9hG4bK45da.82f6fd55.0
>>                                 From:
>>             <sip:+396789 at domain>;tag=E3AE5C5C-1A42
>>                                 Call-ID:
>>             GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
>>                                 To: <sip:12345 at 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 at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>
>>             <mailto:Users at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>>
>>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>>
>>             _______________________________________________
>>                         Users mailing list
>>             Users at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>
>>             <mailto:Users at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>>
>>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>>
>>             _______________________________________________
>>                 Users mailing list
>>             Users at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>
>>             <mailto:Users at lists.opensips.org
>>             <mailto:Users at lists.opensips.org>>
>>             http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>
>>
>>
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>     _______________________________________________
>     Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160430/c1f84695/attachment-0001.htm>


More information about the Users mailing list