Hi Jason, My proctor labs session has ended, and I cannot test this anymore today. But I was checking here my home lab, and the default value for Wait for far end TCS in Device > Gateway is "checked", and not "unchecked". So by default CUCM waits for the PSTN router's TCS. I am not getting into a stalemate condition, since I can see the TCS coming from the PSTN. So maybe if I uncheck this, CUCM will send the first TCS message, and the PSTN router may answer me with a clearer message... I will try in my next session.
Regarding the note "For intercluster trunks and gatekeeper-controlled intercluster trunks, the Wait for Far-End to Send TCS option is always disabled and cannot be enabled.", this is not what I saw in SDI traces... in the traces, CUCM received the TCS from PSTN, and then it sent his TCS. But maybe this is a timestamp issue when displaying the messages in the logs... Yes, but it really makes sense. If Device >> gateway by default "waits for far end tcs", and ICT never waits, that explains the different behavior between them. I will make more tests in my next session. Thanks a lot, Bruno On Fri, Aug 24, 2012 at 4:40 PM, Jason Aarons (AM) < [email protected]> wrote: > Please correct me if necessary. I’ve done some limited home testing on > ICT vs Device > Gateway.**** > > ** ** > > My understanding from the SRND is that Device > Trunk ICT Non-gatekeeper > should only be used with another CallManager/Cluster. With Trunk > H323 > Non-Gatekeeper Controlled TCS is always sent. I’m also wondering if > anything non-standard is sent as it expects the other end to be a > CallManager/Cluster.**** > > ** ** > > With Device > Gateway the default is unchecked Wait for Far End H.245 > Terminal Capability Set. Depending on who becomes Master/Slave you might > not see a TCS Reject but instead the Master (be sure to understand MSD and > be able to tell who is Master) sending a disconnect without a definitive > proof of why. I would then check Wait for Far End H.245 Terminal > Capability Set and review SDI/SDL traces for TCS problems, however if the > other side doesn’t send TCS I have a Stalemate and can’t show proof TCS is > the problem, only how I did my troubleshooting that problem is far end > configuration.**** > > ** ** > > ** ** > > References**** > > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/callpros.html** > ** > > ** ** > > ICT Non-Gatekeeper Controlled**** > > > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/trunks.html#wp1044701 > **** > > ** ** > > http://www.mail-archive.com/[email protected]/msg27089.html** > ** > > ** ** > > > http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/7x/video.html#wp1046354 > **** > > Note: For intercluster trunks and gatekeeper-controlled intercluster > trunks, the Wait for Far-End to Send TCS option is always disabled and > cannot be enabled.**** > > ** ** > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *Bruno Nonogaki > *Sent:* Friday, August 24, 2012 2:11 PM > *To:* [email protected] > *Subject:* [OSL | CCIE_Voice] H.323 Troubleshooting**** > > ** ** > > > > Hello guys, > > I was practicing some troubleshooting today, making some changes in the > PSTN router and analysing the SDI traces. > And I found out in a codec mismatch situation, the trace is different if I > configure the trunk as an H.323 gateway or as an Inter Cluster Trunk (non > GK controlled). > > If I configure an ICT, I can clearly see the incoming TCS from the PSTN > supporting g711u, then the outgoing TCS from CUCM saying it supports g729 > only. > And finally the PSTN sends a terminalCapabilitySetReject, and the call is > released with cause code C1 (which is Bearer capability not implemented). > > But if I configure an H.323 gateway, I can only see the incoming TCS from > the PSTN saying it supports g711u only, and after that, the call is > released. CUCM does not send its TCS, and I cannot see any > terminalCapabilitySetReject message. > The cause code now is AF (which is Resources unavailable, unspecified: The > channel or service that the user requests is unavailable for an unknown > reason. This problem is usually temporary.) > > Is this the correct behavior? So how can I explain a codec mismatch > situation in a H.323 gateway, since no message clearly says that? > > Thanks, > > Bruno > > > > > > > > itevomcid **** > >
_______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com Are you a CCNP or CCIE and looking for a job? Check out www.PlatinumPlacement.com
