[Spce-user] clients having difficulty with domain concept

[Theo]

Hi Walter

Yes that of course could work but we won't have sufficient IP addresses for
that in the long run I reckon.

I have stuck with the prefix which is now working as expected I think.
Rather than bothering the client with prefixing it, I use a rewrite rule to
prefix it with "peer1" or "peer2" etc. That prefix I use in the peering
rules to ensure it selects the correct one, and then strip it again when it
goes out to the peer. I will test it in production but this should do it
then.

Cheers


On Fri, Jan 19, 2018 at 1:43 AM, Walter Klomp <walter at myrepublic.net> wrote:

> Hi Theo,
>
> If “ip addresses” is all you can work with then assign multiple IP
> addresses to the server and use that as authentication.
>
> reseller A - 1.1.1.1
> reseller B - 1.1.1.2
> …etc…
>
> (provided you have enough IP addresses as they are getting scarce...
>
> Regards
> Walter.
>
>
>
> On 19 Jan 2018, at 7:24 AM, Theo <axessofficetheo at gmail.com> wrote:
>
> Apologies, I see I accidentally replied to the posters only. My response
> was:
>
>
>
> The issue is that I have multiple resellers. I can't create that domain
> and assign it to multiple resellers or am I seeing that wrong - so the
> solution of just adding the ip as a domain won't work for that.
>
> Another option would be to create the IP domain (in order to accept
> incoming reqeust), leave the subscriber on the URL-domain and enable the
> "ignore_auth_realm", so the domain is not used in the AUTH process.
>
> I did this and that solves the problem but there is another snatch. Calls
> for various clients have to go out through different peers using remote
> authentication settings in the subscriber. The way those calls are forced
> out over peer x y or z is by using the domain as a pattern. Because the
> domain is not present in the header, it does not select the correct peer
> anymore. I am getting around that for the moment by asking the client to
> prefix their calls and select the peer based on that but that's not ideal.
> What would work is if a peer could be selected based on who the client is.
> Any way of doing that?
>
>
>
> On Thu, Jan 18, 2018 at 4:04 PM, Daniel Grotti <dgrotti at sipwise.com>
> wrote:
>
>> Hi,
>> if they can send request with IP into the URI, then you should add a
>> domain with that IP.
>> You can create those subscribers under that domain.
>>
>> Another option would be to create the IP domain (in order to accept
>> incoming reqeust), leave the subscriber on the URL-domain and enable the
>> "ignore_auth_realm", so the domain is not used in the AUTH process.
>>
>> Daniel
>>
>>
>> On 01/18/2018 02:46 PM, Theo wrote:
>>
>> Hi
>>
>> I have a number of rather large clients who I am wanting to move to our
>> sipwise CE edition. However, they claim they can't use domains - so the
>> header only contains the IP address. I have set them up under trusted
>> sources with their IP but that still requires the correct domain to be sent.
>>
>> Their argument is "no other carrier requires this - so sort it out". I
>> cannot use the ip as a domain because this problem is across resellers.Is
>> there a way around this?
>>
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing listSpce-user at lists.sipwise.comhttps://lists.sipwise.com/listinfo/spce-user
>>
>>
>>
>> _______________________________________________
>> Spce-user mailing list
>> Spce-user at lists.sipwise.com
>> https://lists.sipwise.com/listinfo/spce-user
>>
>>
> _______________________________________________
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> https://lists.sipwise.com/listinfo/spce-user
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20180119/81c49a98/attachment-0001.html>