[asterisk-dev] [svn-commits] jrose: branch 1.8 r369750 - /branches/1.8/channels/chan_sip.c

[Olle E. Johansson]

9 jul 2012 kl. 16:12 skrev Jonathan Rose:

> 
> 
> Olle E. Johansson wrote:
>> From: "Olle E. Johansson" <oej at edvina.net>
>> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
>> Sent: Monday, July 9, 2012 1:44:14 AM
>> Subject: Re: [asterisk-dev] [svn-commits] jrose: branch 1.8 r369750 -	/branches/1.8/channels/chan_sip.c
>> 
>> 
>> 6 jul 2012 kl. 22:54 skrev SVN commits to the Digium repositories:
>> 
>>> Author: jrose
>>> Date: Fri Jul  6 15:54:04 2012
>>> New Revision: 369750
>>> 
>>> URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=369750
>>> Log:
>>> chan_sip: Add case for FLASH control frames so that we don't
>>> display a warning.
>>> 
>>> chan_sip channels can receive flash control frames when connected
>>> to analog
>>> phones and possibly for other reasons. There really isn't a reason
>>> to warn when
>>> these frames are received, we can safely ignore them.
>>> 
>>> Patches:
>>>   dahdi_sip_flash.diff uploaded by Jonathan Rose (license 6182)
>>> 
>>> Modified:
>>>   branches/1.8/channels/chan_sip.c
>>> 
>>> Modified: branches/1.8/channels/chan_sip.c
>>> URL:
>>> http://svnview.digium.com/svn/asterisk/branches/1.8/channels/chan_sip.c?view=diff&rev=369750&r1=369749&r2=369750
>>> ==============================================================================
>>> --- branches/1.8/channels/chan_sip.c (original)
>>> +++ branches/1.8/channels/chan_sip.c Fri Jul  6 15:54:04 2012
>>> @@ -7006,6 +7006,8 @@
>>> 		break;
>>> 	case AST_CONTROL_UPDATE_RTP_PEER: /* Absorb this since it is
>>> 	handled by the bridge */
>>> 		break;
>>> +	case AST_CONTROL_FLASH: /* Absorb this since it is irrelevant to
>>> SIP. */
>>> +		break;
>> 
>> The should be sent down the RTP stack and be sent as RFC 2833
>> signals. We do already receive them,
>> so why not send them?
>> 
>> /O
>> 
> 
> Oh, I'm not sure why we would or wouldn't want to send them.
> I was simply wanting to get rid of the warning that appears and wasn't
> trying to change the functionality. In retrospect, I need to go ahead and
> set the res value to -1 though to ensure that the only thing that changes
> is the display of the log message, so I'm going to go ahead and do that.
> 
So we can receive but not send. Does that make sense in a product, do you think?
Either remove the receive part or add the send part is my suggestion.

Now, removing functionality that people may depend on is something 
the community normally doesn't like.

/O

> All I saw in regards to flashes in RFC 2833 though were the following

> 
>>  "A compliant implementation MUST support the events listed in Table 1
>>  with the exception of "flash". If it uses some other, out-of-band
>>  mechanism for signaling line conditions, it does not have to
>>  implement the other events."
> 
>>  DTMF Events
>> 
>>  Table 1 summarizes the DTMF-related named events within the
>>  telephone-event payload format.
>> 
>>                    Event  encoding (decimal)
>>                    _________________________
>>                    0--9                0--9
>>                    *                     10
>>                    #                     11
>>                    A--D              12--15
>>                    Flash                 16
>> 
>>                    Table 1: DTMF named events
> 
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

---
* Olle E Johansson - oej at edvina.net
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden