Summary:	ASTERISK-08336: SIP HOLD propegation to AST_CONTROL
Reporter:	Andrew Edem (andrewedem)	Labels:
Date Opened:	2006-12-12 06:57:48.000-0600	Date Closed:	2007-01-29 10:41:51.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	As of asterisk 1.4.0-beta3, the SIP driver still does not properly propagate the HOLD state of the channel using AST_CONTROL. This can be seen in sip_indicate where AST_CONTROL_HOLD and AST_CONTROL_UNHOLD simply start and stop music on hold instead of sending a re-INVITE. ****** ADDITIONAL INFORMATION ****** In the very least it should be possible to get the channel to send a re-INVITE with recvonly/sencrecv when the bridged channel goes on or off hold. This would make asterisk much more useful as a ISDN-SIP-ISDN gateway as currently the hold is not propagated end-to-end, since the SIP channel driver will play MOH, which is not desirable for many carriers, although it may be nice for an office PBX.
Comments:	By: Joshua C. Colp (jcolp) 2006-12-12 10:07:40.000-0600 The changes weren't originally designed to do what you want but aye, they could be used to make the hold propogate through to the remote end. It would definitely need to be an option, turned off by default, and only in trunk. By: Russell Bryant (russell) 2006-12-12 13:06:22.000-0600 Actually, the redisign of hold signalling was intended to have the ability to propogate the signalling if configured to do so.  I implemented this in chan_iax2 and in chan_zap, but did not do it for chan_sip because I didn't know the proper thing to do at the time.  I was hoping someone would come behind me to implement it, or at least tell me what should be done.  Then, over time, I forgot all about it ... By: Russell Bryant (russell) 2006-12-12 13:09:17.000-0600 To be honest, this is something that I would consider for inclusion in 1.4 if we can get it implemented very soon, and get the implementation signed off on by oej. By: Andrew Edem (andrewedem) 2006-12-12 15:47:08.000-0600 It isn't too difficult, we just need to adjust the SDP and send a reinvite to the peer when the CONTROL frame is received. The main issue I see is the ONHOLD_SENDONLY and ONHOLD_INACTIVE since it will be easy to loose state. First, lets say we add a flag; call it BRIDGED_ONHOLD. Now, we introduce the following logic when we create the SDP: If BRIDGED_ONHOLD && !ONHOLD_SENDONLY && !ONHOLD_INACTIVE, send "sendonly" in SDP. If !BRIDGED_ONHOLD && ONHOLD_SENDONLY && !ONHOLD_INACTIVE, send "recvonly" in SDP If (BRIDGED_ONHOLD && ONHOLD_SENDONLY) || ONHOLD_INACTIVE, send "inactive" in SDP otherwise, send "sendrecv" in SDP. OK, so that's straight forward. The more difficult thing is understanding what to do when we get the SDP from the peer. Let's say the bridged channel is on hold (BRIDGED_ONHOLD). In this case, the peer should send an SDP with "recvonly" in response to our reinvite, as per RFC. That's fine, no problems here. Now, let's say the peer goes on hold as well. As per RFC, the peer would send "inactive" in a reinvite (because it is already "recvonly"), and we would send "inactive" in the response. However, as the code is currently structured, our channel would end up with the ONHOLD_INACTIVE flag set. So, if the bridged channel goes off of hold first, we SHOULD send a re-invite with the "recvonly" sdp, but in this case we still send "inactive". Maybe this is not the end of the world, but it is not the correct behavior. By: Olle Johansson (oej) 2006-12-15 05:00:28.000-0600 This is a feature request and I think it's too late to include it in 1.4. It's on my todo-list and was, as Russell said, part of the plan with the new on hold signalling. By: Olle Johansson (oej) 2007-01-23 02:28:20.000-0600 Closing this, keeping it in archive in the "feature requests" category.