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

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

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