Upstream ignores reply, because To-tag doesn't match?

List overview All Threads
Download

newer

older

Centos 7 opensuse repo issues for...

modifying via header from public...

Sergiu Pojoga

6 Apr 2019 6 Apr '19

3:25 p.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@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

Attachments:

attachment.html (text/html — 7.8 KB)

Show replies by date

Sergiu Pojoga

7 Apr 7 Apr

1: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@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

Alex Balashov

4:41 p.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@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 List sr-users@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/

Daniel-Constantin Mierla

8 Apr 8 Apr

6:15 a.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

...

Suggestions?

On Sat, Apr 6, 2019 at 11:25 AM Sergiu Pojoga <pojogas@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@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 List sr-users@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

Sergiu Pojoga

3:34 p.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@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

Daniel-Constantin Mierla

9 Apr 9 Apr

11:10 a.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@gmail.com mailto: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
<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@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@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@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@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

Sergiu Pojoga

12:08 p.m.

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

Daniel-Constantin Mierla

3:54 p.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@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:

...

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 <mailto: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 <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@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@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@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@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@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

Sergiu Pojoga

4:30 p.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@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@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

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

2202

Age (days ago)

2205

Last active (days ago)

sr-users@lists.kamailio.org

8 comments

3 participants

tags (0)

participants (3)

Alex Balashov
Daniel-Constantin Mierla
Sergiu Pojoga