[OpenSIPS-Users] B2b module topology hiding

[Douglas Lane]

Hi All,

I've decided to embark on a new little project, and that is turning 
opensips into a very basic sbc-type function. The architecture is simple:

UAC ------------- (public internet) ------> OpenSIPS SBC -------- 
(private network) -------> OpenSIPS Router ----------> Asterisk ------> PSTN

The concept here is to have the OpenSIPS SBC to act as a registrar and 
initial auth server (so this system will handle the Proxy Auth process). 
Once the auth is successful, the idea is then to push the request 
through the B2B module and relay it onto the OpenSIPS Router server, 
which will handle any possible rewrites to the SIP messages before 
sending the call to an Asterisk box for termination.

The reason to use the B2B module is to hide the topology (like a SBC does).

Now I've got a functional route logic programmed on both systems, and if 
I remove the b2b stuff, the calls go through correctly. When I add in 
the b2b stuff accordingly, After the b2b module is started, the OpenSIPS 
SBC box sends an invite to itself on its public interface. The initial 
invite from the UAC passes down to the Router and finally onto the 
Asterisk box correctly, but the SBC gets a bit confused with all these 
invites coming into itself from itself.

I was wondering if anyone has a working example of an architecture 
similar to the above, or could point me in the right direction. What I 
have noticed is the following just below before we get an invite from 
ourselves:

May 25 20:22:20 [2268] DBG:b2b_entities:client_new: generated tag = 
[NmZlZDUxNjM1ZjMwNzg2N2JjMjllZjYwZTUyN2UyYzE.7d70bc67]
May 25 20:22:20 [2268] DBG:tm:t_uac: 
next_hop=<sip:0716054314 at dev.mydomain.com>
May 25 20:22:20 [2268] DBG:core:mk_proxy: doing DNS lookup...
May 25 20:22:20 [2268] DBG:core:sip_resolvehost: no port, no proto -> do 
NAPTR lookup!
May 25 20:22:20 [2268] DBG:core:get_record: lookup(dev.mydomain.com, 35) 
failed
May 25 20:22:20 [2268] DBG:core:sip_resolvehost: no valid NAPTR record 
found for dev.mydomain.com trying direct SRV lookup...
May 25 20:22:20 [2268] DBG:core:do_srv_lookup: 
SRV(_sip._udp.dev.mydomain.com) = sbc1.dev.mydomain.com:5060
May 25 20:22:20 [2268] DBG:core:get_out_socket: socket determined: 0x7912f8
May 25 20:22:20 [2268] DBG:tm:dlg2hash: 42135
May 25 20:22:20 [2268] DBG:tm:print_request_uri: 
sip:0716054314 at dev.mydomain.com
May 25 20:22:20 [2268] DBG:tm:t_uac: REF_UNSAFE: after is 1
May 25 20:22:20 [2268] DBG:tm:set_timer: relative timeout is 500000
May 25 20:22:20 [2268] DBG:tm:insert_timer_unsafe: [4]: 0x7faf39600988 
(12600000)
May 25 20:22:20 [2268] DBG:tm:set_timer: relative timeout is 30
May 25 20:22:20 [2268] DBG:tm:insert_timer_unsafe: [0]: 0x7faf396009b8 (42)
May 25 20:22:20 [2268] DBG:b2b_logic:b2bl_create_new_entity: address: 
0x7faf396022d0

It looks like the b2b module initiates a lookup on the domain and then 
I'd assume sends the invite to itself as sbc1.dev.mydomain.com points to 
the SBC's public IP address.

And then directly after the above, my script kicks in:

[SBC] Setting the on_reply and failure route settings
[SBC] Sending the request to the core
Request leaving server, D-URI='sip:172.20.0.21:5060' - M=INVITE 
RURI=sip:0716054314 at dev.mydomain.com F=sip:doug at dev.mydomain.com 
T=sip:0716054314 at dev.mydomain.com IP=1.2.3.4 
ID=NmZlZDUxNjM1ZjMwNzg2N2JjMjllZjYwZTUyN2UyYzE.

Any suggestions?

This is what my route logic looks like after the INVITE has been 
processed (proxy auth):

route[CORE]
{
         ds_select_dst("2", "0");
         xlog("L_INFO", "[SBC] Destintion URI now set to $du\n");

         xlog("L_INFO", "[SBC] Calling b2b module with topology hiding\n");
         b2b_init_request("top hiding");

         xlog("L_INFO", "[SBC] Setting the on_reply and failure route 
settings\n");
         t_on_reply("1");
         t_on_failure("1");

         xlog("L_INFO", "[SBC] Sending the request to the core\n");
         xlog("L_INFO", "Request leaving server, D-URI='$du' - M=$rm 
RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n");
         if(!t_relay("0x05"))
         {
                 sl_reply_error();
         }
         exit;
}

I also tried using forward() instead of t_relay(), but both seem to have 
the same affect.

As always, your assistance is greatly appreciated.

Thanks
Doug