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 <mico...@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, <mico...@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 < >> mico...@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 <pojo...@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:514xxxx...@208.72.xxx.xxx>;isup-oli=00;tag=1975755942 >>>> >>>> >>>> To: <sip:514xxxx...@65.39.xxx.xxx>;tag=as2ab54180 >>>> >>>> >>>> >>>> Call-ID: did-28270...@208.72.xxx.xx >>>> >>>> >>>> >>>> CSeq: 477023 INVITE >>>> >>>> >>>> >>>> Supported: replaces, timer, path >>>> >>>> >>>> >>>> Contact: <sip:1514xxxx...@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-28270...@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:514xxxx...@208.72.xxx.xxx>;isup-oli=00;tag=1975755942 >>>> >>>> >>>> To: <sip:514xxxx...@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 >> >> > _______________________________________________ > 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 List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users