[OpenSIPS-Users] B2b module topology hiding

Tue May 25 20:58:53 CEST 2010

Hi Jeff,

Many thanks for the reply.

I'm using dispatcher to select a OpenSIPS Router server (currently only 
one in the list).

So my first call is

ds_select_dst("2", "0");

Which will find one of the router servers and then:

xlog("L_INFO", "[SBC] Destintion URI now set to $du and detination 
domain is set to $du\n");
b2b_init_request("top hiding");

And the xlog output looks like this:

[SBC] Destintion URI now set to sip:172.20.0.21:5060 and detination 
domain is set to sip:172.20.0.21:5060

So I'm confused - or perhaps I've done something wrong again.

Thanks
Doug

On 2010/05/25 8:45 PM, Jeff Pyle wrote:
> Doug,
>
> It sounds like the request domain is the same when you call b2b_init as it does when it enters your core route.  You may want to amend your Destination URI xlog to display $rd as well.  Or, perhaps try some testing by manually updating it to see if things improve.
>
>
>
> - Jeff
>
>
> On May 25, 2010, at 2:39 PM, Douglas Lane wrote:
>
>    
>> 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
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>      
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>    