[OpenSIPS-Users] B2b module topology hiding
Anca Vamanu
anca at opensips.org
Wed May 26 11:53:55 CEST 2010
Hi Douglas,
First there is an important thing that you misunderstood: if you call
the B2B topology hiding on a request, that request should be dropped
after not sent on the other side. The B2BUA will generate a completely
new request with the information from the first one but putting itself
as the Contact and not including the route headers. This request will be
routed according to the information in RURI and if it points to the same
machine, you will receive this message in the script. You can apply
different routing logic by checking if src_ip and src_port equal the ip
and port of the machine.
Regards,
--
Anca Vamanu
www.voice-system.ro
Douglas Lane wrote:
> 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
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
More information about the Users
mailing list