I was just wondering if anybody has ever been involved in any installations/faults where Cisco PIX seems to be not allowing the VoIP stream to be established correctly when it tries to create a logical channel as of part H.245 between two IPO’s. In this scenario there is a simple VPN created between 2 PIX firewalls as one segment of the corporate WAN.
In the PIX we have the Fix up commands but still will not process the call.
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
Looks like 1720 – Call Setup is OK, as remote phones rings but the setup of the RTP Stream - Logical Channel gets no response from the remote end with a channel ID so no channel is opened and no speech path is heard.
This is exactly the same fault in the opposite direction. All IPO’s are running 3.0(59) PIX Version is 6.3(4) and the other side is 6.3(3)
All access list have been created to allow all traffic as per command line below on both PIX’s for correct subnets
access-list VPN permit ip 138.79.0.0 255.255.0.0 138.79.0.0 255.255.0.0
SCN is passing OK as you can see users and BLF status across the PIX VPN, just speech across the PIX environment when a call is made.
The IPO’s involved in the roll out are also connected via a Managed Private Network to other IPO’s approx five others not across PIX firewalls and they can create IP calls no issues. Issue simply seems relating to VoIP Calls across the PIX VPN and the way the PIX deals with H323v2 calls. I have done some research and it looks like this is a common issue but I can find not fix apart from the fix up commands which have been entered.
We did some further testing in our LAB with IPO’s Back to Back and you get the following Tracing from Sys-Monitor which is call with speech path OK.
This is a trace on 192.168.43.1 unpon pickup of the remote handset initialises H.245 channel allocation and transmits (CMLineTx) the port it wants to use as the Audio channel for this call
6348mS CMLineTx: v=0
CMConnect
Line: type=IPLine 0 Call: lid=0 id=1 in=2
Called[6201] Type=Default (100) Calling[6201] Type=Default (100)
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=AutoSelect (0) pktsize=0 ipaddr=192.168.42.150 port=0
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
Display [Extn6201]
The remote side (192.168.42.150) answers with the port it wants to use (CMLineRx) as part of H.245
6452mS CMLineTx: v=0
CMOpenLogicalChan
Line: type=IPLine 0 Call: lid=0 id=1 in=2
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
6460mS PRN: CMOLC locudpport 49290
6461mS PRN: Using g729AnnexA mf:2
6489mS PRN: LogicalChannels: HandleOpen
6489mS PRN: H245 Received open channel: 65793
6489mS PRN: Using g729AnnexA mf:2
6490mS PRN: Media Control Channel 192.168.42.150, 49213
6499mS CMLineRx: v=0
CMOpenLogicalChan
Line: type=IPLine 0 Call: lid=0 id=1 in=2
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
Both ends will then send acknowledgement of this if acceptable and proceed
CMLineTx: v=0
CMOpenLogicalChanAck
Line: type=IPLine 0 Call: lid=0 id=1 in=2
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
6508mS PRN: H245 Received open channel ack: 257
6508mS PRN: Media Channel 192.168.42.150, 49212
6509mS PRN: Media Control Channel 192.168.42.150, 49213
6509mS PRN: Media Channel 192.168.42.150, 49212
6512mS PRN: H245 Sending open channel ack: 65793
6513mS PRN: Media Channel 192.168.43.1, 49290
6513mS PRN: Media Control Channel 192.168.43.1, 49291
6522mS CMLineRx: v=0
CMOpenLogicalChanAck
Line: type=IPLine 0 Call: lid=0 id=1 in=2
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
We then looked at some tracing from one of the IPO’s connected across the PIX VPN and the Signalling for channel allocation does not come back with a Channel ID.
This is a partial trace from a IP call that successfully sets up, but no speech path is available. 138.79.161.4 is the local IP address. 138.79.227.4 is the remote end.
The H225=1720 setup is ok (phone rings and is answered).
420921mS CMLineTx: v=201
CMOpenLogicalChan
Line: type=IPLine 201 Call: lid=0 id=1 in=2
Called[7140] Type=Default (100)
BChan: slot=250 chan=9057
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.161.4 port=49236
Display [Peter Harms]
420922mS CMMap: a=250.9057 b=0.0 R1
420922mS PRN: Converted to:
420922mS CMMap: a=3.20 b=0.0 R1
420922mS CD: CALL: 201.1.2 BState=Ringing Cut=1 Music=2.0 Aend="Line 201" (250.9057) Bend="Peter Harms(7140)" [Peter Harms] (0.0) CalledNum=7140 () CallingNum=708 () Internal=0 Time=28 AState=Ringing
420923mS CMLineTx: v=201
CMAlerting
Line: type=IPLine 201 Call: lid=0 id=1 in=2
Called[7140] Type=Default (100)
BChan: slot=250 chan=9057
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.227.4 port=0
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.161.4 port=49236
Display [Peter Harms]
420927mS H323Evt: v=0 stacknum=201 State, new=Received, old=Present id=1
436040mS PRN: TCP: Trying to send in state 7
436041mS H323Evt: v=0 stacknum=201 State, new=ReleaseReq, old=Received id=1
436041mS H323Evt: v=0 stacknum=201 State, new=NullState, old=ReleaseReq id=1
We get back no CMLineRx: v=0
CMOpenLogicalChan
showing a handshake of the CMIETxChannelAudio ID, a few seconds later we see below when the other end gives up hearing DEAD air.
436055mS CMLineRx: v=201
CMReleaseComp
Line: type=IPLine 201 Call: lid=201 id=1 in=2
Cause=123, Forward To Voicemail(IPO)
Any help would be great
Umm anotherprivatebuild !!!
In the PIX we have the Fix up commands but still will not process the call.
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
Looks like 1720 – Call Setup is OK, as remote phones rings but the setup of the RTP Stream - Logical Channel gets no response from the remote end with a channel ID so no channel is opened and no speech path is heard.
This is exactly the same fault in the opposite direction. All IPO’s are running 3.0(59) PIX Version is 6.3(4) and the other side is 6.3(3)
All access list have been created to allow all traffic as per command line below on both PIX’s for correct subnets
access-list VPN permit ip 138.79.0.0 255.255.0.0 138.79.0.0 255.255.0.0
SCN is passing OK as you can see users and BLF status across the PIX VPN, just speech across the PIX environment when a call is made.
The IPO’s involved in the roll out are also connected via a Managed Private Network to other IPO’s approx five others not across PIX firewalls and they can create IP calls no issues. Issue simply seems relating to VoIP Calls across the PIX VPN and the way the PIX deals with H323v2 calls. I have done some research and it looks like this is a common issue but I can find not fix apart from the fix up commands which have been entered.
We did some further testing in our LAB with IPO’s Back to Back and you get the following Tracing from Sys-Monitor which is call with speech path OK.
This is a trace on 192.168.43.1 unpon pickup of the remote handset initialises H.245 channel allocation and transmits (CMLineTx) the port it wants to use as the Audio channel for this call
6348mS CMLineTx: v=0
CMConnect
Line: type=IPLine 0 Call: lid=0 id=1 in=2
Called[6201] Type=Default (100) Calling[6201] Type=Default (100)
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=AutoSelect (0) pktsize=0 ipaddr=192.168.42.150 port=0
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
Display [Extn6201]
The remote side (192.168.42.150) answers with the port it wants to use (CMLineRx) as part of H.245
6452mS CMLineTx: v=0
CMOpenLogicalChan
Line: type=IPLine 0 Call: lid=0 id=1 in=2
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
6460mS PRN: CMOLC locudpport 49290
6461mS PRN: Using g729AnnexA mf:2
6489mS PRN: LogicalChannels: HandleOpen
6489mS PRN: H245 Received open channel: 65793
6489mS PRN: Using g729AnnexA mf:2
6490mS PRN: Media Control Channel 192.168.42.150, 49213
6499mS CMLineRx: v=0
CMOpenLogicalChan
Line: type=IPLine 0 Call: lid=0 id=1 in=2
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
Both ends will then send acknowledgement of this if acceptable and proceed
CMLineTx: v=0
CMOpenLogicalChanAck
Line: type=IPLine 0 Call: lid=0 id=1 in=2
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
6508mS PRN: H245 Received open channel ack: 257
6508mS PRN: Media Channel 192.168.42.150, 49212
6509mS PRN: Media Control Channel 192.168.42.150, 49213
6509mS PRN: Media Channel 192.168.42.150, 49212
6512mS PRN: H245 Sending open channel ack: 65793
6513mS PRN: Media Channel 192.168.43.1, 49290
6513mS PRN: Media Control Channel 192.168.43.1, 49291
6522mS CMLineRx: v=0
CMOpenLogicalChanAck
Line: type=IPLine 0 Call: lid=0 id=1 in=2
BChan: slot=250 chan=9073
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.42.150 port=49212
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=192.168.43.1 port=49290
We then looked at some tracing from one of the IPO’s connected across the PIX VPN and the Signalling for channel allocation does not come back with a Channel ID.
This is a partial trace from a IP call that successfully sets up, but no speech path is available. 138.79.161.4 is the local IP address. 138.79.227.4 is the remote end.
The H225=1720 setup is ok (phone rings and is answered).
420921mS CMLineTx: v=201
CMOpenLogicalChan
Line: type=IPLine 201 Call: lid=0 id=1 in=2
Called[7140] Type=Default (100)
BChan: slot=250 chan=9057
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.161.4 port=49236
Display [Peter Harms]
420922mS CMMap: a=250.9057 b=0.0 R1
420922mS PRN: Converted to:
420922mS CMMap: a=3.20 b=0.0 R1
420922mS CD: CALL: 201.1.2 BState=Ringing Cut=1 Music=2.0 Aend="Line 201" (250.9057) Bend="Peter Harms(7140)" [Peter Harms] (0.0) CalledNum=7140 () CallingNum=708 () Internal=0 Time=28 AState=Ringing
420923mS CMLineTx: v=201
CMAlerting
Line: type=IPLine 201 Call: lid=0 id=1 in=2
Called[7140] Type=Default (100)
BChan: slot=250 chan=9057
IE CMIETxChannelAudio (1) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.227.4 port=0
IE CMIERxChannelAudio (2) comptype=G729A8K (6) pktsize=20 ipaddr=138.79.161.4 port=49236
Display [Peter Harms]
420927mS H323Evt: v=0 stacknum=201 State, new=Received, old=Present id=1
436040mS PRN: TCP: Trying to send in state 7
436041mS H323Evt: v=0 stacknum=201 State, new=ReleaseReq, old=Received id=1
436041mS H323Evt: v=0 stacknum=201 State, new=NullState, old=ReleaseReq id=1
We get back no CMLineRx: v=0
CMOpenLogicalChan
showing a handshake of the CMIETxChannelAudio ID, a few seconds later we see below when the other end gives up hearing DEAD air.
436055mS CMLineRx: v=201
CMReleaseComp
Line: type=IPLine 201 Call: lid=201 id=1 in=2
Cause=123, Forward To Voicemail(IPO)
Any help would be great
