[OpenSIPS-Users] B2BUA, authenticated INVITEs with "ACK for a negative reply"

Nathan Ward opensips-list at daork.net
Sat Nov 26 05:04:03 CET 2016


Hi all,

I am configuring an SBC with 3 legs - one to the core (i.e. to a registrar and routing server), one towards end users, and one towards a provider.
My intent is to make he SBC fairly “dumb”, and not keep state of registrations etc.

The provider requires registration and authentication for calls. I generate registrations from our core towards our provider for each line, through the SBC (forwarding these rather than B2BUA-ing). I also have users registering towards our core. Works great.

When we forward an INVITE from our core, the B2BUA creates a new session and forwards it to the provider. The provider challenges (401), which is forwarded back towards the core. The core ACKs this challenge, and forwards the ACK to the provider. Then, the B2BUA deletes the dialog after saying "ACK for a negative reply”.

This means that the subsequent authenticated INVITE generates a new instance on the B2BUA, and a new Call-ID - which causes the provider to reject this as the Call-ID is expected to be consistent across auth/unauth INVITEs.

Worth noting that before we call b2b_init_request, I call “force_send_socket”, as we use loopback/virtual addresses for talking with our provider.

- Is this expected behaviour?
- Is there a way to tweak this so that ACK for a 401/407/etc. does not immediately tear down the B2BUA entity?
- Can I avoid this by writing my own B2BUA scenario? We are using the built in “top hiding” for the moment.

If code is required to permit this model I’m happy to work on this, but before I get my hands dirty I thought I’d ask around :-)


We have the same behaviour from User->B2BUA->Core - however for the moment our Core doesn’t care about differing Call-ID, which is obviously a problem that I’ll be looking at next..!

--
Nathan Ward




More information about the Users mailing list