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
<bog...@opensips.org <mailto:bog...@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.san...@rolmail.net <mailto:julian.san...@rolmail.net>> wrote:
Hi John,
the commit was:
commit 8133656de9503a122a72c0f80d11eff975bc43f1
Author: Bogdan-Andrei Iancu <bog...@opensips.org
<mailto:bog...@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.san...@rolmail.net
<mailto:julian.san...@rolmail.net>
<mailto:julian.san...@rolmail.net
<mailto: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:
<sip:+396789@domain>;tag=E3AE5C5C-1A42
To: <sip:12345@domain>
Call-ID:
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
CSeq: 101 INVITE
Max-Forwards: 8
Remote-Party-ID:
<sip:+396789@IP_CARRIER>;party=calling;screen=yes;privacy=off
Contact:
<sip:+396789@IP_GW-CARRIER;rdlg=3db.94186637>
<mailto:sip:+396789@IP_GW-CARRIER;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: <sip:IP_GW-CONSUMER;lr>
From:
<sip:+396789@domain>;tag=E3AE5C5C-1A42
To: <sip:12345@domain>
Call-ID:
Core_ExwGCwAcKhgvdAgnFg58LwQGAXUOXSAzC3A1JFB/FCcWCWFzGAQkXHInPFQGDzYYI3oPCCAMahZeEy11JywlCVEG
CSeq: 101 INVITE
Max-Forwards: 7
Remote-Party-ID:
<sip:+396789@IP_CARRIER>;party=calling;screen=yes;privacy=off
Contact:
<sip:+396789@IP_CORE;rdlg=28e.bad6c124>
<mailto:sip:+396789@IP_CORE;rdlg=28e.bad6c124>
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:
<sip:+396789@domain>;tag=E3AE5C5C-1A42
Call-ID:
GW-CARRIER_EjJFKHdkNlktdGM2RV93ZV5MWHdlS0wvAn1HN14LYjFHLgRiXU1aHGdCWlcE
To: <sip:12345@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@lists.opensips.org
<mailto:Users@lists.opensips.org>
<mailto: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
<mailto:Users@lists.opensips.org>
<mailto: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
<mailto:Users@lists.opensips.org>
<mailto: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 <mailto:Users@lists.opensips.org>
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
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 <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
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
