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:10 | Date Closed: | |
Priority: | Major | Regression? | No |
Status: | Open/New | Components: | 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 |