Summary:	ASTERISK-12319: [patch] SIP channel cannot handle FLASH HOOK INFO message sent by SIP device
Reporter:	Alisher (licedey)	Labels:
Date Opened:	2008-07-05 08:57:32	Date Closed:	2011-06-07 14:02:42
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/NewFeature
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) chan_sip.diff ( 1) log.pcap ( 2) log1.pcap
Description:	Currently Asterisk/SIP response with Warning messages to FLASH HOOK events. [Jul  5 22:58:15] WARNING[31979]: chan_sip.c:4015 sip_indicate: Don't know how to indicate condition 9 [Jul  5 22:58:15] WARNING[31979]: channel.c:2420 ast_indicate_data: Unable to handle indication 9 for 'SIP/1982-095d1088' ****** ADDITIONAL INFORMATION ****** Some devices, such as this: http://www.audiocodes.co.il/asp/DoDownload2.asp?ID=6312 send SIP INFO Header = application/broadsoft; version = 1.0 and  SIP INFO Body = event flashhook To support this event we can add few lines to chan_sip.c [[[code removed]]]
Comments:	By: Tilghman Lesher (tilghman) 2008-07-05 10:03:52 Do NOT place patches in the description or additional info field.  All patches must be marked as code and uploaded into the file upload area, along with an appropriate license. By: Alisher (licedey) 2008-07-05 10:41:29 I have uploaded the sip dump, of flashhook event, which illustrates how ISP handles flash hook. This can help to add same support to asterisk. I uploaded the patch. This is a work around patch that bypasses the flash hook event to ISP. By: Olle Johansson (oej) 2008-07-05 13:10:43 ...and if you read the bug guidelines, we need a SIP debug output from Asterisk, not a pcap file. Reading bug guidelines is always helpful to make the process more simple for all of us. Thanks, /O By: Olle Johansson (oej) 2008-07-05 13:12:24 I don't really appreciate yet another method used for signalling of events, like "application/broadsoft". If we're going to support that, we need to check the specification and find out more of these events and figure out when and how and if we need to send them too. By: Olle Johansson (oej) 2008-07-05 13:17:00 Can't this device be configured to send Flash hook over RTP/DTMF 2833 instead? By: Alisher (licedey) 2008-07-05 18:55:37 I uploaded pcap instead of SIP debug output from Asterisk, because sip channel doesn't supports FLASH hook. The devices that send FLASH hook events over RTP/DTMF 2833/INFO also suffer from same issue, since asterisk just ignores it with warning message. I doesn't neccessary to implement application/broadworks events to chan_sip, asterisk should be able to handle flash hook events over  RTP/DTMF 2833/INFO/INBAND same was as "application/broadworks mechanism" does. By: Alisher (licedey) 2008-07-05 19:18:57 Flash based services support: IP phone shall support Flash-based Service Support via INFO Method with a proprietary extension to the INFO method to support flash-based user services such as call waiting, call transfer, three-way calling, and so on. The extension includes the definition of a new value for the Content-Type header. The new value is: application/broadsoft.   The application/broadsoft Content-Type allows an endpoint to notify VoIP platform that a flash hook has occurred or to direct an endpoint to play a tone, as specified by the VoIP solution.   The Content-Type of application/broadsoft indicates that a proprietary body is in the message. The body must be in one of the following formats in order for VoIP solution or the endpoint to interpret the intention: (These fields are not case sensitive.)   o  event <event name>   o  play tone <tone name>   o  stop <tone name>   Optionally, the play tone body may contain the following body parts to communicate call waiting calling party identification information. Note that the INFO body is case insensitive.   o  Calling-Name:”<calling-name>” where <calling-name> is a string representing the calling party’s name   o  Calling-Number:<calling-number> where <calling-number>  is  a string representing the calling party’s number The Calling-Name and Calling-Number are always included in the INFO for call waiting as long as the calling party information is available. When the information is not available, the device must populate the calling line identification signal to the analog line with the appropriate unavailable signal. When the calling party information is not available, the Calling-Name and/or Calling-Number fields are not included in the INFO method body. It is possible that the calling number may be available without the calling name and vice versa. When these conditions occur, only the information that is available is included in the INFO method body (that is, it is possible to have a Calling-Number field in the INFO method body without a Calling-Name field and vice-versa).   When any portion of the calling party information is restricted, the Calling-Name and Calling-Number fields are included in the INFO method body header and are populated with Private. Note that restricted calling party information overrides unavailable calling party information. When the calling number is restricted and the calling name is unavailable or vice versa, both the Calling-Name and Calling-Number fields are included in the INFO method body and are populated with Private.   The Calling-Number field is sent in the INFO method body with the national format when the calling number and called number are within the same country code. When the calling number and called number are in different country codes, the Calling-Number field is populated with the E.164 number of the calling party.   The only event currently defined is flashhook (this is not case sensitive). The only event currently defined is flashhook (this is not case sensitive).   The only tones currently defined are:   CallWaitingTone1   CallWaitingTone2   CallWaitingTone3   CallWaitingTone4   The only parameter allowed for the stop body is: CallWaitingTone. A body with stop CallWaitingTone indicates that the access device should cease applying the call waiting tone regardless of which type of call waiting tone is applied.   The access device should send INFO when a flash is detected on the device.   VoIP platform sends type of INFO with play tone body when a VoIP subscriber has the Flash Call Waiting service assigned and a second call arrives for the VoIP platform subscriber while the subscriber is in an active call. The access device should never send this type of INFO.   Following is an example of INFO with stop body. Note that BroadWorks sends this type of INFO under the following conditions:   BroadWorks subscriber has Flash Call Waiting service assigned.     Second call arrives for the VoIP subscriber while the subscriber is in an active call.     INFO with a play tone body has been sent to the device to apply the appropriate call waiting tone.     Calling party hangs up prior to the VoIP subscriber answering the waiting call.   The INFO with stop body is not sent when the device answers the call via a flashhook. VoIP platform is expecting the device to implicitly stop the tone upon flashing, to answer the unanswered call. The only time VoIP platform will send the stop tone is when the call waiting caller hangs up before the call waiting party flashes to answer the call. Note that the access device should send never send this type of INFO. By: Olle Johansson (oej) 2008-07-06 02:42:47 licedey: Where did you copy this information from? If it's a proprietary format, what's the license and copyright? I think we do support FLASH in rfc2833. Have you tested? By: Alisher (licedey) 2008-07-07 08:42:24 The above info I found after googling in Czech technical manual. I didn't see anything related to copyright in this manual. Here is a link: http://www.cz.o2.com/file_conver/19071/TE000002_VoIP_Connect___Priloha.pdf I don't have sip device that generates flash hook in RFC2833, it worked on FXS analog phone with zap. With device that I have, when I set dtmf RFC2833 it send all dtfm in RFC2833 exept Flash hook (which it sends in sip info), and there is no option to override it. Can we add code that translates sip info/inband flash hook events into RFC2833? By: Leif Madsen (lmadsen) 2008-12-04 16:13:58.000-0600 Suspending this issue as it is a feature request without a patch (essentially since the license for the patch was rejected). Please find a bug marshall in #asterisk-bugs on the IRC network irc.freenode.net to request this bug reopened should you be able to move it along. Thanks!