Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Via: branch in non-200 ACK differs from Via: branch in INVITE. #4

Closed
whosgonna opened this issue Apr 1, 2022 · 3 comments
Closed

Comments

@whosgonna
Copy link
Sponsor

When receiving a non 200 reply for an INVITE sipexer sends a response, but the branch parameter of the via header does not match the branch parameter of the INVITE.

Given this minimal Kamailio config:

#!KAMAILIO

loadmodule "tm.so"
loadmodule "sl.so"
loadmodule "pv.so"

request_route {
    if ( $rm == "ACK" ) {
        if( !t_check_trans() ) {
            exit;
        }
    }
    t_newtran();
    t_reply("404","Not Found");
}

Sending an Invite from sipexer (where kamailio resolves to the host running the kamailio.cfg above):

sipexer -invite kamailio

Has Kamailio repeatedly sending the 404 reply after sipexer sends an ACK. This appears to be due to the ACK's via: header having a different branch than the INVITE.

INVITE (minus SDP):

INVITE sip:kamailio:5060 SIP/2.0
Via: SIP/2.0/UDP 172.31.0.4:56595;rport;branch=z9hG4bKSG.f7f686a3-ce6d-45a1-95a7-42652740d210
From: <sip:alice@localhost>;tag=9dc18f12-c779-4b0e-b30e-681d0526c72e
To: <sip:bob@localhost>
Call-ID: 0418f8d8-d472-43ab-9dc2-786129278a1c
CSeq: 481768 INVITE
Date: Fri, 01 Apr 2022 16:30:13 CDT
User-Agent: SIPExer v1.0.0
Content-Length: 210
Content-Type: application/sdp

ACK:

ACK sip:kamailio:5060 SIP/2.0
Via: SIP/2.0/UDP 172.31.0.4:56595;rport;branch=z9hG4bKSG.cda7e72d-892c-4bee-ad36-cec0734d8c59
From: <sip:alice@localhost>;tag=9dc18f12-c779-4b0e-b30e-681d0526c72e
To: <sip:bob@localhost>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-f254
Call-ID: 0418f8d8-d472-43ab-9dc2-786129278a1c
CSeq: 481768 ACK
Content-Length: 0

Call flow:

             172.31.0.4:56595              172.31.0.3:5060  
          ──────────┬─────────          ──────────┬─────────
  16:30:13.498783   │           INVITE            │ 
        +0.000956   │ ──────────────────────────> │ 
  16:30:13.499739   │        404 Not Found        │ 
        +0.000530   │ <────────────────────────── │ 
  16:30:13.500269   │             ACK             │ 
        +0.447913   │ ──────────────────────────> │ 
  16:30:13.948182   │        404 Not Found        │ 
        +0.999823   │ <<<──────────────────────── │ 
  16:30:14.948005   │        404 Not Found        │ 
        +2.000091   │ <<<──────────────────────── │ 
  16:30:16.948096   │        404 Not Found        │        
                    │ <<<──────────────────────── │
@miconda
Copy link
Owner

miconda commented Apr 13, 2022

Thanks for testing and reporting back! Somehow I failed to notice the issue report so far.

I just pushed a commit for it, but I had no chance to test it myself yet. If you have time to test soon, let me know if works ok.

@whosgonna
Copy link
Sponsor Author

Sorry for the delayed response here. Yes, that seems to correct it. Note: I'm not sure what your workflow for updating the pre-compiled binary is, but it's still the older version. I don't think that's really a problem. I just didn't think about it at first and my first test just grabbed the binary. :)

Closing the issue.

@miconda
Copy link
Owner

miconda commented Apr 26, 2022

Thanks for testing and reporting back. Binaries are generated on a release, not on commit. I was waiting to see if it fixes and I will trigger a new release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants