[cisco-voip] Calling name from Avaya to Cisco Call Manager

Ryan Ratliff rratliff at cisco.com
Mon Nov 24 16:00:08 EST 2008


Notice the absence of any IE there indicating calling name.    If I were
presenting this to you (as the customer) I'd simply say the Avaya isn't
passing the name to CUCM so you should engage Avaya support to find out why.
 

-Ryan 

 

  _____  

From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Voice Noob
Sent: Monday, November 24, 2008 3:24 PM
To: Wes Sisk
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Calling name from Avaya to Cisco Call Manager


Has anyone else heard this? How can I present this as the problem to the
customer / PBX person?
 
Also here are some of the trac information. Does anyone know how to read
this stuff? :)
 

:15:33.910 CCM|In  Message -- H225SetupMsg -- Protocol=
H225Protocol|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::Significant><M
ASK::0040>

11/24/2008 14:15:33.910 CCM|Ie - H225BearerCapabilityIe -- IEData= 04 03 90
90 A5 |<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.910 CCM|Ie - Q931ProgressIndIe -- IEData= 1E 02 80 83
|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|Ie - H225CallingPartyIe -- IEData= 6C 0B 80 35
37 33 39 36 34 36 30 31 30
|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|Ie - Q931CalledPartyIe -- IEData= 70 05 80 33 33
33 38 |<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|Ie - H225UserUserIe -- IEData= 7E 00 C3 05 20 90
06 00 08 91 4A 00 05 3C C0 B5 00 4C 54 11 41 76 61 79 61 20 4D 75 6C 74 69
76 61 6E 74 61 67 65 0F 52 30 31 32 69 2E 30 32 2E 30 2E 31 31 31 2E 34 10
03 14 05 04 01 00 00 C0 2C 05 04 01 00 00 C0 3C 05 04 01 00 00 C0 20 01 01
80 66 6B 00 00 44 95 19 57 BD DD 01 B6 0D 48 41 3F C7 00 00 00 D5 1D 80 00
07 00 0A C8 01 32 06 B8 11 00 00 44 95 19 57 BD DD 01 B6 0D 48 41 3F C7 00
00 34 02 13 00 00 64 0C 60 13 80 0B 0F 00 01 00 0A C8 01 33 1F 69 00 1E 40
00 64 06 04 01 00 4C 60 13 80 12 15 00 01 00 0A C8 01 33 1F 68 00 0A C8 01
33 1F 69 00 01 00 01 80 01 00 01 00 10 80 01 80 00
|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|MMan_Id= 0. (iep=  0 dsl=  0 sapi=  0 ces= 0
IpAddr=3201c80a
IpPort=11044)|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|IsdnMsgData1= 08 02 58 BF 05 A1 04 03 90 90 A5
1E 02 80 83 6C 0B 80 35 37 33 39 36 34 36 30 31 30 70 05 80 33 33 33 38 7E
00 C3 05 20 90 06 00 08 91 4A 00 05 3C C0 B5 00 4C 54 11 41 76 61 79 61 20
4D 75 6C 74 69 76 61 6E 74 61 67 65 0F 52 30 31 32 69 2E 30 32 2E 30 2E 31
31 31 2E 34 10 03 14 05 04 01 00 00 C0 2C 05 04 01 00 00 C0 3C 05 04 01 00
00 C0 20 01 01 80 66 6B 00 00 44 95 19 57 BD DD 01 B6 0D 48 41 3F C7 00 00
00 D5 1D 80 00 07 00 0A C8 01 32 06 B8 11 00 00 44 95 19 57 BD DD 01 B6 0D
48 41 3F C7 00 00 34 02 13 00 00 64 0C 60 13 80 0B 0F 00 01 00 0A C8 01 33
1F 69 00 1E 40 00 64 06 04 01 00 4C 60 13 80 12 15 00 01 00 0A C8 01 33 1F
68 00 0A C8 01 33 1F 69 00 01 00 01 80 01 00 01 00 10 80 01 80 00
|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0040>

11/24/2008 14:15:33.911 CCM|value H323-UserInformation ::=
|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0100>

11/24/2008 14:15:33.912 CCM|SPROCRas - {

  h323-uu-pdu 

  {

    h323-message-body setup : 

      {

        protocolIdentifier { 0 0 8 2250 0 5 },

        sourceInfo 

        {

          vendor 

          {

            vendor 

            {

              t35CountryCode 181,

              t35Extension 0,

              manufacturerCode 19540

            },

            productId '4176617961204D756C746976616E746167 ...'H,

            versionId '52303132692E30322E302E3131312E34'H

          },

          gatekeeper 

          {

          },

          gateway 

          {

            protocol 

            {

              h320 : 

                {

                  supportedPrefixes 

                  {

                    {

                      prefix dialedDigits : "9"

                    }

                  }

                },

              h323 : 

                {

                  supportedPrefixes 

                  {

                    {

                      prefix dialedDigits : "9"

                    }

                  }

                },|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0100>

11/24/2008 14:15:33.913 CCM|SPROCRas - 

              voice : 

                {

                  supportedPrefixes 

                  {

                    {

                      prefix dialedDigits : "9"

                    }

                  }

                }

            }

          },

          mcu 

          {

          },

          mc TRUE,

          undefinedNode FALSE

        },

        destinationAddress 

        {

          dialedDigits : "3338"

        },

        activeMC FALSE,

        conferenceID '0044951957BDDD01B60D48413FC70000'H,

        conferenceGoal create : NULL,

        callType pointToPoint : NULL,

        sourceCallSignalAddress ipAddress : 

          {

            ip '0AC80132'H,

            port 1720

          },

        callIdentifier 

        {

          guid '0044951957BDDD01B60D48413FC70000'H

        },

        fastStart 

        {

          '0000640C6013800B0F0001000AC801331F ...'H,

          '400064060401004C60138012150001000A ...'H

        },

        mediaWaitForConnect FALSE,

        canOverlapSend
TRUE,|<CLID::StandAloneCluster><NID::10.200.1.60><LVL::State
Transition><MASK::0100>

11/24/2008 14:15:33.913 CCM|

        multipleCalls FALSE,

        maintainConnection FALSE

      },



On Thu, Nov 20, 2008 at 10:10 PM, Wes Sisk <wsisk at cisco.com> wrote:


I discussed this exact scenario with an Avaya PBX guy last week. He
indicated it was an intenational limitation on the avaya side and that
additional load (?) was specifically required to enable this passing of
cname between trunks.  unfortunately I did not get the name of the
load/package/option.

/wes 


On Wednesday, November 19, 2008 9:35:30 AM, Voice Noob
<mailto:voicenoob at gmail.com> <voicenoob at gmail.com> wrote:


I am having a problem getting calling name to work correctly. I have an
Avaya system, not sure on the specs on it, that is connected to a CUCM 6.1
system. All PSTN connectivity goes through the Avaya system first and is
then sent via H.323 to CUCM. If I call from Cisco phone to Avaya I get
calling name. If I call from Avaya to Cisco I get calling name. If an
outside caller from the PSTN calls an Avaya phone they get calling name. If
a PSTN caller calls into the system and is rerouted to a Cisco phone they do
not get calling name.  What could be the causes of this and where should I
start to troubleshoot this issue. Thanks for everyone's help. 



  _____  


_______________________________________________

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/20081124/1e927c42/attachment-0001.html>


More information about the cisco-voip mailing list