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
