Alphanumerics in User Name

[JRayfield]

1. Brekeke Product Name and Version:

SIP Server, Version 3.9.2.1/515

2. Java version:

1.8.0_201

3. OS type and the version:

Windows Server 2016

4. UA (phone), gateway or other hardware/software involved:

3CX

5. Your problem:

I've tried using some alphanumeric characters in User names for Authentication. (for example, Customer4171112222001) When I've done this, in some cases, I've had some intermittent problems with outbound calls from 3CX servers, through BSS, where they would get a SIP 603. When this has happened, I've removed the alphanumeric characters from the User name (such as 4171112222001) and the problem went away.

Is there any known problem with using alphanumeric characters in the User name in BSS, or is there a limit as to how many characters long the User name can be in BSS?

John Rayfield, Jr.

[snuyzm]

Are both SIP username and auth username same?

In your example, is 4171112222001 a SIP username?

Let you set "no" at [Auth-user=user in "To:" (Register) ] and [Auth-user=user in "From:"] in Configuration->SIP page.

[JRayfield]

Both of those settings are set to Yes.

And, yes, the Authentication and the User are both the same. Registration between the 3CX server and the BSS are fine. And inbound calls (BSS to 3CX) always work fine. The only problem is in outbound calls (3CX to BSS). And this only occurs intermittently. But the problem never occurs if I only use numbers in the Authentication and User fields.

John

[snuyzm]

Have you switched these Auth-user settings to "no"?

Check the [Logs]->[Error Logs] if the problem still happens.

[JRayfield]

Let me clarify a bit.

I'm using a combination of User/Password Authentication and IP Address Authentication from a 3CX server and BSS.

$registered("4171112222001") = true
$addr = ^11.22.33.44$

Obviously the numbers in the above lines are 'fake', to protect the actual authentication information.

This works great, as I've shown them above.

But, if the string in the $registered line is changed to something like this:

$registered("customer4171112222001") = true

Then it also works, but after a while, it seem that something happens and calls through this Dial String start to have a SIP 603 returned to the 3CX server from BSS. When this happens, it appears that the 3CX server is still registered with BSS, but BSS still returned the SIP 603.

It's odd that this problem doesn't seem to show up for a while after setting up a user with the alphanumeric user name/authentication name, but then shows up a bit later.

It would interesting, though, to change the settings to which you're referring, when this problem occurs, to see what happens. I also need to look more closely at some packet captures when this happens.

John

[snuyzm]

> $registered("4171112222001") = true
> $addr = ^11.22.33.44$

The above rule will match even if a REGISTER was not sent from 11.22.33.44.

If you want to accept an INVITE sent from the same remote IP address of REGISTER, let you rewrite Matching Patterns like the following.

Matching Patterns

$registeredSender = true $addr = ^11.22.33.44$

https://docs.brekeke.com/sip/registeredsender



> $registered("customer4171112222001") = true
>
> Then it also works, but after a while, it seem that something happens
> and calls through this Dial String start to have a SIP 603 returned to
> the 3CX server from BSS.

Can you find "customer4171112222001" in the [Registered Clients] ?
If so, $registered() method returns true. Otherwise, it returns false.

Does 3CX send REGISTER packets periodically to keep the binding?

[JRayfield]

Yes, 3CX sends register packets every so often on SIP trunk connections (so in this case, to the BSS.

John

[snuyzm]

Can you find the record like "customer4171112222001" in the [Registered Clients] page after the SIP Server sends SIP 603?

If yes.. the SIP Server didn't receive subsequent REGISTER packets from the 3CX.

Are you using Auth for REGISTER too?

[JRayfield]

Yes, I am using Auth for REGISTER requests from the 3CX server.

Regarding the use of $registerdSender vs. $registered, for incoming calls from the upstream voip service provider, the BSS does not use username/password authentication with that provider. It uses IP authentication. But, for an incoming call, I want to make sure that the client (i.e. 3CX server) is registered with BSS. Using $register in the dialplan for incoming calls, along with $addr, works well because the incoming call INVITEs are not coming from a 'registered' user (a user in the BSS database). But, for outgoing calls, I see what you mean. I should definitely us $registedSender for outgoing calls (calls coming from 3CX into BSS).

After taking more packet captures, I've come to the conclusion that there is a problem in the 3CX server that is getting the 603s.

John

[JRayfield]

So I implemented the $registeredSender.

This worked fine. For a while. Then it 'broke'.

I started getting 403 Forbidden messages back to 3CX from BSS. I didn't change anything at all. It was working fine and then it started returning the 403 messages. And this was with multiple 3CX servers, not just one.

I changed the lines back to $register and everything is ok again.

Then, on my own 3CX system connection to BSS, I changed back to $registeredSender, and it works fine again.

Any ideas as to why $registeredSender worked at first and then started to fail, without any other changes being made to BSS, and then works again ok if I put it back in (after changing it to $registered)?

It seems 'unstable', as if there's a problem in the BSS code itself.

One other thought... I do not have a $continue anywhere in my rules (and I have a lot of rules for different clients). Should there be a $continue= anywhere in my rules? I'm a bit unclear as when this would be used.

John

[JRayfield]

Here's a follow up.

I don't know how $registeredSender ever worked in my BSS system. According to the Brekeke documentation, $registeredSender is True "If the From-URI indicates a registered user and the SIP request comes from a registered Contact IP address and port number.".

My 3CX IP PBX is configured so that the User part of the From line is the Outbound Caller ID number. That means that the From-URI would not include the Authentication Name that 3CX uses to register with the BSS. So the From-URI would NOT indicate a registered user. Thus, $registeredSender would never be True.

However, the User part of the Contact line does have the Authentication Name in it. So, I tried using $registered(Contact)=true, and this does work.

John

[snuyzm]

> Any ideas as to why $registeredSender worked at first and then started to fail,


It seems that 3CX changes a source port number after while.
The $registeredSender method checks whether both remote IP address and port number are same as the latest accepted REGISTER request.

Is the 3CX located behind a router? If so, the router might change the source port number when it updates the port-mapping.

[JRayfield]

Yes, the 3CX server is behind a router. And I have seen routers change port numbers like that in the past. Motorola Solutions has a professional digital two-way radio system that requires that port numbers not change. I had a terrible time with finding routers that wouldn't randomly change the WAN-side port numbers. I finally found MikroTik routers. They don't do that. They're great. But, some of my 3CX customers' systems are behind other brands/models of routers, over which I have no control. So, this is a good thing for me to watch for.

Thanks!
John

[snuyzm]

If you still have the issue with the alphanumeric username, set "no" for the following settings in the [Configuration]->[SIP] page. With these settings, the SIP Server doesn't check whether the Auth name is same as SIP username.

[Auth-user=user in "To:" (Register) ] = no
[Auth-user=user in "From:" ] = no

[JRayfield]

It's turned out that the two systems that I was having trouble with, had problems in those systems. With one system, AT&T was blocking UDP traffic on port 5060 and with the other system, their Barracuda router was intermittently blocking outbound Register requests that included authentication information.

John