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:[email protected]> 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:[email protected] 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:[email protected] F=sip:[email protected] T=sip:[email protected] 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 [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
