[OpenSIPS-Users] Questions about initial setup

Brett Nemeroff brett at nemeroff.com
Sat May 24 08:58:08 CEST 2014 

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 <kheimerl at endaga.com>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 <brett at nemeroff.com>wrote:
>
>> Well the thing is.. if you are a registrar and users are registering to
>> your domain name like 1234 at domain.com.. 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 <kheimerl at endaga.com>wrote:
>>
>>> Getting back on this horse, what do you mean "alias setup". There seem
>>> to be two different aliases: one for users (x at y -> 1000 at 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 <brett at nemeroff.com>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 <kheimerl at endaga.com>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 <brett at 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 <kheimerl at 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 at lists.opensips.org
>>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Users mailing list
>>>>>> Users at lists.opensips.org
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org
>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Users mailing list
>>>> Users at lists.opensips.org
>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140524/595ddca2/attachment-0001.htm>

More information about the Users mailing list