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

[Bogdan-Andrei Iancu]

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 
> 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
> wrote:

Hi John,

the commit was:

commit 8133656de9503a122a72c0f80d11eff975bc43f1
Author: Bogdan-Andrei Iancu >
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

>> 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.

 

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

[John Nash]

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 
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 
> wrote:
>
>> Hi John,
>>
>> the commit was:
>>
>> commit 8133656de9503a122a72c0f80d11eff975bc43f1
>> Author: Bogdan-Andrei Iancu 
>> 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>> 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: ;tag=E3AE5C5C-1A42
>>> To: 

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

[Bogdan-Andrei Iancu]

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 
> wrote:


Hi John,

the commit was:

commit 8133656de9503a122a72c0f80d11eff975bc43f1
Author: Bogdan-Andrei Iancu >
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

>> 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: ;tag=E3AE5C5C-1A42
To: 
Call-ID:
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID:
   

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

[John Nash]

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 
wrote:

> Hi John,
>
> the commit was:
>
> commit 8133656de9503a122a72c0f80d11eff975bc43f1
> Author: Bogdan-Andrei Iancu 
> 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 > > 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: ;tag=E3AE5C5C-1A42
>> To: 
>> Call-ID:
>> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
>> CSeq: 101 INVITE
>> Max-Forwards:  8
>> Remote-Party-ID: > >;party=calling;screen=yes;privacy=off
>> Contact: > ;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: 
>> From: ;tag=E3AE5C5C-1A42
>> To: 
>> Call-ID:
>> Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
>> CSeq: 101 INVITE
>> 

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

[Julian Santer]

Hi John,

the commit was:

commit 8133656de9503a122a72c0f80d11eff975bc43f1
Author: Bogdan-Andrei Iancu 
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 > 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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off
Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off
Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: 

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

[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 
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: ;tag=E3AE5C5C-1A42
> To: 
> Call-ID:
> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
> CSeq: 101 INVITE
> Max-Forwards:  8
> Remote-Party-ID:  >;party=calling;screen=yes;privacy=off
> Contact: 
> 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: 
> From: ;tag=E3AE5C5C-1A42
> To: 
> Call-ID:
> Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
> CSeq: 101 INVITE
> Max-Forwards:  7
> Remote-Party-ID:  >;party=calling;screen=yes;privacy=off
> Contact: 
> 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: ;tag=E3AE5C5C-1A42
> Call-ID:
> GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
> To: 
> CSeq: 101 CANCEL
> Max-Forwards: 70
> Route: 
> 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
> 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 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

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

[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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG

CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

To: 
CSeq: 101 CANCEL
Max-Forwards: 70
Route: 
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
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

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

[Julian Santer]

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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
To: 
CSeq: 101 CANCEL
Max-Forwards: 70
Route: 
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
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

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

[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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG

CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

To: 
CSeq: 101 CANCEL
Max-Forwards: 70
Route: 
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
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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Julian Santer]

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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: ;party=calling;screen=yes;privacy=off
Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
To: 
CSeq: 101 CANCEL
Max-Forwards: 70
Route: 
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
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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

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

[Bogdan-Andrei Iancu]

Julian,

No need for anything more as I managed to reproduce it. Let me dig in 
and fix.


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: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

CSeq: 101 INVITE
Max-Forwards:  8
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: 
From: ;tag=E3AE5C5C-1A42
To: 
Call-ID: 
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG

CSeq: 101 INVITE
Max-Forwards:  7
Remote-Party-ID: 
;party=calling;screen=yes;privacy=off

Contact: 
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: ;tag=E3AE5C5C-1A42
Call-ID: 
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE

To: 
CSeq: 101 CANCEL
Max-Forwards: 70
Route: 
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
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 list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm

[John Nash]

Yes it is the original A leg Invite.

On Thu, Aug 13, 2015 at 2:45 PM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:

 Hi John,

 Is the callid in CANCEL the original one from the incoming INVITE ?

 Regards,

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

 On 12.08.2015 09:52, John Nash wrote:

 I am not sure if its some bug or my mistake.

 I am using topology hiding module (opensips 2.1 version) and I have
 noticed that Call-id in Cancel message is different than Invite sent to
 gateway.

 Invite is sent to gateway and we get session progress but call is not
 picked up, as per fr_timer opensips triggers cancel but call ID in cancel
 is not same as sent in Invite

 INVITE sip:11025@2.2.2.2:5060 SIP/2.0
 Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
 Max-Forwards: 26
 From: 786786 sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F
 To: sip:11025@2.2.2.2:5060
 Call-ID: DLGCH_LkhSV2VxNGNiEgQMMGRhYXxDSF9rcDN+K0QEC2Z7M2ouFFFd
 CSeq: 79309702 INVITE
 Contact: sip:sbc@1.1.1.1:9096;did=775.84850bf2
 sip:sbc@1.1.1.1:9096;did=775.84850bf2
 User-Agent: Opensips
 Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER,
 REFER, NOTIFY, PUBLISH, SUBSCRIBE
 Supported: timer, path, replaces
 Allow-Events: talk, hold, conference, presence, as-feature-event, dialog,
 line-seize, call-info, sla, include-session-description, presence.winfo,
 message-summary, refer
 Content-Type: application/sdp
 Content-Disposition: session
 Content-Length: 258

 v=0
 o=- 22469580 22469580 IN IP4 1.1.1.1
 s=Softphone
 c=IN IP4 1.1.1.1
 t=0 0
 m=audio 32706 RTP/AVP 18 101
 a=rtpmap:18 G729/8000
 a=fmtp:18 annexb=no
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-15
 a=ptime:20
 a=rtcp:32707


 CANCEL sip:11025@2.2.2.2:5060 SIP/2.0
 Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
 From: 786786 sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F
 Call-ID: a87968d0-babc-1233-189c-d4ae52c9ad43
 To: sip:11025@2.2.2.2:5060
 CSeq: 79309702 CANCEL
 Max-Forwards: 70
 Reason: SIP;cause=480;text=NO_ANSWER
 User-Agent: Opensips
 Content-Length: 0


 ___
 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

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm

[Bogdan-Andrei Iancu]

Hi John,

Could you please use the latest 2.1 GIT version and see how it is going 
? If still bogus, could you please past somewhere the whole SIP flow 
showing the in and out messages (from opensips perspective) ?


Regards,

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

On 19.08.2015 15:54, John Nash wrote:

Yes it is the original A leg Invite.

On Thu, Aug 13, 2015 at 2:45 PM, Bogdan-Andrei Iancu 
bog...@opensips.org mailto:bog...@opensips.org wrote:


Hi John,

Is the callid in CANCEL the original one from the incoming INVITE ?

Regards,

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

On 12.08.2015 09:52, John Nash wrote:

I am not sure if its some bug or my mistake.

I am using topology hiding module (opensips 2.1 version) and I
have noticed that Call-id in Cancel message is different than
Invite sent to gateway.

Invite is sent to gateway and we get session progress but call is
not picked up, as per fr_timer opensips triggers cancel but call
ID in cancel is not same as sent in Invite

INVITE sip:11025@2.2.2.2:5060
http://sip:11025@2.2.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
Max-Forwards: 26
From: 786786 sip:786786@1.1.1.1:9096
http://sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F
To: sip:11025@2.2.2.2:5060
http://sip:11025@2.2.2.2:5060
Call-ID: DLGCH_LkhSV2VxNGNiEgQMMGRhYXxDSF9rcDN+K0QEC2Z7M2ouFFFd
CSeq: 79309702 INVITE
Contact: sip:sbc@1.1.1.1:9096;did=775.84850bf2
mailto:sip:sbc@1.1.1.1:9096;did=775.84850bf2
User-Agent: Opensips
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event,
dialog, line-seize, call-info, sla, include-session-description,
presence.winfo, message-summary, refer
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 258

v=0
o=- 22469580 22469580 IN IP4 1.1.1.1
s=Softphone
c=IN IP4 1.1.1.1
t=0 0
m=audio 32706 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:32707


CANCEL sip:11025@2.2.2.2:5060
http://sip:11025@2.2.2.2:5060 SIP/2.0
Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
From: 786786 sip:786786@1.1.1.1:9096
http://sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F
Call-ID: a87968d0-babc-1233-189c-d4ae52c9ad43
To: sip:11025@2.2.2.2:5060
http://sip:11025@2.2.2.2:5060
CSeq: 79309702 CANCEL
Max-Forwards: 70
Reason: SIP;cause=480;text=NO_ANSWER
User-Agent: Opensips
Content-Length: 0


___
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

Re: [OpenSIPS-Users] Call-id issue in Cancel message generated by tm

[Bogdan-Andrei Iancu]

Hi John,

Is the callid in CANCEL the original one from the incoming INVITE ?

Regards,

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

On 12.08.2015 09:52, John Nash wrote:

I am not sure if its some bug or my mistake.

I am using topology hiding module (opensips 2.1 version) and I have 
noticed that Call-id in Cancel message is different than Invite 
sent to gateway.


Invite is sent to gateway and we get session progress but call is not 
picked up, as per fr_timer opensips triggers cancel but call ID in 
cancel is not same as sent in Invite


INVITE sip:11025@2.2.2.2:5060 
http://sip:11025@2.2.2.2:5060 SIP/2.0

Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
Max-Forwards: 26
From: 786786 sip:786786@1.1.1.1:9096 
http://sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F
To: sip:11025@2.2.2.2:5060 
http://sip:11025@2.2.2.2:5060

Call-ID: DLGCH_LkhSV2VxNGNiEgQMMGRhYXxDSF9rcDN+K0QEC2Z7M2ouFFFd
CSeq: 79309702 INVITE
Contact: sip:sbc@1.1.1.1:9096;did=775.84850bf2
User-Agent: Opensips
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, 
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE

Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, 
dialog, line-seize, call-info, sla, include-session-description, 
presence.winfo, message-summary, refer

Content-Type: application/sdp
Content-Disposition: session
Content-Length: 258

v=0
o=- 22469580 22469580 IN IP4 1.1.1.1
s=Softphone
c=IN IP4 1.1.1.1
t=0 0
m=audio 32706 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=rtcp:32707


CANCEL sip:11025@2.2.2.2:5060 
http://sip:11025@2.2.2.2:5060 SIP/2.0

Via: SIP/2.0/UDP 1.1.1.1:9096;branch=z9hG4bKe5d5.fca1aeb4.0
From: 786786 sip:786786@1.1.1.1:9096 
http://sip:786786@1.1.1.1:9096;tag=2B6F7HZaNH02F

Call-ID: a87968d0-babc-1233-189c-d4ae52c9ad43
To: sip:11025@2.2.2.2:5060 
http://sip:11025@2.2.2.2:5060

CSeq: 79309702 CANCEL
Max-Forwards: 70
Reason: SIP;cause=480;text=NO_ANSWER
User-Agent: Opensips
Content-Length: 0


___
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