This makes *a lot* of sense. Thanks!I expected the SIP REGISTER to be terminated at the instance rather than forwarded as I had that user/pw combo in the subscribers table. I assume it doesn't do that by default I have to add a command to the routing logic to do that? Or, architecturally, should I just forward that request anyhow?
Thanks! On Thu, May 15, 2014 at 2:11 AM, Brett Nemeroff <br...@nemeroff.com> wrote: > Normally this means that you haven't actually done anything with the call, > but you are t_relaying it out. > > In other words, the RURI was destined for your opensips box.. That's how > it got there.. it hit opensips, then you sent it back out.. But you never > adjusted the RURI to point to the next hop by either changing the request > user part or domain part. So it sends it back to itself (loopback) until > Max-Forwards expires and returns the 483. > > If you remove the 483 check, you get a massive loop on the loopback > interface until you start to kill server resources, which gave you the 408. > > Be sure you are actually doing some change to the message before you send > it back out. Try to xlog the r-uri before you t_relay() like this: > > xlog("L_INFO","Sending call out to $ru"); > > If you watch sip traffic on your loopback interface, you'll see what all > the madness is about.. I don't really recommend it, since it very quickly > will consume your terminal, but you'll at least understand what exactly is > happening.. > > Good luck! > -Brett > > > > On Wed, May 14, 2014 at 8:36 PM, Kurtis Heimerl <kheim...@endaga.com>wrote: > >> Hey Users, >> >> I'm a developer with a lot of experience in FreeSWITCH trying out >> OpenSIPS for a larger, more central piece of infrastructure. I started >> investigating it a few days ago with the following use case in mind: >> >> FS instance with users attached. >> OpenSIPS in the cloud routing the FS communications to another cloud >> provider (e.g., Twilio). >> >> I've got FS set up with our OpenSIPS box as an external provider and a >> set username and password. That seems to be working. I set up OpenSIPS from >> the opensips APT repository (http://apt.opensips.org/) and version 11.1. >> It's running, configured with TEXTDB, and I inserted the username and >> password (after modifying the DB schema to allow null emails, which I guess >> is an ancient bug... http://sourceforge.net/p/openser/bugs/593/). >> >> The registration from FS is being rejected as a 483 "Too many hops" This >> is strange. I removed the 483 check in the opensips cfg and now it's a 408 >> Timeout. OpenSIPS itself it complaining in the following way. The actual >> log is also available, but too large for the mailing list. >> >> May 15 01:27:34 [26230] WARNING:core:fm_malloc: Not enough free memory, >> will atempt defragmentation >> May 15 01:27:34 [26230] ERROR:tm:relay_reply: no more share memory >> May 15 01:27:34 [26230] WARNING:core:fm_malloc: Not enough free memory, >> will atempt defragmentation >> May 15 01:27:34 [26230] ERROR:tm:_reply_light: failed to allocate shmem >> buffer >> >> Googling this error brings up a few hits on issues with a memory leak, >> but that can't be the case here as it is just started. >> >> Ideas? What am I doing wrong? Is this is right use case for OpenSIPS >> anyhow? >> >> Thanks! >> >> _______________________________________________ >> Users mailing list >> Users@lists.opensips.org >> http://lists.opensips.org/cgi-bin/mailman/listinfo/users >> >> > > _______________________________________________ > Users mailing list > Users@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/users > >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users