[SR-Users] Upstream ignores reply, because To-tag doesn't match?
Daniel-Constantin Mierla
miconda at gmail.com
Tue Apr 9 17:54:05 CEST 2019
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 <mailto: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 <mailto: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 <mailto: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
>>> <mailto: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
>>> <mailto: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 List
>>> sr-users at lists.kamailio.org <mailto:sr-users at 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 at lists.kamailio.org <mailto:sr-users at 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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20190409/8a301a73/attachment.html>
More information about the sr-users
mailing list