7 Apr
2019
7 Apr
'19
2:25 a.m.
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't hang
up. This doesn't happen when the client's gateway generates identical 503
or other negative replies.
I suspect this is happening because the To-tag in the Kam generated 503
reply doesn't match with the To-tag that previously was forwarded from the
client's gateway to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU" <sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU" <sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
7 Apr
7 Apr
11:40 p.m.
To simplify, the problem seems to come down to the following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be terminated
with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") - doesn't
seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't
hang up. This doesn't happen when the client's gateway generates identical
503 or other negative replies.
I suspect this is happening because the To-tag in the Kam generated 503
reply doesn't match with the To-tag that previously was forwarded from the
client's gateway to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=
a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
8 Apr
8 Apr
2:41 a.m.
Hi,
To-tags are only significant at the dialog layer. Replies are matched to
a transaction by Via `branch` parameter and CSeq. See RFC 3261 § 17.1.3
for details.
Consequently, the 503 response should be matched to the initial INVITE
transaction on that basis alone.
-- Alex
On Sun, Apr 07, 2019 at 09:40:10AM -0400, Sergiu Pojoga wrote:
To simplify, the problem seems to come down to the
following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated
with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") - doesn't
seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
> Hi ppl,
>
> Scenario: invite from upstream is t_relayed to a client gateway. After
> `fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
> Service unavailable", then exit().
>
> However, the upstream provider simply ignores this reply, call doesn't
> hang up. This doesn't happen when the client's gateway generates identical
> 503 or other negative replies.
>
> I suspect this is happening because the To-tag in the Kam generated 503
> reply doesn't match with the To-tag that previously was forwarded from the
> client's gateway to the upstream provider in the `180 Ringing`.
>
> Any suggestions what can be done about it?
>
>
> 2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
>
>
> SIP/2.0 180 Ringing
>
>
>
> Via: SIP/2.0/UDP
> 208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
>
>
> Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
>
>
>
> From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
>
>
> To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
>
>
>
> Call-ID: DID-28270826(a)208.72.xxx.xx
>
>
>
> CSeq: 477023 INVITE
>
>
>
> Supported: replaces, timer, path
>
>
>
> Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
>
>
>
> Content-Length: 0
>
>
>
>
>
>
>
>
>
>
>
> 2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
>
>
> SIP/2.0 503 Service Unavailable
>
>
>
> Call-ID: DID-28270826(a)208.72.xxx.xx
>
>
>
> Via: SIP/2.0/UDP
> 208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
>
>
> From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
>
>
> To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=
> a6a1c5f60faecf035a1ae5b6e96e979a-8e82
>
>
> CSeq: 477023 INVITE
>
>
>
> Server: KAM
>
>
>
> Content-Length: 0
>
> Thanks,
> --Sergiu
>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
4:15 p.m.
On 07.04.19 15:40, Sergiu Pojoga wrote:
To simplify, the problem seems to come down to the
following: how do
you cancel/end an early state dialog between the caller and callee
after `fr_inv_timeout` occurs? Kam self-generates a proper CANCEL
towards the callee, while the caller gets a `408 Request Timeout' with
a different To-tag.
That's all required not to have a dialog completed, but faild. There is
no need to send a BYE or another CANCEL. The INVITE got the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") -
doesn't seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com
<mailto:pojogas@gmail.com>> wrote:
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway.
After `fr_inv_timeout` occurs, in a failure route I simply t_reply
with "503 - Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call
doesn't hang up. This doesn't happen when the client's gateway
generates identical 503 or other negative replies.
I suspect this is happening because the To-tag in the Kam
generated 503 reply doesn't match with the To-tag that previously
was forwarded from the client's gateway to the upstream provider
in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To:
<sip:514XXXXXXX@65.39.xxx.xxx>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
9 Apr
9 Apr
1:34 a.m.
Looks like it's going to be another battle with a Metaswitch-based
carrier... so far they are telling me 'we can't do anything about it. Send
us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to overcome this,
would *uac_req_send() *be my only option?
Thanks again,
--Sergiu
On Mon, Apr 8, 2019 at 2:15 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
On 07.04.19 15:40, Sergiu Pojoga wrote:
To simplify, the problem seems to come down to the following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
That's all required not to have a dialog completed, but faild. There is no
need to send a BYE or another CANCEL. The INVITE got the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") - doesn't
seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't
hang up. This doesn't happen when the client's gateway generates identical
503 or other negative replies.
I suspect this is happening because the To-tag in the Kam generated 503
reply doesn't match with the To-tag that previously was forwarded from the
client's gateway to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=
a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
9:10 p.m.
To be sure I understand properly: do they require to send a CANCEL back
to them for calls that they initiate with the first INVITE and do not
get 200ok, but 3xx/4xx/5xx?
Cheers,
Daniel
On 08.04.19 17:34, Sergiu Pojoga wrote:
Looks like it's going to be another battle with a
Metaswitch-based
carrier... so far they are telling me 'we can't do anything about it.
Send us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to overcome
this, would *uac_req_send() *be my only option?
Thanks again,
--Sergiu
On Mon, Apr 8, 2019 at 2:15 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
On 07.04.19 15:40, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
To simplify, the problem seems to come down
to the following: how
do you cancel/end an early state dialog between the caller and
callee after `fr_inv_timeout` occurs? Kam self-generates a proper
CANCEL towards the callee, while the caller gets a `408 Request
Timeout' with a different To-tag.
That's all required not to have a dialog completed, but faild.
There is no need to send a BYE or another CANCEL. The INVITE got
the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)",
"22", "200") -
doesn't seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com
<mailto:pojogas@gmail.com>> wrote:
Hi ppl,
Scenario: invite from upstream is t_relayed to a client
gateway. After `fr_inv_timeout` occurs, in a failure route I
simply t_reply with "503 - Service unavailable", then exit().
However, the upstream provider simply ignores this reply,
call doesn't hang up. This doesn't happen when the client's
gateway generates identical 503 or other negative replies.
I suspect this is happening because the To-tag in the Kam
generated 503 reply doesn't match with the To-tag that
previously was forwarded from the client's gateway to the
upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
<mailto:DID-28270826@208.72.xxx.xx>
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
<mailto:DID-28270826@208.72.xxx.xx>
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To:
<sip:514XXXXXXX@65.39.xxx.xxx>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
10:08 p.m.
Yes Daniel, that is precisely so.
On Tue, Apr 9, 2019, 7:10 AM Daniel-Constantin Mierla, <miconda(a)gmail.com>
wrote:
To be sure I understand properly: do they require to
send a CANCEL back to
them for calls that they initiate with the first INVITE and do not get
200ok, but 3xx/4xx/5xx?
Cheers,
Daniel
On 08.04.19 17:34, Sergiu Pojoga wrote:
Looks like it's going to be another battle with a Metaswitch-based
carrier... so far they are telling me 'we can't do anything about it. Send
us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to overcome this,
would *uac_req_send() *be my only option?
Thanks again,
--Sergiu
On Mon, Apr 8, 2019 at 2:15 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
On 07.04.19 15:40, Sergiu Pojoga wrote:
To simplify, the problem seems to come down to the following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
That's all required not to have a dialog completed, but faild. There is
no need to send a BYE or another CANCEL. The INVITE got the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") - doesn't
seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't
hang up. This doesn't happen when the client's gateway generates identical
503 or other negative replies.
I suspect this is happening because the To-tag in the Kam generated 503
reply doesn't match with the To-tag that previously was forwarded from the
client's gateway to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=
a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
10 Apr
10 Apr
1:54 a.m.
That's really strange, the CANCEL has the same direction as INVITE, not
the opposite. Can you double check if they really asked for such things.
This is very clear in terms of SIP specs and I doubt that someone
understood it wrong.
Cheers,
Daniel
On 09.04.19 14:08, Sergiu Pojoga wrote:
Yes Daniel, that is precisely so.
On Tue, Apr 9, 2019, 7:10 AM Daniel-Constantin Mierla,
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
To be sure I understand properly: do they require to send a CANCEL
back to them for calls that they initiate with the first INVITE
and do not get 200ok, but 3xx/4xx/5xx?
Cheers,
Daniel
On 08.04.19 17:34, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Looks like it's going to be another
battle with a
Metaswitch-based carrier... so far they are telling me 'we can't
do anything about it. Send us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to
overcome this, would *uac_req_send() *be my only option?
Thanks again,
--Sergiu
On Mon, Apr 8, 2019 at 2:15 AM Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
On 07.04.19 15:40, Sergiu Pojoga wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users To simplify, the problem seems to come
down to the
following: how do you cancel/end an early state dialog
between the caller and callee after `fr_inv_timeout` occurs?
Kam self-generates a proper CANCEL towards the callee, while
the caller gets a `408 Request Timeout' with a different To-tag.
That's all required not to have a dialog completed, but
faild. There is no need to send a BYE or another CANCEL. The
INVITE got the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs
can't be terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)",
"22",
"200") - doesn't seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga
<pojogas(a)gmail.com <mailto:pojogas@gmail.com>> wrote:
Hi ppl,
Scenario: invite from upstream is t_relayed to a client
gateway. After `fr_inv_timeout` occurs, in a failure
route I simply t_reply with "503 - Service unavailable",
then exit().
However, the upstream provider simply ignores this
reply, call doesn't hang up. This doesn't happen when
the client's gateway generates identical 503 or other
negative replies.
I suspect this is happening because the To-tag in the
Kam generated 503 reply doesn't match with the To-tag
that previously was forwarded from the client's gateway
to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
<mailto:DID-28270826@208.72.xxx.xx>
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 ->
208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
<mailto:DID-28270826@208.72.xxx.xx>
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To:
<sip:514XXXXXXX@65.39.xxx.xxx>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
<http://www.kamailioworld.com>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
2:30 a.m.
Daniel,
Becomes clear that the carrier's SIP knowledge is worse than mine... sorry
for wasting your time.
Regards,
Sergiu
On Tue, Apr 9, 2019 at 11:54 AM Daniel-Constantin Mierla <miconda(a)gmail.com>
wrote:
That's really strange, the CANCEL has the same
direction as INVITE, not
the opposite. Can you double check if they really asked for such things.
This is very clear in terms of SIP specs and I doubt that someone
understood it wrong.
Cheers,
Daniel
On 09.04.19 14:08, Sergiu Pojoga wrote:
Yes Daniel, that is precisely so.
On Tue, Apr 9, 2019, 7:10 AM Daniel-Constantin Mierla, <miconda(a)gmail.com>
wrote:
To be sure I understand properly: do they require
to send a CANCEL back
to them for calls that they initiate with the first INVITE and do not get
200ok, but 3xx/4xx/5xx?
Cheers,
Daniel
On 08.04.19 17:34, Sergiu Pojoga wrote:
Looks like it's going to be another battle with a Metaswitch-based
carrier... so far they are telling me 'we can't do anything about it. Send
us a CANCEL to tear down the call`
I know this is a `another story` question, but if I had to overcome this,
would *uac_req_send() *be my only option?
Thanks again,
--Sergiu
On Mon, Apr 8, 2019 at 2:15 AM Daniel-Constantin Mierla <
miconda(a)gmail.com> wrote:
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
On 07.04.19 15:40, Sergiu Pojoga wrote:
To simplify, the problem seems to come down to the following: how do you
cancel/end an early state dialog between the caller and callee after
`fr_inv_timeout` occurs? Kam self-generates a proper CANCEL towards the
callee, while the caller gets a `408 Request Timeout' with a different
To-tag.
That's all required not to have a dialog completed, but faild. There is
no need to send a BYE or another CANCEL. The INVITE got the 408, not 200.
Cheers,
Daniel
I've tried:
dlg_bye("all") - throws an error, non-confirmed dialogs can't be
terminated with this function
t_cancel_callid("$dlg(callid)", "$dlg(from_cseq)", "22",
"200") -
doesn't seem to produce any action
Suggestions?
On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas(a)gmail.com> wrote:
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Hi ppl,
Scenario: invite from upstream is t_relayed to a client gateway. After
`fr_inv_timeout` occurs, in a failure route I simply t_reply with "503 -
Service unavailable", then exit().
However, the upstream provider simply ignores this reply, call doesn't
hang up. This doesn't happen when the client's gateway generates identical
503 or other negative replies.
I suspect this is happening because the To-tag in the Kam generated 503
reply doesn't match with the To-tag that previously was forwarded from the
client's gateway to the upstream provider in the `180 Ringing`.
Any suggestions what can be done about it?
2019/04/06 10:42:46.127177 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;received=208.72.xxx.xxx;rport=5060;branch=z9hG4bK1982422573
Record-Route: <sip:65.39.xxx.xxx;lr=on;did=915.8af1>
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=as2ab54180
Call-ID: DID-28270826(a)208.72.xxx.xx
CSeq: 477023 INVITE
Supported: replaces, timer, path
Contact: <sip:1514XXXXXXX@65.39.xxx.xxx:5060>
Content-Length: 0
2019/04/06 10:42:51.072516 65.39.xxx.xxx:5060 -> 208.72.xxx.xxx:5060
SIP/2.0 503 Service Unavailable
Call-ID: DID-28270826(a)208.72.xxx.xx
Via: SIP/2.0/UDP
208.72.xxx.xxx:5060;rport=5060;branch=z9hG4bK1982422573;received=208.72.xxx.xxx
From: "SERGIU"
<sip:514XXXXXXX@208.72.xxx.xxx>;isup-oli=00;tag=1975755942
To: <sip:514XXXXXXX@65.39.xxx.xxx>;tag=
a6a1c5f60faecf035a1ae5b6e96e979a-8e82
CSeq: 477023 INVITE
Server: KAM
Content-Length: 0
Thanks,
--Sergiu
_______________________________________________
Kamailio (SER) - Users Mailing
Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda --
www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
2137
days inactive
2140
days old
8 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel-Constantin Mierla -
Sergiu Pojoga