02-25-2008 05:33 PM - edited 03-17-2019 09:17 PM
Hi,
Topology:
[Intercom] -> fxo--[gw 2821] -> [cucm5] -- [phone 41851]
The configuration:
dial-peer voice 41851 voip
destination-pattern 41851
session target ipv4:172.26.240.10
dtmf-relay h245-signal
codec g711ulaw
voice-port 0/0/0
cptone CA
timeouts call-disconnect 5
timeouts wait-release 5
connection plar 41851
station-id name Intercom4
station-id number 00004
caller-id enable
I suspect that some configurations are missing. please help.
Please refer to the attachment for output of debug vpm signal and deb voice dialpeer.
Thanks,
Jon
Solved! Go to Solution.
02-27-2008 10:47 AM
Hi Jon,
It may be necessary to shut/no shut the voice port to have the changes take effect.
If not, then it would seem that any caller-id information received from the VG224 phone overrides the station-id configs. Can you configure the VG224 phone to not send any caller-id information.
In the planned topology, the FXO port was connected to the Intercom system. Would the intercom system be sending caller-id information like the VG224 phone is doing? If not, then the station-id info would be sent.
Regards,
Michael.
02-25-2008 09:09 PM
Jon,
Looks like you are getting battery reversal on the line.
*Feb 26 02:05:53.987: htsp_process_event: [0/0/0, FXOLS_OFFHOOK, E_DSP_SIG_0110]fxols_offhook_rvs_battery
Try disabling battery-reversal on this port and test it again.
router(config)# voice-port 0/0/0
router(config-voiceport)# no battery-reversal
Regards,
/mao
02-26-2008 08:30 AM
Thanks for reply, Mao. disabling battery reversal doesn't resolve it. Do I have to add a H.323 gateway on CallManager to make this work? I haven't done that yet.
Thanks,
Jon
02-26-2008 08:39 AM
Hi Jon,
Yes, the H.323 gateway needs to be added in CCM.
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080094636.shtml
Once added, test once again and let us know what happens.
Regards,
Michael.
02-26-2008 09:19 AM
Hi, Michael,
The h323 gw was added with default configurations in ccm now. the router's config is like this:
voice-port 0/0/0
no battery-reversal
cptone CA
timeouts call-disconnect 5
timeouts wait-release 5
connection plar 41851
station-id name Intercom4
caller-id enable
dial-peer voice 41851 voip
destination-pattern 41851
session target ipv4:172.26.240.10
dtmf-relay h245-alphanumeric
codec g711ulaw
Good news is the phone 41851 now rings, however, I hear busy tone once the call is answered.
Thanks,
Jon
02-26-2008 09:24 AM
I haven't configured the route pattern using the h323 gw in ccm. 'Cause this is gonna be one-way calling, from an intercom device to IP Phone. Do I need to configure it?
Thanks
02-26-2008 09:50 AM
If it is only one-way calling to the IP phone, then the route pattern is not required in the CallManager.
Could you please attach the output of these debugs while testing?
- debug cch323 h225
- debug cch323 h245
- debug voip ccapi inout
Thanks,
Michael.
02-26-2008 10:04 AM
02-26-2008 10:58 AM
It seems CCM is disconnecting the call, I think after waiting in vain for the gwy to begin H.245 negotiation.
*Feb 26 18:45:06.471: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type RELEASEIND_CHOSEN
*Feb 26 18:45:06.471: //46/C5B3BAA78044/H323/release_ind: Disconnect cause 47 location code 0
One more request Jon. There is a checkbox on the gateway configuration page in CCM called 'Wait for Far End H.245 Terminal Capability Set'. If this is checked, could you please uncheck it, then reset the gateway within CCM.
After making that change and before testing again, please add the following debugs on the gateway:
debug h225 asn1
debug h245 asn1
Also if you could include the detailed CCM traces from the CCM side to your attachment that would be great!
Regards,
Michael.
02-26-2008 11:29 AM
02-26-2008 12:11 PM
Jon,
We are getting closer, so bear with me a little. Here's the analysis of the last debugs from the gateways perspective.
When an H.323 call is being established, the H.245 negotiation allows the endpoints to agree on the properties of the call being established. One of the properties that must be agreed upon is the codec that will be used for the duration of the call. In this negotiation, each party specifies which codec it can support, and as long as they have at least one codec in common, then the call may proceed.
In this particular case, here is what the gateway sends to CCM as it advertises its capabilities.
*Feb 26 19:51:17.235: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
capability receiveAudioCapability : g711Ulaw64k : 20
Notice that the gateway indicates that it only supports G.711, which is the codec you have configured on the outbound voip dial-peer that is used to send the call to CCM.
And below is what the CCM advertises as the codecs that it phone in question is allowed to use.
*Feb 26 19:51:17.247: H245 MSC INCOMING PDU ::=
value MultimediaSystemControlMessage ::= request : terminalCapabilitySet :
capabilityTableEntryNumber 1
capability receiveAudioCapability : g729wAnnexB : 6
},
{
capabilityTableEntryNumber 2
capability receiveAudioCapability : g729AnnexAwAnnexB : 6
},
{
capabilityTableEntryNumber 3
capability receiveAudioCapability : g729 : 6
},
{
capabilityTableEntryNumber 4
capability receiveAudioCapability : g729AnnexA : 6
},
{
capabilityTableEntryNumber 5
capability receiveAudioCapability : g729AnnexA : 6
},
Notice also that phone is only allowed to use variants of G.729 codec.
So essentially the issue is one of a codec mismatch between the gateway and the called phone.
Shortly after the exchange above, the gateway released the call because none of the capabilities that were exchanged matched and no transcoder resource was available.
*Feb 26 19:51:17.255: H245 MSC OUTGOING PDU ::=
value MultimediaSystemControlMessage ::= response : terminalCapabilitySetReject :
One option that may resolve the issue to so configure the gateway to support G.729 as well. You could do this by modifying the configuration so that it looks like this:
!
voice class codec 1
codec preference 1 g729br8
codec preference 2 g729r8
codec preference 3 g711ulaw
!
dial-peer voice 41851 voip
destination-pattern 41851
session target ipv4:172.26.240.10
dtmf-relay h245-signal
voice-class codec 1
!
Other alternative options to fix the issue include configuring the Regions within CCM so that the codec used between the Region that the gateway is in and the one that the phone is in is G.711. Alternatively, providing access to a transcoder resource would allow the two endpoints to speak their different languages while the transcoder would act as a translator.
Lets try the modification to the gateway as above and lets see if that makes a difference.
Regards,
Michael.
02-26-2008 01:10 PM
Hi, Michael, we're getting closer now. I applied the voice class codec you posted. now call is established. however, only one way audio exists, which is from dialer to receiver 41851.
Thanks,
Jon
02-26-2008 01:37 PM
Thanks for the update, Jon. A couple of questions for you:
1. When the H.323 gateway was added in CCM, what is the IP address that was used for this?
2. Would you please depict the topology here once again? You mentioned previously that there was a VG2xx device involved as well, so I'd like to make sure we understand the full topology.
3. For clarification of the current issue, the IP phone user hears the calling party but that calling party does not hear the IP phone user - Is this correct?
4. Please recreate the current issue, and collect CCM traces once again from the CCM. In order to make sure we have the correct set of CCM traces, if you can, please set the trace level to detail, stop logging, delete existing trace log files, then start logging again before doing the test.
5. While the call is up, execute the following command on the gateway twice. Wait about 15 seconds before executing it the second time.
Thanks,
Michael.
02-26-2008 02:47 PM
Thanks a lot for diving into this, Michael.
1. When the H.323 gateway was added in CCM, IP address that was used is 172.26.240.243(this change since this test)
2. The final topology will be like this:
[Intercom] -> [fxo 0/1/0 on gw 2821(172.26.240.243)] -> [cucm5(172.26.240.10)] -- [phone 41851]
For the purpose of proving the configurations, I use this topology now:
[phone 41896] -> [ext 41740 of vg224] -> [fxo 0/1/0 on gw 2821(172.26.240.243)] -> [cucm5(172.26.240.10)] -- [phone 41851]
3. The receiver hears the calling party but that calling party does not hear the receiver - This is correct
4. Please see the newest trace and gw debug output from attachment.
02-26-2008 03:38 PM
Jon,
Do you have both 172.26.240.244 and 172.26.240.243 on the H.323 gateway?
* In previous traces, the H.323 gateway specified .244 as its address in the H.225 setup, but in the latest one, while performing capabilities exchange, it used .243. Was this as a result of a recent change?
* To remove any ambiguity, on the interface that has the .243, add the command h323-voip gateway bind' command so that all h.323 communication may use that address.
* From the traces:
- CCM tells the VG224 phone to startMediaTransmission with VG224 gateway while specifying the address to use for the VG224 gateway as 172.26.240.245
- CCM tells Destination IP phone (172.26.241.197) to startMediaTransmission with H.323 gateway while specifying the address to use for the gateway as 172.26.240.243
Can we verify that the subnet masks and default gateways of these devices are all correct, and also perform ping or other tests to confirm reachability between the 240 and 241 subnets?
Regards,
Michael.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide