[FEATURE] b2b_bridge_retry() brakes SIP headers

[denyspozniak]

Hello!

In the example below, when doing serial call forking b2b_bridge_retry() brakes SIP header in B2-leg (sip:102@pbx):

• To header (from original A-leg)
• From display (completely missing)
• Contact (it's not clear where from)

A-leg (sip:bob@172.28.28.28:50600) --> B1-leg (101@pbx)
                                                            --> B2-leg (102@pbx)

If you need help with reproducing or need logs/pcap traces, I can send privately.

route{
  if ( is_method("INVITE") && !has_totag() ) {
    b2b_client_new("dst1", "sip:101@pbx");
    b2b_server_new("src1");
    b2b_init_request("sbc");
    exit;
  }
}

route[b2b_logic_reply] {
    if ( $rm == "INVITE" && $rs == 403 ) {
        b2b_client_new("dst2", "sip:102@pbx");
        b2b_bridge_retry("dst2");
    }
}

SIP INVITE

---INCOMING A-leg:
INVITE sip:bob@172.28.28.28:50600 SIP/2.0
Via: SIP/2.0/UDP 172.28.128.1:5060;branch=z9hG4bK80d7e96fc5a1ef11bf692e066dce02e3;rport
From: "PhonerLite" <sip:phonerlite@172.28.28.28>;tag=3364579678
To: <sip:bob@172.28.28.28:50600>
Call-ID: 80D7E96F-C5A1-EF11-BF68-2E066DCE02E3@172.28.128.1
CSeq: 1 INVITE
Contact: <sip:phonerlite@172.28.128.1>
Content-Type: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
Max-Forwards: 70
Supported: replaces, from-change, 100rel
User-Agent: PhonerLite/3.26
P-Preferred-Identity: <sip:phonerlite@172.28.28.28>
Content-Length:   373

---OUTGOING B1-leg:
INVITE sip:101@pbx SIP/2.0
Via: SIP/2.0/UDP 192.168.56.181:5060;branch=z9hG4bK04c.b2dad6b6.0
To: <sip:101@pbx>
From: "PhonerLite" <sip:phonerlite@172.28.28.28>;tag=6ac03514de7b804f3828ecc535d25839-a3a5
CSeq: 2 INVITE
Call-ID: .201.7518725.1731678282.1420985851
Max-Forwards: 69
Content-Length: 373
User-Agent: OpenSIPS (3.5.2 (x86_64/linux))
Content-Type: application/sdp
Supported: replaces, from-change, 100rel
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
X-CallID: 80D7E96F-C5A1-EF11-BF68-2E066DCE02E3@172.28.128.1
Contact: <sip:phonerlite@172.18.0.2>

---OUTGOING B2-leg:
INVITE sip:102@pbx SIP/2.0
Via: SIP/2.0/UDP 192.168.56.181:5060;branch=z9hG4bK1029.925e8a76.0
To: <sip:bob@172.28.28.28:50600>
From: <sip:phonerlite@172.28.28.28>;tag=36d52ec24f434cecf68e6c41b2db31a9-a3a5
CSeq: 2 INVITE
Call-ID: .64.1873052.1731678284.1474255093
Max-Forwards: 69
Content-Length: 373
User-Agent: OpenSIPS (3.5.2 (x86_64/linux))
Content-Type: application/sdp
Supported: replaces, from-change, 100rel
Allow: INVITE, ACK, BYE, CANCEL, INFO, MESSAGE, NOTIFY, OPTIONS, REFER, UPDATE, PRACK
X-CallID: 80D7E96F-C5A1-EF11-BF68-2E066DCE02E3@172.28.128.1
Contact: <sip:bob@172.18.0.2>

opensips -V

version: opensips 3.5.2 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll, sigio_rt, select.
git revision: 8a183b0c0
main.c compiled on  with gcc 9

[github-actions[bot]]

Any updates here? No progress has been made in the last 15 days, marking as stale. Will close this issue if no further updates are made in the next 30 days.

[razvancrainea]

I don't see something broken, it's just different... That's because the function uses some defaults that you are not expecting, and it does not inherit them throughout the branches. If you would like to enforce From display name and Contact, make sure you are explicit about the 4th and 5th parameters of the b2b_client_new function.

Best regards, Răzvan

[denyspozniak]

@razvancrainea but if you look at the log above (B2-leg), there is also a "corrupted" To header. How can this be fixed?

[razvancrainea]

I may be wrong, but I don't see anything corrupted - it's the same To header that was received.

[razvancrainea]

Not sure what is the "fix" you are expecting.

[denyspozniak]

I may be wrong, but I don't see anything corrupted - it's the same To header that was received.

I would expect the B2-leg to have the To header modified as it happened in the B1-leg