Yes Daniel, that is precisely so.
On Tue, Apr 9, 2019, 7:10 AM Daniel-Constantin Mierla, 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:
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@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@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@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@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
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