By the way, why the BBGK endpoint does not send the TCS?
On Fri, Dec 2, 2011 at 10:02 PM, ccielabrat <ccielab...@gmail.com> wrote:
> Hi Ash,
>
> Thanks very much for taking the time to reply.
> I would really like to understand all the pieces to this scenario.
>
> The debug I posted was from the HQ router/GK/CUBE, I'm not sure how to
> read it yet, so I can't say what call leg it represents.
>
> We are talking about the same scenario you mention in your reply.
>
> CUCM via GK-0Trunk (No MTP configured) (Wait for H245 unchecked)
> GK configured with a Remote Zone using a outvia to local CUBE.
> CUBE is configured with One inbound dial-peer 011! with a fixed codec of
> g.711 and an outbound dial-peer targeting RAS (default g.729)
> The call setup works and I can answer the call but the rtp never works.
>
> Please confirm my understanding of the problem.
> 1.) CUCM does ARQ/setup via GK
> 2.) GK sends LRQ to BBGK and gets LCF that it's a routable DN
> 3.) GK tells CUCM to target CUBE for H.323 call setup because of Outvia
> config for BBGK Zone.
> 4.) CUCM sends H.225 to CUBE which triggers CUBE to do H.225 to endpoint
> in BBGK Zone.
> 5.) CUBE waits for h.245 TCS and doesn't send H.225 connect back to CUCM
> 6.) BBGK Endpoint doesn't send any TCS and causes CUBE to wait /timeout
> for H.245
> 7.) Call fails with CUBE disconnecting both BBGK call leg and CUCM call
> leg.
>
> I think this is due to the fact that CUCM (without MTP) is forced to do
> slow start , while CUBE will automatically do fast start.
> As I understand , CUBE can't compensate for the difference between
> slow/fast start call legs.
>
> So is the only option to have an MTP configured at CUCM side?
> Can the CUBE be forced to do slow start? Would that fix the issue?
>
>
>
>
> On Fri, Dec 2, 2011 at 1:20 AM, Ashraf Ayyash <ash.ayy...@gmail.com>wrote:
>
>> What are you looking at in the debugs and which leg is this ?
>>
>> you said you have CUBE in between so you will see 2 seprated H245
>> negotiation for each leg ,
>>
>> can you post the H225 and h245 debugs for me please ?
>>
>> just to make sure that we both talking about the same thing , this
>> call is Slow start and you have CUBE with Transcoder in it and the
>> issue you trying to trace is that once you connected the call it got
>> dropped by the remote GK ?
>>
>> On the CUBE you have inbound dial-peer with codec G711 and outbound
>> dial-peer with G729 and then you have transcoder to fix this in the
>> cube , but on the remote GK you have dial-peer with G711u call only,
>>
>> if any of the above is not what you have please correct me ,
>>
>>
>>
>> Ash
>>
>> On Thu, Dec 1, 2011 at 2:53 PM, ccielabrat <ccielab...@gmail.com> wrote:
>> > ok, I'm getting to understand this better.
>> >
>> > I don't see any mention of a tcs failure though
>> > See the output of debug h245 asn1 below. Where is the indication of a
>> > failure?
>> >
>> > Also, I have CUBE running with a Hw transcoder registered locally on HQ
>> > telephony-service.
>> > I would think the CUBE should allocate the xcoder to get around the
>> codec
>> > mismatch.
>> >
>> > Output from Debug of H245 ASN1 on HQ/GK/CUBE
>> >
>> > Dec 1 20:45:36.806: h245_decode_one_pdu: more_pdus = 0,
>> bytesLeftToDecode =
>> > 97
>> > Dec 1 20:45:36.806: H245 MSC INCOMING ENCODE BUFFER::=
>> >
>> 0270010600088175000A801380003C000100000100000100000CC00100010006800000240001058000012408010580000222800580000322C00580000485014080000585011080002B85015000800002030000000100020003010004000500002B
>> > Dec 1 20:45:36.806:
>> > Dec 1 20:45:36.806: H245 MSC INCOMING PDU ::=
>> >
>> > value MultimediaSystemControlMessage ::= request :
>> terminalCapabilitySet :
>> > {
>> > sequenceNumber 1
>> > protocolIdentifier { 0 0 8 245 0 10 }
>> > multiplexCapability h2250Capability :
>> > {
>> > maximumAudioDelayJitter 60
>> > receiveMultipointCapability
>> > {
>> > multicastCapability FALSE
>> > multiUniCastConference FALSE
>> > mediaDistributionCapability
>> > {
>> >
>> > {
>> > centralizedControl FALSE
>> > distributedControl FALSE
>> > centralizedAudio FALSE
>> > distributedAudio FA
>> > HQ#LSE
>> > centralizedVideo FALSE
>> > distributedVideo FALSE
>> > }
>> > }
>> > }
>> > transmitMultipointCapability
>> > {
>> > multicastCapability FALSE
>> > multiUniCastConference FALSE
>> > mediaDistributionCapability
>> > {
>> >
>> > {
>> > centralizedControl FALSE
>> > distributedControl FALSE
>> > centralizedAudio FALSE
>> > distributedAudio FALSE
>> > centralizedVideo FALSE
>> > distributedVideo FALSE
>> > }
>> > }
>> > }
>> > receiveAndTransmitMultipointCapability
>> > {
>> > multicastCapability FALSE
>> > multiUniCastConference FALSE
>> > mediaDistributionCapability
>> > {
>> >
>> > {
>> > centralizedControl FALSE
>> > distributedControl FALSE
>> > centralizedAudio FALSE
>> > distributedAudio FALSE
>> > centralizedVideo FALSE
>> > distributedVideo FALSE
>> > }
>> > }
>> > }
>> > mcCapability
>> > {
>> > centralizedConferenceMC FALSE
>> > decentralizedConferenceMC FALSE
>> > }
>> > rtcpVideoControlCapability FALSE
>> > mediaPacketizationCapability
>> > {
>> > h261aVideoPacketization FALSE
>> > }
>> > logicalChannelSwitchingCapability FALSE
>> > t120DynamicPortCapability FALSE
>> > }
>> > capabilityTable
>> > {
>> >
>> > {
>> > 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 receiveAndTransmitUserInputCapability : dtmf : NULL
>> > },
>> > {
>> > capabilityTableEntryNumber 6
>> > capability receiveAndTransmitUserInputCapability :
>> basicString :
>> > NULL
>> > },
>> > {
>> > capabilityTableEntryNumber 44
>> > capability receiveAndTransmitUserInputCapability : hookflash :
>> > NULL
>> > }
>> > }
>> > capabilityDescriptors
>> > {
>> >
>> > {
>> > capabilityDescriptorNumber 0
>> > simultaneousCapabilities
>> > {
>> >
>> > {
>> > 1,
>> > 2,
>> > 3,
>> > 4
>> > },
>> >
>> > {
>> > 5,
>> > 6
>> > },
>> >
>> > {
>> > 44
>> > }
>> > }
>> > }
>> > }
>> > }
>> >
>> >
>> >
>> > Dec 1 20:45:36.810: h245_decode_one_pdu: H245ASNDecodePdu rc = 0,
>> > bytesLeftToDecode = 0
>> > Dec 1 20:45:36.810: h245_decode_one_pdu: Read Pkt body: more_pdus:0
>> rc:0
>> > asn_rc:0
>> > HQ#
>> > HQ#
>> > HQ#
>> > HQ#sho deb
>> >
>> > H.245:
>> > H.245 ASN1 Messages debugging is on
>> >
>> >
>> >
>> > On Thu, Dec 1, 2011 at 2:00 PM, Ashraf Ayyash <ash.ayy...@gmail.com>
>> wrote:
>> >>
>> >> The ccapi debug will show you the cause code which doesn't explain why
>> >> the call failed ,
>> >>
>> >> you have to debug the h245 asn1 and check the TCS and see the codecs
>> >> advertised and received and then you will get the TCS negotiation
>> >> failure so you can explain that there is codec mismatch
>> >>
>> >> Ash
>> >>
>> >> On Thu, Dec 1, 2011 at 11:55 AM, Mohd Baqari <baqari.voic...@gmail.com
>> >
>> >> wrote:
>> >> > Use the command debug voice ccapi inout. H323 debugs won't show in
>> this
>> >> > case.
>> >> >
>> >> > Regards,
>> >> > Mohammed Al Baqari
>> >> >
>> >> > Sent from my iPhone
>> >> >
>> >> > On Dec 1, 2011, at 6:12 PM, ccielabrat <ccielab...@gmail.com> wrote:
>> >> >
>> >> >> I'm trying to setup a call from HQ CUCM via GK-Trunk to a Remote Gk
>> >> >> Zone.
>> >> >>
>> >> >> I have the Gatekeeper configured with OutVia for the remote zone
>> >> >> referencing a CUBE on the HQ router.
>> >> >>
>> >> >> I didn't realize (but it makes sense now) that with "Wait for H.245"
>> >> >> unchecked on on the CUCM trunk, the call setup goes to the GK/CUBE
>> as g.711.
>> >> >>
>> >> >> This obviously causes a problem when the CUBE (by default) tries to
>> >> >> create the outgoing call leg to the remote zone using G.729.
>> >> >>
>> >> >> I don't have an XCoder available to CUBE at this point.
>> >> >>
>> >> >> My problem is that I can't see the codec mismatch failure in "debug
>> >> >> cch323 h225 " or "debug cch323 h245".
>> >> >> (If it's in there , I'm not seeing :) )
>> >> >>
>> >> >> Can someone help me understand if the failure is noted in either of
>> >> >> these debugs
>> >> >> Or
>> >> >> Point me towards a debug that would show the codec mismatch problem?
>> >> >>
>> >> >>
>> >> >>
>> >> >> _______________________________________________
>> >> >> 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 <http://www.platinumplacement.com/>
>> >> > _______________________________________________
>> >> > 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 <http://www.platinumplacement.com/>
>> >
>> >
>>
>
>
> _______________________________________________
> 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 <http://www.platinumplacement.com/>
>
_______________________________________________
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
