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

John Nash john.nash778 at gmail.com
Tue Apr 19 16:49:08 CEST 2016


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
>> <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>
>>                     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>
>>                     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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20160419/5ed413a7/attachment.htm>


More information about the Users mailing list