[OpenSIPS-Users] Trouble with forked calls and rtpengine

[Robert Dyck]

Opensips adds its via ( with branch info ) after script processing but before 
forwarding. Opensips branch info is not available to the script when 
processing an INVITE. I have attached some text of an INVITE with rtpengine 
and with "offer via-branch=1". What rtpengine receives is the branch parameter 
added by the upstream node. The upstream node has no knowledge of any forking 
that may occur after lookup.

The branch parameter is a legacy of rfc2543. That rfc stated that a forking 
proxy would add branch info in a via parameter called branch. This parameter 
could be added by any hop but is ignored. It was only meaningful in a response 
received by the forking proxy.

Rfc3261 retained the via parameter name, I assume for compatibility. Rfc3261 
was clear however that "branch" was now a transaction ID. This is only of 
interest to the node that added it in a request. Now in the case of a forking 
proxy the branch parameter has the dual role of being a transaction ID and a 
branch ID. Opensips does this by adding the branch index as a suffix to the 
transaction ID.

The opensips script may not have access to the eventual transaction ID but the 
branch index is available. Passing the branch index to rtpengine causes it to 
create a different profile for each branch rather than stacking the profiles. 
That stacking was causing trouble for me.

When rtpengine is simply providing a public address to relay media the 
stacking does not appear to have any consequence. However when mixing WEBRTC 
and non-WEBRTC stacking the profiles in a single entry in rtpengine gives 
inconsistent results.

On Thursday, January 27, 2022 3:57:07 A.M. PST Răzvan Crainea wrote:
> Hi, Robert!
> 
> Are you sure that via-branch=2 does not set different branches, and sets
> the same param as via-branch=1?
> If you are going to use the extra_id_pv, you should make sure that you
> persist it over dialog, i.e. also provide it during sequential
> offer/answer/delete commands.
> 
> Best regards,
> 
-------------- next part --------------
 INVITE sip:2 at 192.168.1.2 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.87:38268;branch=z9hG4bK24749ef66a21e2fd;rport
Contact: <sip:4-0x55f10603af00 at 192.168.1.87:38268>
Max-Forwards: 70
Proxy-Authorization: Digest username="4", realm="192.168.1.2", nonce="jzLa4gxOll83BD3v0WKZclEjjHyaJpxfmIWTVMw8WXcA", uri="sip:2 at 192.168.1.2", response="697304535675ddab4c8fec180eef338a", cnonce="fe5ab4853d24b69e", qop=auth, nc=00000001, algorithm=MD5
To: <sip:2 at 192.168.1.2>
From: <sip:4 at 192.168.1.2>;tag=a331187bbb05d5eb
Call-ID: 2a211cae7d8a4ec3
CSeq: 56918 INVITE
User-Agent: baresip v1.1.0 (x86_64/linux)
Allow: INVITE,ACK,BYE,CANCEL,OPTIONS,NOTIFY,SUBSCRIBE,INFO,MESSAGE,REFER
Supported: gruu
Content-Type: application/sdp
Content-Length: 433


xlog
Jan 27 08:24:27 [2683481] Invite with first via host 192.168.1.87 and branch ID z9hG4bK24749ef66a21e2fd

xlog
Jan 27 08:24:27 [2683481] profile is  debug via-branch=1 SDES-off ICE=force UDP/TLS/RTP/SAVPF replace-session-connection replace-origin DTLS-fingerprint=sha-256 rtcp-mux-require generate-mid

>From rtpengine log
Jan 27 08:24:27 slim rtpengine[1623448]: DEBUG: [2a211cae7d8a4ec3]: ... : "force", "DTLS-fingerprint": "sha-256", "direction": [ "ipv4-priv", "ipv6" ], "flags": [ "debug", "SDES-off", "generate-mid" ], "replace": [ "session-connection", "origin" ], "transport-protocol": "UDP/TLS/RTP/SAVPF", "rtcp-mux": [ "require" ], "call-id": "2a211cae7d8a4ec3", "via-branch": "z9hG4bK24749ef66a21e2fd", "received-from": [ "IP4", "192.168.1.87" ], "from-tag": "a331187bbb05d5eb", "command": "offer" }