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
