Re: [MMUSIC] Transport of "Flash-hook"

[Brian Rosen <[e-mail]>]

Muthu, I propose an Informational document.

Keith, I need to build a new box, which works with existing gateways and existing PSAP equipment.  The gateways implement 2833, which is still an RFC, but is declared obsolete.  4733 didn’t drop code 16 because there was a problem: it appears to be an oversight and/or lack of documented use.  I have a documented use.  I need to write a new spec.  I could always reference 2833.  If this was the IETF rather than NENA, I wouldn’t be allowed to create a new RFC with a  normative reference to an obsolete RFC without a really good reason.  Instead, I would be asked to do what I’m proposing to to; fix the problem by reserving Code 16 for hook flash.

Having said that, I have inquired and determined that some gateways indeed use INFO, rather than code 16.  Some do use code 16.  I’m going to discuss this within NENA and decide what to request of IETF based on this.

Brian


> On Jun 10, 2016, at 10:13 PM, Muthu Arul Mozhi Perumal <[e-mail]> wrote:
> 
> How about an informational path? That way NENA doesn't have to refer to an obsolete standard and no one would be forced to be complaint.
> 
> Muthu
> 
> On Sat, Jun 11, 2016 at 4:16 AM, Drage, Keith (Nokia - GB) <[e-mail] <mailto:[e-mail]>> wrote:
> If the purpose of this comment is to force everyone to be compliant with your 40 year old system, which you acknowledge you want to change out anyway, then that seems to be a very poor justification.
> 
> I would note that if you need to specify interoperability, the the old version still exists - it has not disappeared just because another document has replaced.
> 
> To me, you need to justify this based on a need for interoperability of new equipment in the field.
> 
> Keith
> 
> -----Original Message-----
> From: mmusic [mailto:[e-mail] <mailto:[e-mail]>] On Behalf Of Brian Rosen
> Sent: 10 June 2016 14:21
> To: Cullen Jennings (fluffy)
> Cc: [e-mail] <mailto:[e-mail]>
> Subject: Re: [MMUSIC] Transport of "Flash-hook"
> 
> I have a system that has been in use for 40 years.  We’re trying to upgrade everything, but we can’t accomplish that overnight.  The installed system reliably creates and detects hook flash.  No doubt the reason it works more reliably here is that nearly every implementation (probably ALL implementations, but I don’t know that for certain), uses a computer to generate the hook flash.  It’s not a user depressing the physical switch on a black phone.  Used to be, isn’t any more.  There isn’t any way to use some alternate signaling: the interface is CAMA, and that’s it.  At one point there was a push to upgrade these systems to use ISDN, but that got no where.  I’m not sure there are any existing systems that use ISDN.  They all use CAMA.  There are at least 4 brands of gateways that successfully do the right thing.
> 
> Brian
> 
> > On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) <[e-mail] <mailto:[e-mail]>> wrote:
> >
> >
> > I've see a lot of interop problems with hookflash. It's can be surprisingly hard for GWs to detect. Is there any way NENA could find a better way to do this? I'm not keen on bringing this back.
> >
> >
> >> On Jun 2, 2016, at 1:02 PM, Brian Rosen <[e-mail] <mailto:[e-mail]>> wrote:
> >>
> >> Back in RFC2833, the DTMF tones section, code 16 was defined for “Flash”, the signal caused by a momentary depression of the hook-switch in a POTS phone.  When 2833 was obsoleted by 4733, flash was dropped, although the code 16 was reserved.
> >>
> >> We have a use case in NENA (9-1-1 emergency stuff) where existing systems use flash interspersed wth tones in signaling dialing events which are not interpreted by the UA that receives them, but are instead transported to a device that creates appropriate SIP signaling for the dialing events initiated.  We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.
> >>
> >> I’m prepared to write a draft that restores code 16 for flash, as it was in 2833, but wanted to hear any objections to doing that.
> >>
> >> Brian
> >> _______________________________________________
> >> mmusic mailing list
> >> [e-mail] <mailto:[e-mail]>
> >> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> >
> 
> _______________________________________________
> mmusic mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
> _______________________________________________
> mmusic mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>