baresip: no ACK to re-INVITE 200 OK

Just noticed that when today’s baresip main send re-INVITE (hold) and gets back 200 OK, it does not confirm it with ACK (see below). Has some changes made recently that could explain this?

[0:00:26] audio=28357/10005 video=0/0 (bit/s) efps=0.0/0.0    call: hold sip:bar@test.tutpro.com
17:27:35.726#
TCP 192.168.171.45:53262 -> 192.168.171.45:5060
INVITE sip:bar@test.tutpro.com;gr=urn:uuid:24432fb8-562a-296b-f409-473a010260c1 SIP/2.0
Via: SIP/2.0/TCP 192.168.171.45:53262;branch=z9hG4bKcc980b57fb6cbb7b;rport
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:18ffb445-ce14-78c2-8c2e-6ffd34e4a275>
Max-Forwards: 70
Route: <sip:192.168.171.45;transport=tcp;lr>
To: "Bar" <sip:bar@test.tutpro.com>;tag=7bbf032083534e4c
From: <sip:test@test.tutpro.com>;tag=4ad3f03fd7042a74
Call-ID: ec6d412ac36c7f48
CSeq: 1118 INVITE
User-Agent: baresip v3.6.0 (x86_64/Linux)
Content-Type: application/sdp
Content-Length: 1144

v=0
o=- 2707730650 834682369 IN IP4 192.168.171.45
s=-
c=IN IP4 192.168.171.45
t=0 0
m=audio 8954 RTP/AVP 96 97 98 9 99 18 0 8 10 9 100
a=rtpmap:96 opus/48000/2
a=fmtp:96 stereo=0;sprop-stereo=0;maxaveragebitrate=28000;cbr=0;useinbandfec=1
a=rtpmap:97 AMR-WB/16000
a=rtpmap:98 AMR/8000
a=rtpmap:9 G722/8000
a=rtpmap:99 G7221/16000
a=fmtp:99 bitrate=32000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:10 telephone-event/8000
a=fmtp:10 0-15
a=rtpmap:9 G722/8000
a=rtpmap:100 CODEC2/8000
a=sendonly
a=ssrc:1489257764 cname:sip:test@test.tutpro.com
a=minptime:20
a=ptime:20
a=label:1
a=mid:0
m=video 47542 RTP/AVP 96 97 98 99 100
a=rtpmap:96 VP9/90000
a=fmtp:96 max-fs=3600;profile-id=0
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=0;profile-level-id=42e01f
a=rtpmap:98 H264/90000
a=fmtp:98 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:99 VP8/90000
a=fmtp:99 max-fs=3600
a=rtpmap:100 H265/90000
a=fmtp:100 profile-id=1
a=sendonly
a=ssrc:2528770465 cname:sip:test@test.tutpro.com
a=framerate:30.00
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=content:main
a=label:2

stream: update 'audio'
stream: audio: starting mediaenc 'zrtp' (wait_secure=0)
stream: update 'video'
stream: video: starting mediaenc 'zrtp' (wait_secure=0)
17:27:35.756#
TCP 192.168.171.45:5060 -> 192.168.171.45:53262
SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.171.45:53262;received=192.168.171.45;branch=z9hG4bKcc980b57fb6cbb7b;rport=53262
To: "Bar" <sip:bar@test.tutpro.com>;tag=7bbf032083534e4c
From: <sip:test@test.tutpro.com>;tag=4ad3f03fd7042a74
Call-ID: ec6d412ac36c7f48
CSeq: 1118 INVITE
Server: baresip v3.6.0 (?/?)
Contact: <sip:bar@test.tutpro.com;gr=urn:uuid:24432fb8-562a-296b-f409-473a010260c1>
Content-Type: application/sdp
Content-Length: 1074

v=0
o=- 1791962835 770819849 IN IP4 192.168.171.146
s=-
c=IN IP4 192.168.171.146
t=0 0
m=audio 17718 RTP/AVP 96 97 98 99 18 0 8 10 9
a=rtpmap:96 opus/48000/2
a=fmtp:96 stereo=0;sprop-stereo=0;maxaveragebitrate=28000;cbr=0;useinbandfec=1
a=rtpmap:97 AMR-WB/16000
a=rtpmap:98 AMR/8000
a=rtpmap:99 G7221/16000
a=fmtp:99 bitrate=32000
a=rtpmap:18 G729/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:10 telephone-event/8000
a=fmtp:10 0-15
a=rtpmap:9 G722/8000
a=recvonly
a=rtcp-rsize
a=ssrc:1339760344 cname:sip:bar@test.tutpro.com
a=minptime:20
a=ptime:20
a=label:1
a=mid:0
m=video 41864 RTP/AVP 96 97 98 99
a=rtpmap:96 VP9/90000
a=fmtp:96 max-fs=3600;profile-id=0
a=rtpmap:97 VP8/90000
a=fmtp:97 max-fs=3600
a=rtpmap:98 H264/90000
a=fmtp:98 packetization-mode=0;profile-level-id=42e01f
a=rtpmap:99 H264/90000
a=fmtp:99 packetization-mode=1;profile-level-id=42e01f
a=inactive
a=rtcp-rsize
a=ssrc:1486299352 cname:sip:bar@test.tutpro.com
a=mid:1
a=framerate:15.00
a=rtcp-fb:* nack
a=rtcp-fb:* nack pli
a=content:main
a=label:2

test@test.tutpro.com: Call answered: sip:bar@test.tutpro.com
stream: update 'audio'
stream: audio: starting mediaenc 'zrtp' (wait_secure=0)
stream: update 'video'
stream: receive: setting SSRC: 589720d8
stream: video: starting mediaenc 'zrtp' (wait_secure=0)
zrtp: Stream <video> is encrypted (Twofish-256)
zrtp: All streams are encrypted (Twofish-256/EC25), SAS is [gagg] (verified)

About this issue

Original URL
State: closed
Created 8 months ago
Comments: 38 (4 by maintainers)

Most upvoted comments

we have some tests in selftest, but it does not cover all the usecases.

Doing a good old manual testing covers a lot of bugs. If we have time we should do this before each release, in the freeze window.

alfredh on Oct 25, 2023

Note also, that baresip does include Route header to the ACK of initial INVITE as well as PRACK and BYE and sends the request accordingly. It must do the same for ACK of re-INVITE and it has done so forever before the broken PR.

juha-h on Oct 24, 2023

My own Kamailio based SIP proxy. If needed, I can create an account or two for you. Also, here is account config of test:

"Test Account" <sip:test@test.tutpro.com>;auth_user=test;auth_pass=xxxxxx;outbound="sip:lohi.tutpro.com:5060;transport=tcp";audio_codecs=codec2/8000/1,OPUS/16000/1,AMR-WB/16000/1,G722/16000/1,AMR/8000/1,G7221/16000/1,G722/16000/1,G729/8000/1,PCMU,PCMA;video_codecs=VP9,H264,VP8,H265;mwi=no;regint=600;pubint=0;regq=0.5;sipnat=outbound;call_transfer=yes;sip_autoredirect=yes;answermode=manual;dtmfmode=info;100rel=yes

juha-h on Oct 24, 2023

Christian Spielberger writes:

PR for ACK unit test is fine now: https://github.com/baresip/baresip/pull/2775 The issue can not be reproduced. We need more details.

I build re and baresip using tag v3.6.0. Then I started two baresip apps on my Linux host: jh@test.tutpro.com and test@test.tutpro.com. Then jh called test. After the call was established, test issued menu command /hold and received 200 OK to the re-INVITE, but never sent ACK back. I placed pcap of the call here: http://box.tutpro.com/tmp/re-invite.pcapng. All requests/replies go via my SIP Proxy.

I was also running trace at test and it shows that test received the 200 OK to re-INVITE, but didn’t react to it:

18:18:42.297# TCP 192.168.171.45:5060 -> 192.168.171.45:57740 SIP/2.0 200 OK Via: SIP/2.0/TCP 192.168.171.45:57740;received=192.168.171.45;branch=z9hG4bK0e577af907ee5c96;rport=57740 To: “Juha” sip:jh@test.tutpro.com;tag=ba0ce8c5ff52514a From: sip:test@test.tutpro.com;tag=3f5ae913f10827cf Call-ID: 9072f4d9d47cb03d CSeq: 16365 INVITE Server: baresip v3.6.0 (x86_64/Linux) Contact: sip:jh@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce Content-Type: application/sdp Content-Length: 437

v=0 o=- 2379850820 1099638974 IN IP4 192.168.171.45 s=- c=IN IP4 192.168.171.45 t=0 0 m=audio 1062 RTP/AVP 96 97 0 8 101 9 a=rtpmap:96 AMR-WB/16000 a=rtpmap:97 AMR/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=rtpmap:9 G722/8000 a=recvonly a=rtcp-rsize a=ssrc:1760553048 cname:sip:jh@test.tutpro.com a=minptime:20 a=ptime:20 a=label:1 a=mid:0 m=video 0 RTP/AVP 0

Then I build re and baresip using main, made the same test and test sent ACK after receiving 200 OK to re-INVITE.

Let me know if you need something else.

juha-h on Oct 23, 2023

PR for ACK unit test is fine now: https://github.com/baresip/baresip/pull/2775 The issue can not be reproduced. We need more details.

cspiel1 on Oct 23, 2023

@juha-h Please read my comment carefully. Without any forking, this is not reproducible.

I use parallel forking in my SIPP scenario.

I’m trying to help here and I asked you to show your SIP messages in detail. If you don’t provide details, this will be very difficult.

A re-INVITE test already exists in BareSIP as test_call_change_videodir and @cspiel1 just confirmed in the test that ACKs are sent correctly for non-forking calls.

maximilianfridrich on Oct 23, 2023