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:[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 _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
