Problem with SPA3102 passing invalid caller ID names

Status
Not open for further replies.

scruffybob

Joined
Jan 3, 2009
Messages
11
Reaction score
0
I'm using 3CX 7.9.4249.0.

I'm using some Linksys SPA-3102's (5.1.7(GW) and 3.3.6(GW) firmware) and am getting "Error 400: BAD REQUEST (multiple values in single-value header) FROM" responses from my PBX.

According to packets grabbed by Wireshark, the INVITE from the SPA3102 goes out with the following FROM field:

From: MACKEY, RON E <sip:[email protected]>;tag=b9c8ff5d2616dc03o1

The ASCII version:
0000 46 72 6f 6d 3a 20 4d 41 43 4b 45 59 2c 20 52 4f From: MACKEY, RO
0010 4e 20 45 20 3c 73 69 70 3a 36 33 30 33 35 37 38 N E <sip:6303578
0020 31 33 35 40 31 39 32 2e 31 36 38 2e 32 2e 31 33 [email protected]
0030 32 3e 3b 74 61 67 3d 62 39 63 38 66 66 35 64 32 2>;tag=b9c8ff5d2
0040 36 31 36 64 63 30 33 6f 31 0d 0a 616dc03o1..

My reading of the SIP RFC (and it's been a long time since I read an RFC) says that a display-name containing a comma must be enclosed in quotes (""). This would seem to be confirmed by the bad request response from the IP-PBX.

Some questions:

1. Is this an error in the SPA3102?
2. If so, is there any way to prevent the SPA3102 from sending the display-name without disabling caller id altogether?
3. Is this an incorrect interpretation of the RFC by me and 3CX? In other words is the SPA3102 okay in passing an unquoted caller ID display name?
4. I've always ascribed to the theory that you should be liberal in what you accept and conservative in what you send. Even if this is an error by the SPA3102, would the 3CX be best in accepting the packet since it's pretty clear what the correct behavior should be?

I'm running firmware 5.1.7(GW), but the problem also occurs with the 3.3.6(GW) firmware.

Additional information...

The SPA3102 has a field called "Escape Display Name" under the SIP parameters that I would guess should quote the display name, but setting it to "Yes" does nothing.

If I disable passing the PSTN caller-ID, then the SPA3102 uses the Display Name out of the Subscriber information as the Display info it passes on the INVITE. In this case, the "Escape Display Name" will quote the display name if the field is set to "Yes" and will not quote the display name if the field is set to "No", so I'm absolutely sure I'm getting the field set appropriately. However, quoting the field that I statically entered in another place isn't overly interesting. I need it to quote the incoming caller id name as passed in from the telephone company.

In fact, as I tried to figure this out, I tried to use the PSTN CID Name Prefix (under the PSTN tab) as a way to get it to quote the CID Name. What I found is that you can enter any special characters you'd like (commas, quotes, etc.) and it will happily generate an illegally formatted INVITE packet on it's own by pre-pending these characters to the passed name. I'm actually a little shocked that you can get it to generate illegal frames so easily.

This is killing me, as my only recourse seems to be to disable incoming Caller-ID altogether. Since incoming call flow is a big reason I want to convert to an IP-PBX, it makes the SPA3102's worthless if I can't resolve this issue. I didn't have much luck on the Linksys forum (the only suggestion there was to not use commas)

I used Wireshark to sniff the network to verify that the SIP packet generated by the SPA3102 is improperly formatted.

According to packets grabbed by wireshark, the INVITE from the SPA3102 goes out with the following FROM field:

From: MACKEY, RON E <sip:[email protected]>;tag=b9c8ff5d2616dc0 3o1

The ASCII version:
0000 46 72 6f 6d 3a 20 4d 41 43 4b 45 59 2c 20 52 4f From: MACKEY, RO
0010 4e 20 45 20 3c 73 69 70 3a 36 33 30 33 35 37 38 N E <sip:6303578
0020 31 33 35 40 31 39 32 2e 31 36 38 2e 32 2e 31 33 [email protected]
0030 32 3e 3b 74 61 67 3d 62 39 63 38 66 66 35 64 32 2>;tag=b9c8ff5d2
0040 36 31 36 64 63 30 33 6f 31 0d 0a 616dc03o1..

Does anyone know how to get the Caller ID NAME quoted properly as it's passed from the PSTN to the VOIP gateway, or at least is there any way to pass the incoming Caller ID from the PSTN but NOT pass the Caller ID Name? As long as I can get the ID, I can work around not getting the name.

Best regards,
scruffy-bob
 
Unquoted CID violates SIP standard. We can not support such violation. You better bump Linksys to fix that bug.
 
This problem is still present in the new 5.1.10(GW) firmware. Grrrrr...... I did bump Linksys/Sipura (I think!), and there are several posts on their forums about it. I'm a developer myself (astronomy observatory control systems), and occasionally I make accommodations for devices that come from reluctant manufacturers so I can have happy customers. I'm well aware that this sort of thing pollutes clean software. Plus it tends to remain in the code long after the original problem is fixed - future maintainers don't even know why its there unless it is commented thoroughly with a **HACK** marker or something.

But in this case, a very popular ATA is nearly useless for inbound PSTN calls in the US (cannot pass caller-ID). Please consider making an accommodation for this. It would be a matter of looking for the quotes, and if not there, adding them, then letting the rest of the code do its thing. Done right, it wouldn't be a risk for conforming SIP messages.
 
Can you describe it algorithmically? Changes to ABNF?
 
We have an update to our template that should fix caller ID - it will be uploaded in the coming days
 
Not sure if this topic regards the same issue as I experienced last weekend, though as it might help someone out, I will share my solution. I experienced the problem where my to 3CX connected VOIP clients showed the internal number of the Linksys SPA3102, in my case 10001, instead of the number of the calling party. Googling on this problem I found multiple forums describing the same problems, most of them going into deeper changes and problem descriptions. I started playing with the SPA3102 settings a bit as I couldn't believe the problem to be that hard to solve and found out that the problem was indeed very easy resolvable by just setting a switch that wasn't mentioned in the SPA3102 tutorial on the 3CX website:

  • Log into your Linksys SPA3102 using your webbrowser
  • Go to PSTN line tab
  • Look for the PSTN-To-VoIP Gateway Setup section
  • Set the option PSTN CID For VoIP CID to yes
  • Save your settings

Even though the status page on the SPA3102 shows the comma which most users experience as being a problem, it forwards the phone number correctly to the 3CX and thus to the attached VOIP clients.
 
admin said:
We have an update to our template that should fix caller ID - it will be uploaded in the coming days

Hi Guys,

Does anyone know how to get access to that new template that "admin" mentioned it would be uploaded in back in 2009? I am testing this functionality with 3cx (v9-14507) and the SPA3102.. and the issue still exists. I do agree that the source of the problem is the SPA3102, since is passing a non-compliant "FROM" string.. however I think this can easily be handled by 3CX by making an exception..

For example.. if the FROM is supposed to be formated like (FirstName LastName, 5555555555) and when the display name has a comma, the SPA3102 passes (FirstName, LastName, 5555555555), which breaks makes the field invalid.. a way to resolve this.. would be.. to grab the whole string, identify the LAST comma (to check when the CALLERNAME is separated from the actual number), and treat everything before the comma as the CALLER DISPLAY NAME. That way, no matter what caracters are passed in the DISPLAY NAME, 3cx won't have issues with the formatting..

Again, I know this is workaround solution.. but since Cisco is dragging their feet on this... there should be other ways to get it working..

If the template announced by "admin" back in 2009, already resolves this, please let me know how to get it and install it. I checked the Gateway Templates list in the app updates section, and the one for the SPA3102 says "up-to-date" but it doesn't resolve the issue.

Thanks!
 
Status
Not open for further replies.

Forum statistics

Threads
112,326
Messages
591,901
Members
165,479
Latest member
Senergia