[asterisk-bugs] [Asterisk 0012999]: [patch] SIP channel cannot handle FLASH HOOK INFO message sent by SIP device

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=12999 
====================================================================== 
Reported By:                licedey
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   12999
Category:                   Channels/chan_sip/NewFeature
Reproducibility:            always
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.21 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             07-05-2008 08:57 CDT
Last Modified:              07-05-2008 19:18 CDT
====================================================================== 
Summary:                    [patch] SIP channel cannot handle FLASH HOOK INFO
message sent by SIP device
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'

====================================================================== 

---------------------------------------------------------------------- 
 licedey - 07-05-08 19:18  
---------------------------------------------------------------------- 
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. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-05-08 19:18  licedey        Note Added: 0089786                          
======================================================================