[Home]

Summary:ASTERISK-24065: ooh323 irregularities in the sequence of TCS/MSD/OLC after TCS=0
Reporter:Alexander Vysokovskih (laowai)Labels:
Date Opened:2014-07-20 23:38:10Date Closed:
Priority:MajorRegression?No
Status:Open/NewComponents:Addons/chan_ooh323
Versions:11.11.0 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Putting call on hold or transfer the call to asterisk from CUCM (SlowStart,Tunneling OFF). Attachments:( 0) call.bad.txt
( 1) call.good.txt
( 2) ooh245.hold.patch
Description:We have a irregularities in the sequence of TCS/MSD/OLC from asterisk after receiving EmptyCapabilitySet request (TCS=0). In this case CUCM (SlowStart, Tunneling OFF) does not work correctly after putting call on hold of transfer the call to asterisk.
Comments:By: Alexander Vysokovskih (laowai) 2014-07-20 23:41:25.265-0500

Here the patch for correting TCS/MSD/OLC order in case of receiving TCS=0.
By: Alexander Anikin (may213) 2014-07-22 10:40:28.253-0500

Hi Alexander,
Looks like to CUCM reestablish MasterSlaveDetermination procedure after back call from hold. I'm not sure what all h.323 endpoints do so.
Could you attach capture file with signalling data between asterisk and cucm in this case?
By: Alexander Vysokovskih (laowai) 2014-07-23 00:12:22.700-0500

Alexander,

CUCM use EmptyCapabilitySet as "method" of putting on hold as well as returning from hold and as well as transfer the call.
According to ITUs TCS/MSD negotiations required before OLC negotiation. Currently in this case chan_ooh323 send OLC before MSD negotiation.

By: Alexander Vysokovskih (laowai) 2014-07-23 00:14:42.645-0500

call.good shows exchange after fixing. In both files TCS at ~ 10sec represent ECS (TCS=0)
By: Alexander Anikin (may213) 2014-07-23 03:54:42.326-0500

Alexander,
Looks like you're right that both TCS and MSD required for resuming call (when non-emptyTCS received).
Will do few checking about the code then commit changes.
Thank you