SIP address using IP's with leading 0's

[zensoftware]

Hi,

Bit of a strange one this but I will try to explain.

We have a customer who has been configuring there phones with a SIP server of 090.155.090.174. (notice the leading 0's in the IP address)
This leads to SIP invites from for example [email protected].
3CX will allow a user to register with these settings but they cannot make or receive calls.
you just get the following in the logs.

"CM500002]: Unidentified incoming call. Review INVITE and adjust source identification:"

This would suggest that 3CX is taking the literal ASCII text of '090.155.090.174' and not reading that as an IP address and trying to match it against its database.
Is this correct?

I think you could easily argue that the phone should amend the IP address to be in the correct format (eg 90.155.90.174) when the data is entered but we have tested this on a Snom 320 and can replicate the issue.

Has anyone else come across this?

I think a easy fix would be for 3CX to perform some logic on the text and if it only includes digits and it could be an IP address then amend the data accordingly to be able to match it against its own IP address.

Any ideas?

Cheers
Neil

 

[SY]

Neil,

Could you please make a WireShark capture of network traffic for described situation?
It will help us to find the reasons and provide information(comments).
In general, if server address is configured as "090.155.090.174" on device then request must not reach address "90.155.90.174"

Thanks a lot for your help

 

[archie]

Yes, 3CX PBX compares strings in this case. It is because you can also use FQDN, not IP.

 

[Philco]

Actually, you an receive calls but not make them when the leading 0s are put in the server address in the phone.


Phil

 

[SY]

Actually, you an receive calls but not make them when the leading 0s are put in the server address in the phone.


Phil

Actually, we don't have any information and it is a reason why we are asking for it.

If you can, just send us your WireShark capture (you posted quotation in other thread) .

Thanks

 

[Philco]

Hi Stepan, I'll leave it up to zen to post theirs.

My post was from net monitor and I think I've also posted a better copy of the 3cx log, have you seen that?

You could try puting leading zeros in the server address of a phone on your test Stepan, zen certainly got the same results I did.


Thanks

Phil

 

[zensoftware]

Hi,

Here are two traces from our test server.

The calling phone is a snom 320 "Dave Dark" and in the first example "correct IP details.pcap" the SIP registration server is set as "172.17.8.251". this therefore works as expected.
In the second example "extra 0 in IP details.pcap" the registration server is set to "172.017.008.251" and so the call cannot be made.

I hope that helps.

Cheers

neil

 

[SY]

Hi,

Here are two traces from our test server.

The calling phone is a snom 320 "Dave Dark" and in the first example "correct IP details.pcap" the SIP registration server is set as "172.17.8.251". this therefore works as expected.
In the second example "extra 0 in IP details.pcap" the registration server is set to "172.017.008.251" and so the call cannot be made.

I hope that helps.

Cheers

neil

Hi Neil,

Adding the leading 0's in IPv4 address is a question of interpretation. Unfortunately, I cannot find any specification (probably I didn't try to find it too persistent) for IPv4 literal representation. Most of description of IPv4 address (in host part) is 1*digit "." 1*digit "." 1*digit "." 1*digit. I think there is not any specification for literal representation of IPv4 addresses(but it is defined for IPv6). Please correct me if I'm wrong.

For example:
Ping utility uses "C-style" of interpretation (at least windows version, may be unix version has another behavior :?: ):
0nnn - octal representation. 077=63(decimal), 0100=64(decimal)
0xnn - hexadecimal - 63=0x3F, 64=0x40
172.017.008.251 = 172.15.8.251. 008=8(digit) because it is not correct octal number and it interpreted as digit.

Solution: remove leading 0's.
Questions: Who(what) placed those 0's in phone configuration?

Thanks a lot for your information

 

[Philco]

Hi Stepan, I think Neil may be posting the enquiry as I was the one who was putting the leading 0s in the address. I accidentoy put them as I copy pasted the address into the 4 accounts/lines on a Grandstream GXP2020 and also in a Snom 320 which I think Neil has also tested.

However, I'll tell you the reason I sometimes place leading 0s in, it is because some devices dont auto flow or 'tab' accross to the next octet/box if there is less than 3 digits in a box so I place leading 0s.

Snoms and Grandstreams (and I guess other devices) seem quite happy for me to use leading 0s in the IP address for the device, but when the device configuration is saved, the leading 0s are removed, where as if leading 0s are used in the sip server/registration field the leading 0s are retained when the configuration page is saved.

The server/registration field is of course usually a text box and not four boxes for each octet of an IP address. So maybe this is an overight on the device manufacturers where they have not included a routine to remove leading 0s in the sip server/registration fields if the entry is in the form of an IP address.

The issue was more confused as I had already got a number of devices quite happily working on 3cx but I had entered the server address without leading 0s in those and it was something I had overlooked when adding some additional devices.

I wont use leading 0s in my sip server address field.


I wont do it again, honest..


Phil

 

[SY]

Hi Stepan, I think Neil may be posting the enquiry as I was the one who was putting the leading 0s in the address. I accidentoy put them as I copy pasted the address into the 4 accounts/lines on a Grandstream GXP2020 and also in a Snom 320 which I think Neil has also tested.

However, I'll tell you the reason I sometimes place leading 0s in, it is because some devices dont auto flow or 'tab' accross to the next octet/box if there is less than 3 digits in a box so I place leading 0s.

Snoms and Grandstreams (and I guess other devices) seem quite happy for me to use leading 0s in the IP address for the device, but when the device configuration is saved, the leading 0s are removed, where as if leading 0s are used in the sip server/registration field the leading 0s are retained when the configuration page is saved.

The server/registration field is of course usually a text box and not four boxes for each octet of an IP address. So maybe this is an overight on the device manufacturers where they have not included a routine to remove leading 0s in the sip server/registration fields if the entry is in the form of an IP address.

The issue was more confused as I had already got a number of devices quite happily working on 3cx but I had entered the server address without leading 0s in those and it was something I had overlooked when adding some additional devices.

I wont use leading 0s in my sip server address field.


I wont do it again, honest..


Phil

Hi Phil,

There is (slightly) our fault as well (literal comparison)
As far as the rules are not strictly defined then this complaint is just a subject of philosophic discussion.
Sorry if I didn't describe my point strictly.

Thanks

 

[zensoftware]

Hi Stephan,

Thanks for the quick and concise response. Yes your right Phil I am following up on your issue from last week. Thanks chaps, I think the conclusion is fair. The SIP registration server field should be treated as a string as it could indeed be a FQDN, and this would explain why the mismatch occurs.

All good to know.

Thanks

Neil