Just wanted say that the "alias=" line worked perfectly. Thanks so much for your help brett.
On Fri, May 23, 2014 at 11:58 PM, Brett Nemeroff <[email protected]> wrote: > Try just: > > alias=domain.com > > http://www.opensips.org/Documentation/Script-CoreParameters-1-9#toc26 > > Note that there are some tricks you normally have to do to make EC2 work. > You are not learning the easy way :) > > Check out this thread for some pointers: > http://lists.opensips.org/pipermail/users/2010-April/012367.html > > > > On Sat, May 24, 2014 at 12:45 AM, Kurtis Heimerl <[email protected]> > wrote: > >> This totally makes sense! Thanks so much. Due to the intricacies of our >> design (ec2 in action) the automatic alias detection isn't working (it gets >> the name from the local DNS which isn't routable externally). How do I get >> it to know that "myself" is a certain domain name? I set SIP_DOMAIN in the >> configuration, that didn't seem to change anything. >> >> Thanks again! >> >> >> On Fri, May 23, 2014 at 9:59 PM, Brett Nemeroff <[email protected]> >> wrote: >> >>> Well the thing is.. if you are a registrar and users are registering to >>> your domain name like [email protected].. Then your server needs to know >>> it is domain.com else when it hits this block (if you kept it from the >>> examples): >>> >>> if (!uri==myself) { >>> append_hf("P-hint: outbound\r\n"); >>> route(relay); >>> } >>> >>> The call will attempt to be relayed.. and if the domain IS actually >>> pointing to yourself.. well SURPRISE, you have a loop again. >>> >>> so "myself" means that the domain IS a valid alias.. >>> >>> (this is the short answer) >>> >>> Remember, the LISTEN is what IP it'll get packets on.. regardless of >>> domain name.. used in the signaling. >>> -Brett >>> >>> >>> >>> On Fri, May 23, 2014 at 8:07 PM, Kurtis Heimerl <[email protected]> >>> wrote: >>> >>>> Getting back on this horse, what do you mean "alias setup". There seem >>>> to be two different aliases: one for users (x@y -> 1000@foo) and one >>>> for the service itself: >>>> >>>> Restarting opensips: opensipsListening on >>>> udp: 192.168.0.0.1 [192.168.0.0.1]:5060 >>>> Aliases: >>>> udp: x.y.server.name:5060 >>>> >>>> Which of these need to be configured for the server to work as a >>>> registrar? The former seems easy enough, but doesn't make a lot of sense >>>> architecturally. The second makes a lot more sense, but I can't find how to >>>> add another alias (that one is auto detected). >>>> >>>> Thanks again! >>>> >>>> >>>> On Thu, May 15, 2014 at 11:41 AM, Brett Nemeroff <[email protected]> >>>> wrote: >>>> >>>>> So OpenSIPs doesn't do anything on it's own. If you just downloaded, >>>>> and compiled... I can say with like 99% certainty it's not going to do >>>>> what >>>>> you want. It's just a toolkit. >>>>> >>>>> For example, if your config doesn't explicitly check the register to >>>>> see if it's valid, it's not doing it. >>>>> >>>>> The sample config i think has some of these bits littered around it.. >>>>> Maybe you don't have your alias setup right in which case it would try to >>>>> relay it. >>>>> >>>>> >>>>> On Thu, May 15, 2014 at 12:46 PM, Kurtis Heimerl <[email protected]> >>>>> wrote: >>>>> >>>>>> 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 <[email protected]> >>>>>> 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 <[email protected] >>>>>>> > 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 >>>>>>>> [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 >>>>>>> >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> _______________________________________________ >> 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 > >
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
