[cisco-voip] First character missing from calling name ID on
some calls from Cisco TAC engineers
Wes Sisk
wsisk at cisco.com
Tue Aug 10 23:07:54 EDT 2004
Hi Lelio,
I'm sorry, 919 is RTP. One too many route filter expressions :)
/Wes
Lelio Fulgenzi wrote:
> OK. I'll have to open a case when I have some time to commit. I've
> written down a few numbers from TAC engineers and they're willing to
> help reproduce the problem. I think most of them were from 919 to tell
> you the truth. But I can't remember. I'll post whatever I find out
> from the TAC to the list.
>
>
> ----- Original Message -----
> *From:* Wes Sisk <mailto:wsisk at cisco.com>
> *To:* Lelio Fulgenzi <mailto:lelio at uoguelph.ca>
> *Cc:* cisco-voip at puck.nether.net <mailto:cisco-voip at puck.nether.net>
> *Sent:* Tuesday, August 10, 2004 10:42 PM
> *Subject:* Re: [cisco-voip] First character missing from calling
> name ID on some calls from Cisco TAC engineers
>
> Hi Lelio,
>
> Yep, you've got MGCP. Hmm, CSCdu54048 should have taken care of
> this for you. We're gonna need that TAC case. Please include a
> CCM trace that shows an inbound call setup from a Cisco employee.
> Have you noticed coming from any specific Cisco campus/area code?
> RTP(392) SJ(408)...?
>
> CSCdu54048
>
>When CSCdu18827 <http://wwwin-metrics.cisco.com/cgi-bin/ddtsdisp.cgi?id=CSCdu18827> was resolved in CallManager 3.1(0.163), it was discovered
>that a number of ISDN switches implementing the DMS PRI protocols do not
>adhere to Nortel's specification for the Display IE.
>
>Specifically, there is an "extra" leading character that Nortel sends at
>the front of the Display IE that should not be used as part of the
>actual display for the telephone set.
>
>The problem is that now, all PRI gateways in CallManager that are configured
>to use one of the DMS PRI protocols assume that this extra character is there.
>If the ISDN switch is not sending this extra leading character, and rather
>the first character is part of the display name, then the first real
>character of the display name will be discarded from the telephone display
>on the IP phone. This can happen in any of the messages where the Display IE
>can be carried (e.g. SETUP, CONNECT, etc)
>
>For example, if I call from the IP phone on 3.1(0.163) to another phone
>through the gateway where my name display should be John Doe then when
>the call connects and the CallManager gets Display IE = John Doe then
>what actually gets displayed is:
>
> ohn Doe
>
>This is being filed as an enhancement so that for any time we receive a
>Display IE on the PRI gateway configured with one of the DMS PRI protocols,
>we should look at the most significant bit in the byte following the length
>field in the Display IE.
>
>If it is an ASCII character, then we do nothing and continue normally. If
>it is a non-ASCII character, then we strip off the entire byte before handing
>off the name display to the destination device.
>
>
>
>
>
> Lelio Fulgenzi wrote:
>
>> Hi Wes. We are using 6608 blades in a 6500 chasis, so it's not
>> IOS - it's CatOS, I think the bugs were for IOS in routers. I'm
>> pretty sure they are running MGCP, since I was told if it has the
>> T1 icon, it's MGCP, and it's H323 if it has H323 in the icon (all
>> in the gateway configuration screen on CallManager v3.3(3)sr4a).
>>
>> It's certainly wierd - it only occurs with calls from Cisco TAC
>> staff.
>>
>>
>> -----
>> -----
>> Lelio Fulgenzi, B.A.
>> lelio at uoguelph.ca.eh <mailto:lelio at uoguelph.ca.eh>
>> Network Analyst (CCS)
>> University of Guelph FAX:(519)
>> 767-1060 JNHN
>> Guelph, Ontario N1G 2W1 TEL:(519)
>> 824-4120 x56354
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> remove the 1st letter of the canadian alphabet from my
>> email, eh!
>>
>> ----- Original Message -----
>> *From:* Wes Sisk <mailto:wsisk at cisco.com>
>> *To:* Lelio Fulgenzi <mailto:lelio at uoguelph.ca>
>> *Cc:* cisco-voip at puck.nether.net
>> <mailto:cisco-voip at puck.nether.net>
>> *Sent:* Tuesday, August 10, 2004 8:08 PM
>> *Subject:* Re: [cisco-voip] First character missing from
>> calling name ID on some calls from Cisco TAC engineers
>>
>> Hi Lelio,
>>
>> Are you using h323 gateways?
>> CSCea76050, CSCdz86750,
>>
>> In the Avaya implementation of DMS trunks, they do not support
>> the special leading character. The Avaya PBX's are configured
>> for DMS switch type, and for that configuration the Avaya PBX
>> does not insert(on outbound) or strip(on inbound) the special
>> leading character.
>>
>> The possibilities:
>> 1) some endpoints do support the DMS special leading character
>> on trunks configured for the DMS protocol (Nortel PBX's)
>> 2) some endpoints do not support the DMS special leading
>> character
>> on trunks confiugred for the DMS protocol (Avaya,Cisco,other)
>> 3) it is not possibile for intermediate VOIP hops to modify
>> DisplayIE
>> 4) it is possbile for intermediate POTS hops to modify the
>> DisplayIE
>>
>> Basic opertion:
>> Default IOS behavior has to be maintained. The display IE
>> should be passed
>> from pots->voip and from voip->pots without modification.
>> The DisplayIE should
>> not be removed and inserted in the UserUserIE RAW data.
>>
>> What is needed to make this work for customer EY:
>> 1. DO NOT MODIFY DisplayIE (transparently pass DisplayIE
>> without modification in all cases)
>>
>> What is needed to make this work for all possible customer
>> permutations:
>> 1. Do nothing (blindly pass DisplayIE, make this default just
>> like in previous IOS versions)
>> 2. CLI to stip leading char going pots->voip
>> 3. CLI to insert leading char going pots->voip
>> 4. CLI to insert leading char going voip->pots
>> 5. CLI to strip leading char going voip->pots
>>
>> Leading character "0xB1" for DMS 100, or "0xB2" for DSM_250.
>>
>> ********************
>>
>> We have confirmed that the originating Jax CCM did not insert
>> the 0xB1, but the 0xB1 is present when
>> the call arrives at NY.
>>
>> I believe this is due to the IOS request CSCdx12421. This
>> was initially requested to have a hidden
>> CLI to add/remove the 0x81 character. However, the final
>> implementation in is a hard coded insertion of
>> 0xB1 when it is not initially present.
>>
>> Please confirm the version of code on the Jax 36xx router.
>>
>> We need to confirm once more that the 0xB1 is not in the
>> Dislpay when it leaves the Jax CCM, but is
>> there in the Debug isdn q931 when the call leaves the Jax router.
>>
>> Going forward we have 2 options:
>>
>> 1. use MGCP gateways everywhere. Callmanager still allows
>> the option of inserting 0xB1 or not
>> inserting it,
>> We could configure MGCP IOS gateways in Troy, Jax, and Hou??
>> to avoid this issue.
>>
>> 2. upgrade CCM to at least 3.2(2c)spF everywhere and enabled
>> the parameter
>> "SendExtraLeadingCharacterInDisplayIE"
>> everywhere. CCM requires this flag be set in the gateway
>> configuration page to check for the 0xB1
>> character and remove it.
>> With this box checked, incoming messages from MGCP gateways
>> will be checked and stripped of a
>> leading 0xB1 character.
>> However, this will also have CM send the leading character
>> out as well, so the far end CM will have
>> to expect this and remove it.
>> Thus the need for 3.2(2c)spF and this configuration in all
>> locations.
>>
>> /Wes
>>
>>
>> Lelio Fulgenzi wrote:
>>
>> > In order to get calling name ID working properly, we had to
>> check off
>> > the following parameter in our *Digital Access PRI* gateway:
>> >
>> > [x] Send Extra Leading Character In DisplayIE***
>> >
>> > Once we set that parameter, the special character that
>> appeared before
>> > the calling name (usually an ASCII graphic character) went
>> away, and
>> > all was well.
>> >
>> > However, now, when I get a call from some Cisco TAC
>> engineers (this is
>> > the only time I've seen it), the first letter of their name is
>> > missing. Instead of "Tom Smith", I see "om Smith".
>> >
>> > Has anyone else run into this?
>> >
>> > Just thought I'd send a note out before I open a case with
>> the TAC on
>> > this. I'm worried that between some CallManager-to-CallManager
>> > communications, this parameter is actually causing the
>> problem and if
>> > it's something that can be avoided if we decide to go with
>> some
>> > off-site CCM installations.
>> >
>> > Lelio
>> >
>> >
>> --------------------------------------------------------------------------------
>> > Lelio Fulgenzi, B.A.
>> > Network Analyst (CCS) * University of Guelph * Guelph,
>> Ontario N1G 2W1
>> > (519) 824-4120 x56354 (519) 767-1060 FAX (JNHN)
>> >
>> > "This signature may contain traces of nuts"
>> >
>> --------------------------------------------------------------------------------
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >cisco-voip mailing list
>> >cisco-voip at puck.nether.net
>> >https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20040810/a0033964/attachment.html
More information about the cisco-voip
mailing list