[SR-Users] Upstream ignores reply, because To-tag doesn't match?

[Sergiu Pojoga]

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 at 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 at 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 at 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 at 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 at 208.72.xxx.xxx>;isup-oli=00;tag=1975755942
>>>>
>>>>
>>>> To: <sip:514XXXXXXX at 65.39.xxx.xxx>;tag=as2ab54180
>>>>
>>>>
>>>>
>>>> Call-ID: DID-28270826 at 208.72.xxx.xx
>>>>
>>>>
>>>>
>>>> CSeq: 477023 INVITE
>>>>
>>>>
>>>>
>>>> Supported: replaces, timer, path
>>>>
>>>>
>>>>
>>>> Contact: <sip:1514XXXXXXX at 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 at 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 at 208.72.xxx.xxx>;isup-oli=00;tag=1975755942
>>>>
>>>>
>>>> To: <sip:514XXXXXXX at 65.39.xxx.xxx>;tag=
>>>> a6a1c5f60faecf035a1ae5b6e96e979a-8e82
>>>>
>>>>
>>>> CSeq: 477023 INVITE
>>>>
>>>>
>>>>
>>>> Server: KAM
>>>>
>>>>
>>>>
>>>> Content-Length: 0
>>>>
>>>> Thanks,
>>>> --Sergiu
>>>>
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing Listsr-users at 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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190409/85c631a6/attachment.html>