[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