[cisco-voip] Converting from H.323 to MGCP
Jason Aarons (US)
jason.aarons at us.didata.com
Thu Sep 14 18:13:43 EDT 2006
Lots of Nortel's can't do QSIG due to licensing/software limitation,
thus NI or Primary 5ess is used.
________________________________
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Voll, Scott
Sent: Thursday, September 14, 2006 5:55 PM
To: David Fielder (US); cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Converting from H.323 to MGCP
Are you sure Bellsouth is qsig? I thought qsig was for PBX type
connection and ni was more of a telco one? Am I out to lunch?
Scott
________________________________
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of David Fielder
(US)
Sent: Thursday, September 14, 2006 2:52 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Converting from H.323 to MGCP
I know this is a long message but any help would be appreciated.
I am experiencing a strange problem with a gateway conversion I am
doing. Attached are the debugs and configs. My client is running H.323
voice gateways and we are trying to switch them over to MGCP. So far I
have been only partially successfully at getting there Main gateway over
to MGCP. This is a 3745 with two NM-HDV2 2T1 so there are four PRI's
connected to this router with configurations as follows:
1/0 - configured but not functional
1/1 - PRI to Nortel PBX
Switch Type=Primary-ni
2/0 - Second PRI to Nortel PBX
Switch Type=Primary-ni
2/1 - PRI to the PSTN (Bellsouth)
Switch Type=Primary-qsig
The existing gateway configuration on the CallManager is configured to
use the following Plan and Types for H.323
Called Party Number Type = National
Called Numbering Plan = National Standard
Calling Party Number Type = National
Calling Numbering Plan = ISDN
I created a new Gateway in CallManager for MGCP which mirrored the H.323
for CSS, DP, and MRGL...etc. It also had the same numbering Plan and
Type for each port configured. I created three new Route Groups one for
connection to the PSTN and one each for the connections to the PBX. I
created two new Route Lists one for the port to the PSTN and one for the
ports to the PBX.
Below is the configuration I used on the IOS gateway:
ccm-manager fallback-mgcp
ccm-manager redundant-host 172.17.1.20
ccm-manager mgcp
!
controller T1 1/1
framing esf
linecode b8zs
pri-group timeslots 1-24 service mgcp
!
controller T1 2/0
framing esf
linecode b8zs
pri-group timeslots 1-24 service mgcp
!
controller T1 2/1
framing esf
linecode b8zs
pri-group timeslots 1-24 service mgcp
!
interface Serial1/1:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!
interface Serial2/0:23
no ip address
no logging event link-status
isdn switch-type primary-ni
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!
interface Serial2/1:23
no ip address
no logging event link-status
isdn switch-type primary-qsig
isdn incoming-voice voice
isdn bind-l3 ccm-manager
no cdp enable
!
mgcp
mgcp call-agent 172.17.1.21 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode out-of-band
!
mgcp profile default
!
dial-peer voice 1 pots
application mgcpapp
port 2/1:23
!
dial-peer voice 2 pots
application mgcpapp
port 1/1:23
!
dial-peer voice 3 pots
application mgcpapp
port 2/0:23
Once I completed the changes and pointed my Route Patterns to the
appropriate Route List. I was unable to make any four digit or external
calls out or in. Every time I would try to make a call out to the PSTN.
I would get the following message in the Q931 debugs:
Cause i = 0x829C - Invalid number format (incomplete number)
Sep 7 02:21:06.914: ISDN Se2/1:23 Q931: TX -> SETUP pd = 8 callref =
0x0006
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Calling Party Number i = 0x2881, '4879'
Plan:National, Type:National
Called Party Number i = 0xA1, '3154850'
Plan:ISDN, Type:National
Sep 7 02:21:06.982: ISDN Se2/1:23 Q931: RX <- STATUS pd = 8 callref =
0x8006
Cause i = 0x82E46C - Invalid information element contents
Call State i = 0x01
Sep 7 02:21:07.030: ISDN Se2/1:23 Q931: RX <- RELEASE_COMP pd = 8
callref = 0x
8006
I also captured a debug of successful calls when using H.323 and this is
the result of that debug:
Sep 7 02:01:25.344: ISDN Se1/0:23 Q931: pak_private_number: Invalid
type/plan 0
x2 0x8 may be overriden; sw-type 22
Sep 7 02:01:25.348: ISDN Se1/0:23 **ERROR**: CC_CHAN_GetIdleDMSChan:
Interface
de-Activated
Sep 7 02:01:25.348: ISDN Se1/0:23 **ERROR**: CCPMSG_OutCall: fails with
cause 0
x22
Sep 7 02:01:25.348: ISDN Se2/1:23 Q931: pak_private_number: Invalid
type/plan 0
x2 0x8 may be overriden; sw-type 22
Sep 7 02:01:25.352: ISDN Se2/1:23 Q931: Applying typeplan for sw-type
0x16 is 0
x0 0x0, Called num 6695129
Sep 7 02:01:25.352: ISDN Se2/1:23 Q931: TX -> SETUP pd = 8 callref =
0x02A5
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2181, '4879'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '6695129'
Plan:Unknown, Type:Unknown
Sep 7 02:01:25.780: ISDN Se2/1:23 Q931: RX <- CALL_PROC pd = 8 callref
= 0x82A
5
Channel ID i = 0xA98397
Exclusive, Channel 23
Sep 7 02:01:26.632: ISDN Se2/1:23 Q931: RX <- ALERTING pd = 8 callref
= 0x82A5
Progress Ind i = 0x8288 - In-band info or appropriate now
available
Sep 7 02:01:33.878: ISDN Se2/1:23 Q931: RX <- CONNECT pd = 8 callref =
0x82A5
Sep 7 02:01:33.882: ISDN Se2/1:23 Q931: TX -> CONNECT_ACK pd = 8
callref = 0x0
2A5
Sep 7 02:01:36.782: ISDN Se2/1:23 Q931: RX <- DISCONNECT pd = 8
callref = 0x82
A5
Cause i = 0x8290 - Normal call clearing
I noticed that even though the CallManger config for the gateway had the
called party plan and type as National and ISDN, they were showing in
the debug as Unknown. So I changed the Plan and Type for the MGCP
Gateway port 2/1 to match what I was seeing in the debugs for H.323 and
I was able to make calls out to the PSTN. That was working great.
However, I was still unable to make any calls to the PBX on the other
two ports. I changed the plan and type and I was then able to make calls
using my IP Communicator on my PC because I am making the changes
remotely but the people in the office were still unable to make any 4
digit calls. They were able to make calls to the PSTN. 4digit calls
coming in would make it to the destination but the person receiving the
calls would be unable to answer them. They were able to do a call
forward all to a cell phone and get the calls. I captured another Q931
debug for the four digit calls and was getting this information:
Sep 14 12:05:16.228: ISDN Se1/1:23 Q931: TX -> SETUP pd = 8 callref =
0x0013
Bearer Capability i = 0x8090A2
Standard = CCITT
Transer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98381
Exclusive, Channel 1
Display i = '4624'
Calling Party Number i = 0x2181, '4624'
Plan:ISDN, Type:National
Called Party Number i = 0x80, '3411'
Plan:Unknown, Type:Unknown
Sep 14 12:05:16.276: ISDN Se1/1:23 Q931: RX <- STATUS pd = 8 callref =
0x8013
Cause i = 0x81E3 - Information element not implemented
Call State i = 0x06
Sep 14 12:05:16.280: ISDN Se1/1:23 Q931: TX -> DISCONNECT pd = 8
callref = 0x00
13
Cause i = 0x80E2 - Message not compatible with call state or not
implement
Sep 14 12:05:16.324: ISDN Se1/1:23 Q931: RX <- RELEASE pd = 8 callref =
0x8013
Cause i = 0x81E4 - Invalid information element contents
Sep 14 12:05:16.332: ISDN Se1/1:23 Q931: TX -> RELEASE_COMP pd = 8
callref = 0x
0013
I have rolled them back to H.323 until I can resolve the issue. There
are six other gateways to convert and I don't want to run into the
problem there because they are not close by if I needed to go onsite for
any reason. I would appreciate any insight you guys might have on this
or any other troubleshooting steps you may recommend. I have verified
that the endpoints are up and the gateways are registered. I have
attached the full configs, debugs and sh vers for the gateway. I have
also opened a TAC case and they have been unhelpful so far. They did say
that the version of code was unsupported. I plan to upgrade the code
this weekend.
The version of code is 12.3(8)T3 and the CallManager is 4.1(3)sr3
David Fielder
Senior Engineer
Dimension Data
Office: (336) 510-9431
Mobile: (336) 669-5129
david.fielder at us.didata.com
________________________________
Disclaimer:
This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only. If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.
-----------------------------------------
Disclaimer:
This e-mail communication and any attachments may contain
confidential and privileged information and is for use by the
designated addressee(s) named above only. If you are not the
intended addressee, you are hereby notified that you have received
this communication in error and that any use or reproduction of
this email or its contents is strictly prohibited and may be
unlawful. If you have received this communication in error, please
notify us immediately by replying to this message and deleting it
from your computer. Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://puck.nether.net/pipermail/cisco-voip/attachments/20060914/8339e3fe/attachment-0001.html
More information about the cisco-voip
mailing list