[cisco-voip] First character missing from calling name ID on some calls from Cisco TAC engineers

[Lelio Fulgenzi]

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
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 
  To: Lelio Fulgenzi 
  Cc: 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/d75d8abb/attachment-0001.html