[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:[email protected]: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:[email protected]:50600 SIP/2.0
Via: SIP/2.0/UDP 172.28.128.1:5060;branch=z9hG4bK80d7e96fc5a1ef11bf692e066dce02e3;rport
From: "PhonerLite" <sip:[email protected]>;tag=3364579678
To: <sip:[email protected]:50600>
Call-ID: [email protected]
CSeq: 1 INVITE
Contact: <sip:[email protected]>
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:[email protected]>
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:[email protected]>;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: [email protected]
Contact: <sip:[email protected]>

---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:[email protected]:50600>
From: <sip:[email protected]>;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: [email protected]
Contact: <sip:[email protected]>

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]

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

[denyspozniak]

I may be wrong, but I don't see anything corrupted - it's the same To header that was received.
Not sure what is the "fix" you are expecting.

@razvancrainea then I'm a bit confused about the meaning of this b2b_bridge_retry() function if it exposes a topology that negates the idea of SBC.
I would like to see the retried call structured in the same way as the first one.
The required functionality may be outside your vision, so it's worth stating that in the function description.

Anyway, thanks for the B2B module, I'm happy it's evolving and looks production-ready.

[github-actions]

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.