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, >
INVITE sip:2@192.168.1.2 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.87:38268;branch=z9hG4bK24749ef66a21e2fd;rport Contact: <sip:4-0x55f10603af00@192.168.1.87:38268> Max-Forwards: 70 Proxy-Authorization: Digest username="4", realm="192.168.1.2", nonce="jzLa4gxOll83BD3v0WKZclEjjHyaJpxfmIWTVMw8WXcA", uri="sip:2@192.168.1.2", response="697304535675ddab4c8fec180eef338a", cnonce="fe5ab4853d24b69e", qop=auth, nc=00000001, algorithm=MD5 To: <sip:2@192.168.1.2> From: <sip:4@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" }
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users