[OpenSIPS-Users] Call-id issue in Cancel message generated by tm / $T_fr_inv_timeout
John Nash
john.nash778 at gmail.com
Sun Apr 24 08:58:05 CEST 2016
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>
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.santer at rolmail.net>
> wrote:
>
>> Hi John,
>>
>> the commit was:
>>
>> commit 8133656de9503a122a72c0f80d11eff975bc43f1
>> Author: Bogdan-Andrei Iancu <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>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>
>>> <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>
>>> <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>
>>>
>>> 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
>>
>
>
>
> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/20160424/aff392fe/attachment-0001.htm>
More information about the Users
mailing list