[cisco-voip] QSIG: Display name decoding fails
Ryan Ratliff
rratliff at cisco.com
Wed Jul 12 09:04:34 EDT 2006
These two lines seem to point to the problem...
07/12/2006 07:16:46.279 CCM|***Message - Unknown codeset used in
Validation-- MessageType = 5 Codeset= 4|<CLID::IPT-Cluster><NID::
10.30.100.1>
07/12/2006 07:16:46.279 CCM|***Message - Unknown IE -- NOT SAVED--
MessageType = 5 Unknown IeId = 31 TblIndex = 15 Codeset = 4|
<CLID::IPT-Cluster><NID::10.30.100.1>
I recall that CM only supported certain codesets but I didn't think
it applied to Qsig.
-Ryan
On Jul 12, 2006, at 4:07 AM, Dietmar Romer wrote:
This is the CCM trace.
Dietmar
07/12/2006 07:16:46.279 CCM|MGCPBhHandler 10.8.104.250 - TCP msg
available from Device|<CLID::IPT-Cluster><NID::10.30.100.1><CT::
3,100,61,1.197388><IP::10.8.104.250><DEV::>
07/12/2006 07:16:46.279 CCM|MGCPBhHandler - Receiving BhHdr: 0004
0000 0011 8000 0001 0102
|<CLID::IPT-Cluster><NID::10.30.100.1><CT::3,100,61,1.197388><IP::
10.8.104.250><DEV::>
07/12/2006 07:16:46.279 CCM|MGCPBhHandler - PktCapService::out
(Protocol_Backhaul,src=10.8.104.250,port=2428,desc=10.30.100.1,port=2428
,0,0,msg,len=270,gateway=10.8.104.250)|<CLID::IPT-Cluster><NID::
10.30.100.1><CT::3,100,61,1.197388><IP::10.8.104.250><DEV::>
07/12/2006 07:16:46.279 CCM| |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|In Message -- PriQsigSetupMsg --
Protocol= PriQsigProtocol|<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Ni2BearerCapabilityIe -- IEData= 04
03 80 90 A3 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931ChannelIdIe -- IEData= 18 03 A1
83 81 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931FacilityIe -- IEData= 1C A3 9F
AA 06 80 01 00 82 01 00 8B 01 00 A1 0E 02 02 03 BE 02 01 29 03 05 00
8E 00 00 00 A1 6D 02 02 03 C0 02 01 55 30 64 82 09 00 40 08 00 00 00
00 00 00 86 01 01 A8 54 30 40 06 09 2B 0C 02 87 6D 0B 0E 88 4C E0 33
E0 13 C0 01 3E E1 0E A1 0C 0A 01 02 12 07 37 33 39 31 35 30 32 E1 0C
C1 07 00 80 00 00 00 00 00 C3 01 02 E2 0C C1 07 00 D4 00 00 00 00 00
C3 01 01 E3 00 30 10 06 09 2B 0C 02 87 6D 0B 0E 88 4D 03 03 00 80 00
A1 16 02 02 03 C2 02 01 00 80 0D 48 72 2E 20 4D 6F 68 6E 20 4D 2E 20
32 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931FacilityIe -- IEData= 1C 2D 9F
AA 06 80 01 00 82 01 00 8B 01 02 A1 09 02 02 03 C1 02 01 54 05 00 A1
14 02 02 03 BF 02 01 3B 30 0B 30 09 0A 01 05 0A 01 03 0A 01 04 |
<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931CallingPartyIe -- IEData= 6C 0A
00 80 39 30 30 38 33 37 36 33 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931CalledPartyIe -- IEData= 70 09
80 39 30 33 30 37 38 30 38 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|***Message - Unknown codeset used in
Validation-- MessageType = 5 Codeset= 4|<CLID::IPT-Cluster><NID::
10.30.100.1>
07/12/2006 07:16:46.279 CCM|***Message - Unknown IE -- NOT SAVED--
MessageType = 5 Unknown IeId = 31 TblIndex = 15 Codeset = 4|
<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|Ie - Q931HighLayerCompatibilityIe --
IEData= 7D 02 91 81 |<CLID::IPT-Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|MMan_Id= 0. (iep= 0 dsl= 8000 sapi= 0
ces= 0 IpAddr=fa68080a IpPort=2427)|<CLID::IPT-Cluster><NID::
10.30.100.1>
07/12/2006 07:16:46.279 CCM|IsdnMsgData1= 08 02 00 38 05 04 03 80 90
A3 18 03 A1 83 81 1C A3 9F AA 06 80 01 00 82 01 00 8B 01 00 A1 0E 02
02 03 BE 02 01 29 03 05 00 8E 00 00 00 A1 6D 02 02 03 C0 02 01 55 30
64 82 09 00 40 08 00 00 00 00 00 00 86 01 01 A8 54 30 40 06 09 2B 0C
02 87 6D 0B 0E 88 4C E0 33 E0 13 C0 01 3E E1 0E A1 0C 0A 01 02 12 07
37 33 39 31 35 30 32 E1 0C C1 07 00 80 00 00 00 00 00 C3 01 02 E2 0C
C1 07 00 D4 00 00 00 00 00 C3 01 01 E3 00 30 10 06 09 2B 0C 02 87 6D
0B 0E 88 4D 03 03 00 80 00 A1 16 02 02 03 C2 02 01 00 80 0D 48 72 2E
20 4D 6F 68 6E 20 4D 2E 20 32 1C 2D 9F AA 06 80 01 00 82 01 00 8B 01
02 A1 09 02 02 03 C1 02 01 54 05 00 A1 14 02 02 03 BF 02 01 3B 30 0B
30 09 0A 01 05 0A 01 03 0A 01 04 6C 0A 00 80 39 30 30 38 33 37 36 33
70 09 80 39 30 33 30 37 38 30 38 9C 31 01 80 7D 02 91 81 |<CLID::IPT-
Cluster><NID::10.30.100.1>
07/12/2006 07:16:46.279 CCM|MGCPpn9d - initPortInfo:
portInfo[00] endpoint=S0/SU0/DS1-0/1 at xxx, ci=50467533,
globalCallId=3|<CLID::IPT-Cluster><NID::10.30.100.1><CT::
3,100,61,1.197388><IP::10.8.104.250><DEV::>
07/12/2006 07:16:46.279 CCM|SPROC analyzeMsgtransCause
MessageTransCause.ms = 0, MessageTransCause.ieid = 0, PriTsp.protocol
= 29, MCStatus = 0|<CLID::IPT-Cluster><NID::10.30.100.1>
-------- Original-Nachricht --------
Datum: Tue, 11 Jul 2006 19:28:24 -0400
Von: Wes Sisk <wsisk at cisco.com>
An: Dietmar <db7td at gmx.de>
Betreff: Re: [cisco-voip] QSIG: Display name decoding fails
> If not,
>
> Send us the raw message from the trace (whole packet from the line
> that says qsig through and including the line that has the longest
> hex numbers.
>
> /Wes
>
> On Jul 11, 2006, at 1:05 PM, Dietmar wrote:
>
> Ah, this is a very good idea! I will check this as soon as possible.
> Thank
> you!
>
> Dietmar
>
>> Have you looked at the CCM trace? CCM will show the decoded Facility
>> IE in the trace.
>>
>> -Ryan
>>
>> On Jul 11, 2006, at 12:58 PM, Dietmar wrote:
>>
>> Yes, I have already tried this. Unfortunately, it did not help. I
>> think the
>> problem is the long facility. The display name is located at the end
>> of it.
>> Maybe Callmanager can not decode everything and stops at some point
>> in the
>> middle...
>>
>> Dietmar
>>
>>> What about changing the plan type? My Qsig link is Private
>>> national.
>>>
>>> Scott
>>>
>>> -----Original Message-----
>>> From: cisco-voip-bounces at puck.nether.net
>>> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Dietmar
>>> Sent: Tuesday, July 11, 2006 9:39 AM
>>> To: cisco-voip at puck.nether.net
>>> Subject: [cisco-voip] QSIG: Display name decoding fails
>>>
>>> Hi all,
>>>
>>> I have an ISO-QSIG connection between a MGCP controlled 2821
>>> (backhauled
>>> to
>>> CCM 4.1(3)) and a Tenovis PBX.
>>>
>>> When someone places a call from the Tenovis towards the 2821,
>>> Callmanager
>>> seems to be unable to decode the display name (CNAM) of the calling
>>> party.
>>> However, the trace below shows that it is included within the
>>> facility.
>>>
>>> Can anyone tell me what is going wrong there?
>>>
>>> Thanks, Dietmar
>>>
>>>
>>>
>>> 000727: Jun 28 14:41:03.983: ISDN Se0/0/0:15 Q931: RX <- SETUP pd
>>> = 8
>>> callref
>>> = 0x004F
>>> Bearer Capability i = 0x8090A3
>>> Standard = CCITT
>>> Transfer Capability = Speech
>>> Transfer Mode = Circuit
>>> Transfer Rate = 64 kbit/s
>>> Channel ID i = 0xA18381
>>> Preferred, Channel 1
>>> Facility i =
>>> 0x9FAA068001008201008B0100A10D0201480201290305008E
>>>
>>> 000000A16C02014A0201553064820900400800000000000086
>>>
>>> 0101A854304006092B0C02876D0B0E884CE033E013C0013EE1
>>>
>>> 0EA10C0A0102120737333931353032E10CC107008000000000
>>>
>>> 00C30102E20CC10700D40000000000C30101E300301006092B
>>>
>>> 0C02876D0B0E884D0303008000A10F02014C02010080075465
>>> 6E6F766973
>>> Facility i =
>>> 0x9FAA068001008201008B0102A10802014B0201540500A113
>>> 02014902013B300B30090A01050A01030A0104
>>> Calling Party Number i = 0x0080, '3700'
>>> Plan:Unknown, Type:Unknown
>>> Called Party Number i = 0x80, '8999'
>>> Plan:Unknown, Type:Unknown
>>> Shift to Codeset 4
>>> Codeset 4 IE 0x31 i = 0x80
>>> High Layer Compat i = 0x9181
>
> --
> E-Mail: db7td at gmx.de
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
More information about the cisco-voip
mailing list