baresip: forked INVITE causes PRACKs to be sent with equal tags

Scenario:

  • UAC jh@test.tutpro.com sends INVITE to test@test.tutpro.com
  • sip proxy forks the INVITE to two registered UASes
  • both UASes response with 180 ringing
  • UAC sends PRACK to both and both PRACKs have equal tags

Issue: second PRACK should have had To tag from the second 180 response, i.e. 149eb80cb71e5a38.

17:11:18.082#
TCP 192.168.238.45:56852 -> 192.168.238.215:5060
INVITE sip:test@test.tutpro.com SIP/2.0
Via: SIP/2.0/TCP 192.168.238.45:46149;branch=z9hG4bKb4f897122cc2f136;rport
Contact: <sip:jh@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce>
Max-Forwards: 70
Route: <sip:siika.tutpro.com:5060;transport=tcp;lr>
To: <sip:test@test.tutpro.com>
From: "Juha" <sip:jh@test.tutpro.com>;tag=3f1a28c9ee7a4304
Call-ID: a30edcfbf0b7559c
CSeq: 51283 INVITE
User-Agent: baresip v2.7.0 (x86_64/linux)
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,PRACK,REFER
Supported: gruu,path,outbound,replaces,100rel
Content-Type: application/sdp
Content-Length: 415

...

17:11:18.162#
TCP 192.168.238.215:5060 -> 192.168.238.45:56852
SIP/2.0 180 Ringing
Record-Route: <sip:192.168.238.215;transport=tcp;lr>
Via: SIP/2.0/TCP 192.168.238.45:46149;received=192.168.238.45;branch=z9hG4bKb4f897122cc2f136;rport=56852
To: <sip:test@test.tutpro.com>;tag=331068bf5177905c
From: "Juha" <sip:jh@test.tutpro.com>;tag=3f1a28c9ee7a4304
Call-ID: a30edcfbf0b7559c
CSeq: 51283 INVITE
Server: baresip v2.7.0 (x86_64/linux)
Contact: <sip:test@test.tutpro.com;gr=urn:uuid:59f2124b-bbf0-06b4-0316-c750c420cdb3>
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,UPDATE,PRACK,REFER
Require: 100rel
RSeq: 22797
Content-Length: 0

call: SIP Progress: 180 Ringing (/)
alsa: reset: srate=8000, ch=1, num_frames=320, pcmfmt=S16_LE
alsa: playback started (default)

17:11:18.255#
TCP 192.168.238.45:56852 -> 192.168.238.215:5060
PRACK sip:test@test.tutpro.com;gr=urn:uuid:59f2124b-bbf0-06b4-0316-c750c420cdb3 SIP/2.0
Via: SIP/2.0/TCP 192.168.238.45:46149;branch=z9hG4bK760fa11d887974b5;rport
Max-Forwards: 70
Route: <sip:192.168.238.215;transport=tcp;lr>
To: <sip:test@test.tutpro.com>;tag=331068bf5177905c
From: "Juha" <sip:jh@test.tutpro.com>;tag=3f1a28c9ee7a4304
Call-ID: a30edcfbf0b7559c
CSeq: 51284 PRACK
User-Agent: baresip v2.7.0 (x86_64/linux)
RAck: 22797 51283 INVITE
Content-Length: 0


17:11:18.255#
TCP 192.168.238.215:5060 -> 192.168.238.45:56852
SIP/2.0 180 Ringing
Record-Route: <sip:192.168.238.215;transport=tcp;lr>
Via: SIP/2.0/TCP 192.168.238.45:46149;received=192.168.238.45;branch=z9hG4bKb4f897122cc2f136;rport=56852
To: <sip:test@test.tutpro.com>;tag=149eb80cb71e5a38
From: "Juha" <sip:jh@test.tutpro.com>;tag=3f1a28c9ee7a4304
Call-ID: a30edcfbf0b7559c
CSeq: 51283 INVITE
Server: baresip v2.7.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,PRACK,REFER
Require: 100rel
RSeq: 26825
Content-Length: 0

call: SIP Progress: 180 Ringing (/)

17:11:18.255#
TCP 192.168.238.45:56852 -> 192.168.238.215:5060
PRACK sip:test@test.tutpro.com;gr=urn:uuid:9b21c1a8-dc58-a3d6-83d5-7be67cbe70ce SIP/2.0
Via: SIP/2.0/TCP 192.168.238.45:46149;branch=z9hG4bKff951fb4505a52e9;rport
Max-Forwards: 70
Route: <sip:192.168.238.215;transport=tcp;lr>
To: <sip:test@test.tutpro.com>;tag=331068bf5177905c
From: "Juha" <sip:jh@test.tutpro.com>;tag=3f1a28c9ee7a4304
Call-ID: a30edcfbf0b7559c
CSeq: 51285 PRACK
User-Agent: baresip v2.7.0 (x86_64/linux)
RAck: 26825 51283 INVITE
Content-Length: 0

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 33 (11 by maintainers)

Most upvoted comments

Thanks, I tried and now PRACKs were sent with correct To tags.

I would like to suggest that “100rel” is by default disabled.

This matches the legacy behaviour. For people that wants to use 100rel they should enable the feature explicitly in the config/account.

I agree with you both. We will think about changing the default behavior to not use 100rel. Then our devices would become a 100rel account parameter set explicitly.

I would suggest adding the feature to the Roadmap and look into it when time permits.

The description should be something like: “Add support for SIP forking”