wellread01 Posted September 21, 2013 Report Share Posted September 21, 2013 I recently added a Grandstream ATA (firmware v1.0.9.1 [latest]) to my snom ONE PBX (5.1.1 (Win64)). Caller ID works fine with the Grandstream ATA (i.e. the attached phone displays the CID) if the Trunk Routing/Redirection Default Account is set to the ATA's assigned extension. However, if the ATA extension is part of a Hunt Group where the Behaviour: From-Header is set to Calling-Party (or any other setting), the ATA's attached phone simply displays "Incoming Call". I don't have any experience debugging these kinds of problems and any help would be appreciated. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 22, 2013 Report Share Posted September 22, 2013 I would be thinking that the device has a problem with the character set (I believe that IA5 is the encoding here) or the length of the caller-ID. The length between the first two rings sets a limit on how long the string can be. Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 23, 2013 Author Report Share Posted September 23, 2013 Thanks for the info. My grasp of telephony implementations and concepts is pretty tenuous so I am having a little trouble implementing these insights. Is the snom ONE able to set the character encoding scheme from IA5 to ASCII? I don't see any obvious settings that would change the character encoding scheme in my ATA. My ATA/handset combination can display 15 characters and appears to truncate longer CIDs when the call is routed via trunk redirection. It is only when the call is routed via a Hunt group that there is a problem. I don't see any setting in the Hunt group that relates either to character encoding or CID length. Are there settings somewhere in the snom ONE that might fix the problem? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 23, 2013 Report Share Posted September 23, 2013 The ATA is responsible for encoding in IA5. In short words: Try to choose a very short name for the group and choose only simple characters (e.g. SG1 instead of "Sales Grüppchen 1"), so that you don't exceed the limits of the caller-ID display on the ATA. Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 23, 2013 Author Report Share Posted September 23, 2013 I used "H" for the group name. My CID is "office". If I set trunk redirection to the Hunt group and the From-header group behaviour to "Calling-Party" I see the following on the test extenisons: Grandstream 502 ATA: "Incoming Call" snom 820: Caller: "office" If I set the From-header group behaviour to "Group name" I see the following on the two test extenisons: Grandstream 502 ATA: "Incoming Call" snom 820: Caller: "H" If I set trunk redirection to the Grandstream 502 ATA I see the following: "Incoming Call" -> "office" (displays before first ring) If I set trunk redirection to the snom 820 I see the following: "office" Can you suggest a test that would allow me to verify whether the ATA supports IA5. Other than the problem with the Hunt group, the ATA appears to support whatever character encoding is generally used for incoming calls. Do the CID header settings for the trunk have any bearing on this issue? I used the default settings provided by snom ONE for my carrier: CallCentric Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 23, 2013 Report Share Posted September 23, 2013 You should wait for the 2nd ring; in the analog world, the caller-ID is transmitted between the first ring and the second ring. I guess you did that already. Before the 2nd ring you will always see "Incoming Call": Actually it is not so much the problem of the ATA to render all characters; the connected telephone must of course also support all characters. I am sure that the ATA supports "IA5"; at least I don't think it is worth going too deep into the encoding path. The only characters that could be a problem are ( and ); they are used in the hunt group caller-ID setup when you want to mix the group and the caller-ID. Maybe give an extension the username "A(B)" and see if the ATA can display that. Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 23, 2013 Author Report Share Posted September 23, 2013 As you surmise, I am not concerned about the first ring display, only the subsequent rings. I assigned the snom 820 user name First name: "A( B)"and Last name: "C~$"; the ATA displayed "A( B)" C~$" I assigned the snom 820 user name First name: "0123456789"and Last name: "ABCDEFGHIJ"; the ATA displayed "0123456789 ABCD" Added note: The ATA CID displays were correct. The happy face was added by the forum editor. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 24, 2013 Report Share Posted September 24, 2013 Now I am puzzled. What do you see in the INVITE packet that is being send from the PBX to the ATA? I guess that's the key question now. Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 24, 2013 Author Report Share Posted September 24, 2013 Caller (CID): Callcentric EXTCallee snom 820, ext 40, (CID): office phoneCallee ATA (Grandstream HT502), ext 41, (CID): home phoneCallee Hunt group (stage 1 ext 41 & 40 [60s]; stage 2 & 3 blank; final stage 840), ext 72 (CID): Hunt Hunt Group behaviour, From-header: Calling-Party SIP trunk phone number: 1777xxxxxxxxx7My phone number: 1xxxxxxxxx3Logfile excerpts:snom ONE trunk redirected to ext 41Result - phone on ATA displays: Callcentric EXT INVITE sip:41@192.168.1.107:5062 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK-a5a7dfec5de4ea3c3c5593306174815a;rport From: "CallCentric EXT" <sip:101@pbx.company.com;user=phone>;tag=54481 To: "home phone" <sip:41@pbx.company.com>snom ONE trunk redirected to ext 40Result - snom 820 displays: Callcentric EXT INVITE sip:40@192.168.1.123:1024;line=rk6z6l7o SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK-f9699d9b1a8dc86967192bea69425465;rport From: "CallCentric EXT" <sip:101@pbx.company.com;user=phone>;tag=21721 To: "office phone" <sip:40@pbx.company.com>snom ONE trunk redirected to ext 72Result - phone on ATA displays: Incoming CallResult - phone on snom 820 displays: Callcentric EXTNote the same result at the ATA is obtained if only the ATA is in the Hunt group. INVITE sip:41@192.168.1.107:5062 SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK-db21d624464a631ef90955af7d9e25f9;rport From: "CallCentric EXT" <sip:101@pbx.company.com;user=phone>;tag=27652 To: <sip:1xxxxxxxxx3@66.193.176.35;user=phone>.... INVITE sip:40@192.168.1.123:1024;line=rk6z6l7o SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK-abf26457a475334cb5c7d5ea18bca925;rport From: "CallCentric EXT" <sip:101@pbx.company.com;user=phone>;tag=20790 To: <sip:1xxxxxxxxx3@66.193.176.35;user=phone>.... INVITE sip:1777xxxxxxxxx7@192.168.1.100:5060;transport=udp;line=eccbc87e SIP/2.0 v: SIP/2.0/UDP 204.11.192.160:5060;branch=z9hG4bK-f8e466e23bd72b90dea2ee17364e991a;change=ta f: "CallCentric EXT" <sip:101@callcentric.com>;tag=1889682764 t: <sip:1xxxxxxxxx3@66.193.176.35> Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 24, 2013 Author Report Share Posted September 24, 2013 Well I have made some headway. I dug up an old linksys RTP300 ATA, added it to the snom ONE PBX. It displays the correct Caller ID in the Hunt group. I'll have to review the Grandstream settings to see if I kind find a problem. Quote Link to comment Share on other sites More sharing options...
wellread01 Posted September 24, 2013 Author Report Share Posted September 24, 2013 I found the problem. It was a Granstream HT502 firmware bug that, when combined with the valid, default snom ONE ring setting for the Hunt Group, caused the CID to be parsed incorrectly. Grandstream HT502 firmware v 1.0.10.9 fixed the problem (released 3 weeks ago, Sep 6, 2013). A work around for HT502 firmware v 1.0.9.1 is to set the snom ONE hunt group Ring melody to: No specific ring melody I believe the bugfix that bears on this issue is: Fixed fail to parse CID when receiving distinctive ring tone dr2/3/4/5/7 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted September 25, 2013 Report Share Posted September 25, 2013 Thanks for sharing this with us! It was something hard to find. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.