|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|
|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.