Our topology as below
IP Phone 1(XXXX) (HQ region) ----CUCM-----H323 GW (Region X) ----Avaya IPPBX ---Phone 2 (YYYY)
Codec relation between HQ Region and Region X is G729 .
we uncheck box of wait for far end H245 Terminal capability set as Avaya side requirements . Aslo Codec of outbound fast start is G729.
Dial peer on GW which connect to Avaya PBX use G729 default Codec.
Issue : when make a call from Phone 1 to Phone 2 , we noticed that codec is G711ulaw from Phone 1 side , and the transcoder on VG involved in that call with two legs one for IP Phone 1 (G711ulaw) and another leg for (Avaya PBX g729) .
Strange behavior also is when we try to shutdown this transcoder profile on VGW and make another call , we noticed that two call legs become G729 , which must be happened also when transcoder is on .
Please check SDL logs of tested call when transcoder is on and output of below debugs (Download from URL Below)
debug voip ccapi inout
debug h225 asn1
debug h245 asn1
debug cch323 all
debug ip tcp transaction
Solved! Go to Solution.
Hi R A,
When i was going through your GW logs i could get the following informations, i see only one call where G729 was the negotiated Codec and in CUCM SDL logs i don't find that call.
CUCM's IP : 10.6.10.47
++ Incoming H225 setup from your CUCM
373136: *Sep 18 14:08:52.492: H225.0 INCOMING PDU ::=
value H323_UserInformation ::=
h323-message-body setup :
373140: *Sep 18 14:08:52.493: //-1/xxxxxxxxxxxx/H323/cch323_h225_receiver: Received msg of type SETUPIND_CHOSEN
373141: *Sep 18 14:08:52.493: //24431/00DB63391300/H323/setup_ind: callingNumber calledNumber
373148: *Sep 18 14:08:52.493: //24431/00DB63391300/H323/copy_recv_rawMsg:exit@674cch323_ip_best_local_address: IP 10.6.44.200 found for bound IDB GigabitEthernet0/0/1
373183: *Sep 18 14:08:52.495: //24431/00DB63391300/H323/cch323_set_preferred_codec: Not using Voice Class Codec
24431 - CI between CUCM <> and H323 GW
24432 - CI between H323 GW <> ISP
++ Looks like G729 is set as default codec
373323: *Sep 18 14:08:52.507: //24432/00DB63391300/H323/cch323_set_pref_codec_list: First preferred codec(bytes)=16(20)
373324: *Sep 18 14:08:52.507: //24432/00DB63391300/H323/cch323_get_peer_info: Preferred codec set to G729IETF with Bytes = 20
375172: *Sep 18 14:08:53.600: H225.0 OUTGOING PDU ::=
value H323_UserInformation ::=
h323-message-body connect :
++ between both ends H323 GW <> ISP G729 is negotiated
375183: *Sep 18 14:08:53.602: //24431/00DB63391300/H323/h323_set_rtcp_session: raddr(10.6.44.200), rport(27338),media_ip_addr(10.6.44.200)
375184: *Sep 18 14:08:53.602: //24431/00DB63391300/H323/h323_get_mode_for_rtp:
375185: *Sep 18 14:08:53.602: //24431/00DB63391300/H323/h323_common_setup_rtcp_parameters: updating RTP session type, ccb->status = 4810A603,
olc->rtcp_session.type = 3, do_rtcp = 1, iwf_state = 10,
negotiated_codec = G729IETF, mediaWait = 0, h245_lport = 27332,
375610: *Sep 18 14:09:07.679: //24432/00DB63391300/H323/h323_common_setup_rtcp_parameters: updating RTP session type, ccb->status = FFFFFFFF8810261B,
olc->rtcp_session.type = 2, do_rtcp = 1, iwf_state = 10,
negotiated_codec = G729IETF, mediaWait = 0, h245_lport = 27334,
If you can re-produce the issue and collect the logs on both ends GW and CUCM will be good to look into it again. Also make sure the Region between IP phone and H323 GW has G711 as a preferred codec.