[OpenSIPS-Users] Questions about initial setup

[Kurtis Heimerl]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20140523/2bfc83cd/attachment.htm>