baresip keeps re-sending 200 Answering after receiving ACK #3028

juha-h · 2024-05-16T13:38:34Z

juha-h
May 16, 2024
Maintainer

Can someone figure out why in below baresip keeps on re-sending 200 Answering after it has received ACK? ACK URI is the same as Contact URI of 200 response and also Call-IDs, To and From tags match. Why is the call not established?

16:15:22.416#
TCP 192.168.80.215:5060 -> 192.168.80.215:43708
INVITE sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce SIP/2.0
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
To: <sip:test@test.tutpro.com>
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
CSeq: 1 INVITE
Call-ID: 664606ea65838@test.tutpro.com
Max-Forwards: 70
Content-Length: 131
User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux))
Contact: <sip:click2dial@192.168.80.215:5060>
Content-Type: application/sdp

v=0
o=click-to-dial 0 0 IN IP4 0.0.0.0
s=session
c=IN IP4 0.0.0.0
b=CT:1000
t=0 0
m=audio 9 RTP/AVP 0
a=rtpmap:0 PCMU/8000

ua: sipsess connect via TCP 192.168.80.215:5060 --> 192.168.80.215:43708
test@test.tutpro.com: account match for test
ua: using connection-address 0.0.0.0 of SDP offer
call: alloc with params laddr=?, af=AF_INET, use_rtp=1
call: use_video=1

16:15:22.416#
TCP 192.168.80.215:43708 -> 192.168.80.215:5060
SIP/2.0 180 Ringing
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
To: <sip:test@test.tutpro.com>;tag=9e08861de321af9d
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
CSeq: 1 INVITE
Call-ID: 664606ea65838@test.tutpro.com
Server: baresip v3.11.0 (x86_64/Linux)
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,REFER
Content-Length: 0

sip:test@test.tutpro.com: Incoming call from:  sip:click2dial@test.tutpro.com - audio-video: sendrecv-inactive - (press 'a' to accept)
alsa: reset: srate=8000, ch=1, num_frames=320, pcmfmt=S16_LE
alsa: playback started (default)
presence: ua=0x557214c9fa70 got event 10 (CALL_INCOMING)
alsa: stopping playback thread (default)
call: answering call on line 1 from sip:click2dial@test.tutpro.com with 200
stream: update 'audio'
stream: disable audio RTP receiver
stream: disable audio RTP sender
stream: enable audio RTP receiver
stream: update 'video'
stream: disable video RTP receiver
stream: disable video RTP sender
stream: enable video RTP receiver
presence: ua=0x557214c9fa70 got event 28 (CALL_LOCAL_SDP)

16:15:27.605#
TCP 192.168.80.215:43708 -> 192.168.80.215:5060
SIP/2.0 200 Answering
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
To: <sip:test@test.tutpro.com>;tag=9e08861de321af9d
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
CSeq: 1 INVITE
Call-ID: 664606ea65838@test.tutpro.com
Server: baresip v3.11.0 (x86_64/Linux)
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,REFER
Supported: gruu,path,outbound,replaces,norefersub
Content-Type: application/sdp
Content-Length: 212

v=0
o=- 3966051803 1648392487 IN IP6 ?
s=-
c=IN IP6 ?
t=0 0
m=audio 22582 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=ssrc:4276972270 cname:sip:test@test.tutpro.com
a=minptime:20
a=ptime:20
a=label:1

16:15:27.606#
TCP 192.168.80.215:5060 -> 192.168.80.215:43708
ACK sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce SIP/2.0
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
Call-ID: 664606ea65838@test.tutpro.com
To: <sip:test@test.tutpro.com>;tag=9e08861de321af9d
CSeq: 1 ACK
User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux))
Content-Length: 0

... other requests/responses

16:15:29.107#
TCP 192.168.80.215:43708 -> 192.168.80.215:5060
SIP/2.0 200 Answering
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
To: <sip:test@test.tutpro.com>;tag=9e08861de321af9d
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
CSeq: 1 INVITE
Call-ID: 664606ea65838@test.tutpro.com
Server: baresip v3.11.0 (x86_64/Linux)
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,REFER
Supported: gruu,path,outbound,replaces,norefersub
Content-Type: application/sdp
Content-Length: 212

v=0
o=- 3966051803 1648392487 IN IP6 ?
s=-
c=IN IP6 ?
t=0 0
m=audio 22582 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=ssrc:4276972270 cname:sip:test@test.tutpro.com
a=minptime:20
a=ptime:20
a=label:1

16:15:31.107#
TCP 192.168.80.215:43708 -> 192.168.80.215:5060
SIP/2.0 200 Answering
Via: SIP/2.0/TCP 192.168.80.215;branch=z9hG4bKaad.e70b6ae7000000000000000000000000.0
To: <sip:test@test.tutpro.com>;tag=9e08861de321af9d
From: <sip:click2dial@test.tutpro.com>;tag=0314d28d9107d990420d02e8ee696485-6a4090c4
CSeq: 1 INVITE
Call-ID: 664606ea65838@test.tutpro.com
Server: baresip v3.11.0 (x86_64/Linux)
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,REFER
Supported: gruu,path,outbound,replaces,norefersub
Content-Type: application/sdp
Content-Length: 212

v=0
o=- 3966051803 1648392487 IN IP6 ?
s=-
c=IN IP6 ?
t=0 0
m=audio 22582 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=sendrecv
a=ssrc:4276972270 cname:sip:test@test.tutpro.com
a=minptime:20
a=ptime:20
a=label:1

... and so on

juha-h · 2024-05-16T18:55:53Z

juha-h
May 16, 2024
Maintainer Author

I'm also wondering if question marks in the SDP of 200 Answering are syntactically valid:

o=- 3966051803 1648392487 IN IP6 ?
s=-
c=IN IP6 ?

1 reply

sreimers May 16, 2024
Maintainer

o=- 3966051803 1648392487 IN IP6 ?
s=-
c=IN IP6 ?

Looks like sess->laddr within sdp_encode is invalid/empty. How does /netstat command output look like?

juha-h · 2024-05-17T05:45:43Z

juha-h
May 17, 2024
Maintainer Author

Here is /netsta. IP addresses of the device changed from yesterday, but I made a new test and SDP in 200 is still the same.

/netstat
--- Network debug ---
enabled interfaces:
  wlp0s20f3:  192.168.187.215 (default)
  wlp0s20f3:  2001:14bb:a8:77c5:14d4:756f:5105:4cf7 (default)
  wlp0s20f3:  2001:14bb:a8:77c5:e9a:3cff:fe6b:387 
  wlp0s20f3:  fe80::e9a:3cff:fe6b:387 
 DNS Servers from System: (2)
   0: 192.168.187.162:53
   1: [2001:14bb:a8:77c5::9b]:53

0 replies

juha-h · 2024-05-17T06:16:03Z

juha-h
May 17, 2024
Maintainer Author

This is click2dial test. User clicks a SIP URI link on web page that causes my SIP proxy to send INVITE without media. After getting 200 and sending ACK, SIP proxy sends REFER and closes the call. INVITE is send first because many SIP UAs do not accept out-of-dialog REFERs.

0 replies

juha-h · 2024-05-17T06:42:58Z

juha-h
May 17, 2024
Maintainer Author

This starts to look like a bug in baresip. I made the same test with pjsua and everything worked OK. SDP in 200 OK looks fine and there are no re-transmissions of it.

Here are the messages:

INVITE sip:jh@192.168.187.215:42039;transport=TCP;ob
100 Trying
200 OK
ACK sip:jh@192.168.187.215:42039;transport=TCP;ob
REFER sip:jh@192.168.187.215:42039;transport=TCP;ob
202 Accepted
BYE sip:jh@192.168.187.215:42039;transport=TCP;ob
200 OK

And here are the details of INVITE, 200 OK, and ACK:

NVITE sip:jh@192.168.187.215:42039;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP 192.168.187.215;branch=z9hG4bK601.046ef507000000000000000000000000.0
To: <sip:jh@test.tutpro.com>
From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-2506db73
CSeq: 1 INVITE
Call-ID: 6646f924ad1cf@test.tutpro.com
Max-Forwards: 70
Content-Length: 131
User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux))
Contact: <sip:click2dial@192.168.187.215:5060>
Content-Type: application/sdp

v=0
o=click-to-dial 0 0 IN IP4 0.0.0.0
s=session
c=IN IP4 0.0.0.0
b=CT:1000
t=0 0
m=audio 9 RTP/AVP 0
a=rtpmap:0 PCMU/8000

SIP/2.0 200 OK
Via: SIP/2.0/TCP 192.168.187.215;received=192.168.187.215;branch=z9hG4bK601.046ef507000000000000000000000000.0
Call-ID: 6646f924ad1cf@test.tutpro.com
From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-2506db73
To: <sip:jh@test.tutpro.com>;tag=3de52a80-5fb0-433e-884f-d499fc9f3518
CSeq: 1 INVITE
Contact: <sip:jh@192.168.187.215:42039;transport=TCP;ob>
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS
Supported: replaces, 100rel, timer, norefersub
Content-Type: application/sdp
Content-Length: 269

v=0
o=- 3924916132 3924916133 IN IP4 192.168.187.215
s=pjmedia
b=AS:117
t=0 0
a=X-nat:0
m=audio 4002 RTP/AVP 0
c=IN IP4 192.168.187.215
b=TIAS:96000
a=rtcp:4003 IN IP4 192.168.187.215
a=sendrecv
a=rtpmap:0 PCMU/8000
a=ssrc:771274625 cname:347843b75d9b8de3

ACK sip:jh@192.168.187.215:42039;transport=TCP;ob SIP/2.0
Via: SIP/2.0/TCP 192.168.187.215;branch=z9hG4bK601.046ef507000000000000000000000000.0
From: <sip:click2dial@test.tutpro.com>;tag=2dd3d4389fe3d66c5cb97dc370ab7d7b-2506db73
Call-ID: 6646f924ad1cf@test.tutpro.com
To: <sip:jh@test.tutpro.com>;tag=3de52a80-5fb0-433e-884f-d499fc9f3518
CSeq: 1 ACK
User-Agent: OpenSIPg SIP Proxy (5.9.0-0b01 (x86_64/linux))
Content-Length: 0

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

baresip keeps re-sending 200 Answering after receiving ACK #3028

{{title}}

Replies: 4 comments 1 reply

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

Select a reply

baresip keeps re-sending 200 Answering after receiving ACK #3028

juha-h May 16, 2024 Maintainer

Replies: 4 comments · 1 reply

juha-h May 16, 2024 Maintainer Author

sreimers May 16, 2024 Maintainer

juha-h May 17, 2024 Maintainer Author

juha-h May 17, 2024 Maintainer Author

juha-h May 17, 2024 Maintainer Author

juha-h
May 16, 2024
Maintainer

Replies: 4 comments 1 reply

juha-h
May 16, 2024
Maintainer Author

sreimers May 16, 2024
Maintainer

juha-h
May 17, 2024
Maintainer Author

juha-h
May 17, 2024
Maintainer Author

juha-h
May 17, 2024
Maintainer Author