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

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Jun 2016 15:02:13 -0400

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

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Jun 2016 13:15:05 -0700

Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <[email-masked]> 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.
>

It looks to me that you could be compliant with RFC 2833 without
implementing flash at all (see Section 3.3, on event types).  This has been
effectively gone a long time, in other words.

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

So, I'm not sure why invoking NENA and emergency services matters here.
You don't explain what the system does and how it interoperates with
anything else now.

If I replace "NENA" with "A proprietary system uses flash interspersed with
other DTMF tones to send signalling events to a gateway" is that
approximately true?  The key question seems to be "what are these events,
and what's the right way to signal them to a gateway"?

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

Let me gently suggest that you instead ask to re-use code 16, long in
abeyance, for this new purpose, whatever you eventually explain it to be.
Unless you plan to force people to go back through their old ITU E.18* docs
and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved
in this resurrection, saying "restores" seems like the wrong verb here.

Just my two cents, dislodged by a knee-jerk reaction to making DTMF more
important,

regards,

Ted

> Brian
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Jun 2016 16:49:31 -0400

Hi Ted

> On Jun 2, 2016, at 4:15 PM, Ted Hardie <[email-masked]> wrote:
> 
> Hi Brian,
> 
> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
> It looks to me that you could be compliant with RFC 2833 without implementing flash at all (see Section 3.3, on event types).  This has been effectively gone a long time, in other words.
I’m sorry, I don’t understand.  We’re writing a new standard, and I’d really prefer to not reference an obsolete IETF standard in that document.  I need to signal flash, the way 2833 signaled flash, but 4733 doesn’t have a way to signal flash.

> 
> 
> 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. 
> 
> 
> So, I'm not sure why invoking NENA and emergency services matters here.  You don't explain what the system does and how it interoperates with anything else now.  
I’m connecting a new IP based system that uses standards based SIP to an existing old system.  That system expects to signal to do a call transfer or conference operation with combinations of flash and DTMF.  There is a network that is using normal SIP signaling for transfer/conference, and this older system that is expecting hook switch and DTMF.  Ideally, we would have the UA facing the older system do the interwork, but alas that won’t work, and we need another element to do the interwork, and transport the DTMF and flash to the UA which will play out the signaling.  If I made that UA and the interworking element conform to 2833, everything would be fine, but then I’m requiring conformance to an obsolete document.
> 
> 
> If I replace "NENA" with "A proprietary system uses flash interspersed with other DTMF tones to send signalling events to a gateway" is that approximately true?  The key question seems to be "what are these events, and what's the right way to signal them to a gateway”?
It’s approximately true, but it’s a standards based system, not a proprietary system.  The older system is standards based, the new system is standards based, and I need to interwork them in  a standards based manner.  
>  
> We have no other way to transport flash to interwork with our newer SIP based emergency calling systems.
> 
> Let me gently suggest that you instead ask to re-use code 16, long in abeyance, for this new purpose, whatever you eventually explain it to be.  Unless you plan to force people to go back through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what exactly is involved in this resurrection, saying "restores" seems like the wrong verb here.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.

> 
> Just my two cents, dislodged by a knee-jerk reaction to making DTMF more important,
Yeah, I’m not thrilled with more backwards compatibility stuff either, but I’m also not a fan of an organization like NENA making up standards using SDP, or requiring conformance to obsolete standards.

Brian

---

From: Robert Sparks <[email-masked]>
Date: Thu, 2 Jun 2016 16:57:27 -0400

Hi Ted -

IIRC the reason 16 (and several other codes) were moved to reserved in 
4733 was to prepare for taking this up the standards ladder - there 
weren't implementations using the codepoints so the independent 
interoperable implementations barrier of the time couldn't be met. The 
text in 4733 explicitly recognized that they might be reassigned to 
their 2833 meaning if there were a reason to have them (favoring that 
over assigning the codepoint to something else), so I don't think Brian 
is in the weeds.

I had the same initial reaction about whether flash was a reasonable 
thing to use this way in the first place, but I'm not sure it's enough 
to push back against allowing this protocol to carry the events that are 
actually defined.

RjS

On 6/2/16 4:15 PM, Ted Hardie 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.
>
>
> implementing flash at all (see Section 3.3, on event types).  This has 
> been effectively gone a long time, in other words.
>
>
>     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. 
>
>
>
> So, I'm not sure why invoking NENA and emergency services matters 
> here.  You don't explain what the system does and how it interoperates 
> with anything else now.
>
> If I replace "NENA" with "A proprietary system uses flash interspersed 
> with other DTMF tones to send signalling events to a gateway" is that 
> approximately true?  The key question seems to be "what are these 
> events, and what's the right way to signal them to a gateway"?
>
>     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.
>
>
> abeyance, for this new purpose, whatever you eventually explain it to 
> be.  Unless you plan to force people to go back through their old ITU 
> E.18* docs and Bellcore GR-506-CORE PDFs trying to figure out what 
> exactly is involved in this resurrection, saying "restores" seems like 
> the wrong verb here.
>
>     [email-masked] <mailto:[email-masked]>

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Jun 2016 13:58:58 -0700

Howdy,

In-line.

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <[email-masked]> wrote:

> I’m sorry, I don’t understand.
>

I'm saying that since you could call yourself compliant RFC 2833 without
implementing flash at all, the ability to count on this went away before
the turn of the millenium.  As in 16 years ago.

>  We’re writing a new standard, and I’d really prefer to not reference an
> obsolete IETF standard in that document.  I need to signal flash, the way
> 2833 signaled flash, but 4733 doesn’t have a way to signal flash.
>
>
>
> I’m connecting a new IP based system that uses standards based SIP to an
> existing old system.  That system expects to signal to do a call transfer
> or conference operation with combinations of flash and DTMF.  There is a
> network that is using normal SIP signaling for transfer/conference, and
> this older system that is expecting hook switch and DTMF.  Ideally, we
> would have the UA facing the older system do the interwork, but alas that
> won’t work, and we need another element to do the interwork, and transport
> the DTMF and flash to the UA which will play out the signaling.  If I made
> that UA and the interworking element conform to 2833, everything would be
> fine, but then I’m requiring conformance to an obsolete document.
>
>
>
> and what's the right way to signal them to a gateway”?
>
> It’s approximately true, but it’s a standards based system, not a
> proprietary system.
>
You say that, but you appear to be implying that it is a system based on a
standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC
4733).  You appear to be attempting to create a new standard in 2016 (let's
be honest here, likely arriving in 2018) that recapitulates something from
the past so that NENA doesn't have to update something that's been
superseded.

>  The older system is standards based, the new system is standards based,
> and I need to interwork them in  a standards based manner.
>

You want everyone else to re-implement flash so that NENA doesn't replace
their proprietary/superseded system?

> I am asking to use code 16 to transport flash, in exactly the same way
And you want to undo the decisions that led to it being soft-dropped there
and deprecated.  But the justification doesn't seem to be there.

> Yeah, I’m not thrilled with more backwards compatibility stuff either, but
> I’m also not a fan of an organization like NENA making up standards using
> SDP, or requiring conformance to obsolete standards.
>

How about they expressing what the actual gateway signalling requirements
are and we solve them without zombie DTMF shuffling about?

Just a thought,

Ted

---

From: Ted Hardie <[email-masked]>
Date: Thu, 2 Jun 2016 14:00:41 -0700

On Thu, Jun 2, 2016 at 1:57 PM, Robert Sparks <[email-masked]> wrote:

> 4733 was to prepare for taking this up the standards ladder - there weren't
> implementations using the codepoints so the independent interoperable
> implementations barrier of the time couldn't be met. The text in 4733
> explicitly recognized that they might be reassigned to their 2833 meaning
> if there were a reason to have them (favoring that over assigning the
> codepoint to something else), so I don't think Brian is in the weeds.
>
Given that you could claim conformance to RFC 2833 without them, and given
that the implementations of them never came forward, I think this
retrograde motion isn't warranted by the explanation given so far.

Just my two cents, obviously,

Ted

> I had the same initial reaction about whether flash was a reasonable thing
> to use this way in the first place, but I'm not sure it's enough to push
> back against allowing this protocol to carry the events that are actually
> defined.
>
> RjS
>
> mmusic mailing [email-masked]://www.ietf.org/mailman/listinfo/mmusic
>
>
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jun 2016 16:02:16 -0500

This sounds like a whole lot of talking past each other. Brian: do you 
have a rough picture of the system you're designing that you could 
share? Something that points out old parts versus new parts and 
highlights where RFC 4733 would be used?

/a

On 6/2/16 15:58, Ted Hardie wrote:
> Howdy,
>
> In-line.
>
> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Ted
>
>>     On Jun 2, 2016, at 4:15 PM, Ted Hardie <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>
>>     Hi Brian,
>>
>>         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.
>>
>>
>>     implementing flash at all (see Section 3.3, on event types). This
>>     has been effectively gone a long time, in other words.
> I'm saying that since you could call yourself compliant RFC 2833 
> without implementing flash at all, the ability to count on this went 
> away before the turn of the millenium.  As in 16 years ago.
>
>      We’re writing a new standard, and I’d really prefer to not
>     reference an obsolete IETF standard in that document.  I need to
>     signal flash, the way 2833 signaled flash, but 4733 doesn’t have a
>     way to signal flash.
>
>>
>>
>>         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. 
>>
>>
>>
>>     here.  You don't explain what the system does and how it
>>     interoperates with anything else now.
>     I’m connecting a new IP based system that uses standards based SIP
>     to an existing old system.  That system expects to signal to do a
>     call transfer or conference operation with combinations of flash
>     and DTMF.  There is a network that is using normal SIP signaling
>     for transfer/conference, and this older system that is expecting
>     hook switch and DTMF.  Ideally, we would have the UA facing the
>     older system do the interwork, but alas that won’t work, and we
>     need another element to do the interwork, and transport the DTMF
>     and flash to the UA which will play out the signaling.  If I made
>     that UA and the interworking element conform to 2833, everything
>     would be fine, but then I’m requiring conformance to an obsolete
>     document.
>>
>>
>>     If I replace "NENA" with "A proprietary system uses flash
>>     interspersed with other DTMF tones to send signalling events to a
>>     gateway" is that approximately true?  The key question seems to
>>     be "what are these events, and what's the right way to signal
>>     them to a gateway”?
> You say that, but you appear to be implying that it is a system based 
> on a standard that was disappearing in 2000 (RFC 2833) and gone by 
> 2006 (RFC 4733).  You appear to be attempting to create a new standard 
> in 2016 (let's be honest here, likely arriving in 2018) that 
> recapitulates something from the past so that NENA doesn't have to 
> update something that's been superseded.
>
>      The older system is standards based, the new system is standards
>     based, and I need to interwork them in  a standards based manner.
>
>
> You want everyone else to re-implement flash so that NENA doesn't 
> replace their proprietary/superseded system?
>
>>         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.
>>
>>
>>     Let me gently suggest that you instead ask to re-use code 16,
>>     long in abeyance, for this new purpose, whatever you eventually
>>     explain it to be.  Unless you plan to force people to go back
>>     through their old ITU E.18* docs and Bellcore GR-506-CORE PDFs
>>     trying to figure out what exactly is involved in this
>>     resurrection, saying "restores" seems like the wrong verb here.
> And you want to undo the decisions that led to it being soft-dropped 
> there and deprecated.  But the justification doesn't seem to be there.
>
>>
>     Yeah, I’m not thrilled with more backwards compatibility stuff
>     either, but I’m also not a fan of an organization like NENA making
>     up standards using SDP, or requiring conformance to obsolete
>     standards.
>
>
> How about they expressing what the actual gateway signalling 
> requirements are and we solve them without zombie DTMF shuffling about?
>
> Just a thought,
>
> Ted
>
>
>     Brian
>
>
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 2 Jun 2016 17:22:58 -0400

> 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…

What was the reason flash was dropped in 4733?

Was there a "flash considered harmful" argument?

	Thanks,
	Paul

---

From: Brian Rosen <[email-masked]>
Date: Thu, 2 Jun 2016 17:41:46 -0400

Sure

       SIP    SIP   MF
SIP-UA —— IWF —— GW—— Legacy PSAP

A call is up from the SIP-UA to the Legacy PSAP through the IWF and GW.

The Legacy PSAP is trying to tell the SIP UA to transfer the call

GW is an existing off the shelf, normal IP-PSTN gateway, most of which actually are 2833 compliant, but I’m trying not to require conformance to 2833. Note that “MF” is tone signaled analog telephony.  The actual MF protocol used here is CAMA.

IWF is a B2BUA that has code we can do anything reasonable with, which will conform to NENA standards.

The Legacy PSAP signals a transfer by sending FLASH, digit, digit, digit….

The GW gets this signaling, but doesn’t really know what to do with it, so it passes the sequence to the IWF

The IWF recognizes this is a transfer request, and generates the REFER to the SIP UA.

The problem I’m solving is the signaling between the GW and the IWF.  I can transport the digits with 4733, but not the flash.

> On Jun 2, 2016, at 5:02 PM, Adam Roach <[email-masked]> wrote:
> 
> This sounds like a whole lot of talking past each other. Brian: do you have a rough picture of the system you're designing that you could share? Something that points out old parts versus new parts and highlights where RFC 4733 would be used?
> 
> /a
> 
>> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> Hi Ted
>> 
>>> On Jun 2, 2016, at 4:15 PM, Ted Hardie <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Brian,
>>> 
>>> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>> I'm saying that since you could call yourself compliant RFC 2833 without implementing flash at all, the ability to count on this went away before the turn of the millenium.  As in 16 years ago.
>>  
>>  We’re writing a new standard, and I’d really prefer to not reference an obsolete IETF standard in that document.  I need to signal flash, the way 2833 signaled flash, but 4733 doesn’t have a way to signal flash.
>> 
>>> 
>>> 
>> It’s approximately true, but it’s a standards based system, not a proprietary system.
>> You say that, but you appear to be implying that it is a system based on a standard that was disappearing in 2000 (RFC 2833) and gone by 2006 (RFC 4733).  You appear to be attempting to create a new standard in 2016 (let's be honest here, likely arriving in 2018) that recapitulates something from the past so that NENA doesn't have to update something that's been superseded.
>>  
>>  The older system is standards based, the new system is standards based, and I need to interwork them in  a standards based manner.  
>> 
>> You want everyone else to re-implement flash so that NENA doesn't replace their proprietary/superseded system?
>>  
>>>  
>> And you want to undo the decisions that led to it being soft-dropped there and deprecated.  But the justification doesn't seem to be there. 
>>> 
>> How about they expressing what the actual gateway signalling requirements are and we solve them without zombie DTMF shuffling about?
>> 
>> Just a thought,
>> 
>> Ted
>>  
>> 
>> Brian
>> 
>> 
>> 
>> 
>> https://www.ietf.org/mailman/listinfo/mmusic <https://www.ietf.org/mailman/listinfo/mmusic>
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 2 Jun 2016 21:48:45 +0000

I asked Henning:
4733 with 16 seems plausible (and somewhat simpler than INFO in terms of implementation); I did a little bit of digging through my 2002ish email archive and the inclusion criterion seems to have been documented use. I have an email message indicating that hook flash should be included, but it may have fallen into the cracks as 4734 was completed and we never got back to DC (hook) events.

Most unfortunately, Tom is no longer with us.

Brian

On Jun 2, 2016, at 5:22 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,
Paul

Brian
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Adam Roach <[email-masked]>
Date: Thu, 2 Jun 2016 17:07:14 -0500

And, for clarity:

The SIP GW already sends event 16 when it sees a hookflash? Or do you 
need to update its software to accomodate this change?

/a

On 6/2/16 16:41, Brian Rosen wrote:
> GW is an existing off the shelf, normal IP-PSTN gateway, most of which 
> actually are 2833 compliant, but I’m trying not to require conformance 
> to 2833. Note that “MF” is tone signaled analog telephony.  The actual 
> MF protocol used here is CAMA.
>
> The problem I’m solving is the signaling between the GW and the IWF. 
>  I can transport the digits with 4733, but not the flash.
>
>
>> On Jun 2, 2016, at 5:02 PM, Adam Roach <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> This sounds like a whole lot of talking past each other. Brian: do 
>> you have a rough picture of the system you're designing that you 
>> could share? Something that points out old parts versus new parts and 
>>>>         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.
>>>>
>>>>
>>>>     It looks to me that you could be compliant with RFC 2833
>>>>     without implementing flash at all (see Section 3.3, on event
>>>>     types).  This has been effectively gone a long time, in other
>>>>     words.
>>>     signal flash, the way 2833 signaled flash, but 4733 doesn’t have
>>>     a way to signal flash.
>>>
>>>>
>>>>
>>>>         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. 
>>>>
>>>>
>>>>
>>>>     So, I'm not sure why invoking NENA and emergency services
>>>>     matters here.  You don't explain what the system does and how
>>>>     it interoperates with anything else now.
>>>     I’m connecting a new IP based system that uses standards based
>>>     SIP to an existing old system.  That system expects to signal to
>>>     do a call transfer or conference operation with combinations of
>>>     flash and DTMF.  There is a network that is using normal SIP
>>>     signaling for transfer/conference, and this older system that is
>>>     expecting hook switch and DTMF.  Ideally, we would have the UA
>>>     facing the older system do the interwork, but alas that won’t
>>>     work, and we need another element to do the interwork, and
>>>     transport the DTMF and flash to the UA which will play out the
>>>     signaling.  If I made that UA and the interworking element
>>>     conform to 2833, everything would be fine, but then I’m
>>>     requiring conformance to an obsolete document.
>>>>
>>>>
>>>>     interspersed with other DTMF tones to send signalling events to
>>>>     a gateway" is that approximately true? The key question seems
>>>>     to be "what are these events, and what's the right way to
>>>>     signal them to a gateway”?
>>> You say that, but you appear to be implying that it is a system 
>>> based on a standard that was disappearing in 2000 (RFC 2833) and 
>>> gone by 2006 (RFC 4733).  You appear to be attempting to create a 
>>> new standard in 2016 (let's be honest here, likely arriving in 2018) 
>>> that recapitulates something from the past so that NENA doesn't have 
>>> to update something that's been superseded.
>>>
>>>      The older system is standards based, the new system is
>>>     standards based, and I need to interwork them in  a standards
>>>     based manner.
>>>
>>>
>>>>         We have no other way to transport flash to interwork with
>>>>         our newer SIP based emergency calling systems.
>>>>
>>>     either, but I’m also not a fan of an organization like NENA
>>>     making up standards using SDP, or requiring conformance to
>>>     obsolete standards.
>>>
>>>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 3 Jun 2016 08:36:18 -0400

Yeah, the ones I know about do.  They claim 2833 compliance for the most part.

As I said, one way to solve this is just require 2833 compliance in a spec written in 2016.  
We probably wouldn’t allow a normative reference to 2833 in some standards track RFC we wrote today; we would fix whatever the problem was.

Brian

> On Jun 2, 2016, at 6:07 PM, Adam Roach <[email-masked]> wrote:
> 
> And, for clarity:
> 
> The SIP GW already sends event 16 when it sees a hookflash? Or do you need to update its software to accomodate this change?
> 
> /a
> 
>>> On Jun 2, 2016, at 5:02 PM, Adam Roach < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>>>> On Jun 2, 2016, at 4:15 PM, Ted Hardie < <mailto:[email-masked]>[email-masked] <mailto:[email-masked]>> wrote:
>>>>> 
>>>>> Hi Brian,
>>>>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 3 Jun 2016 14:56:57 +0000

I think you need to at least answer a couple of questions.

1)      What are you using it for? In the PSTN, the normal usage was to reconnect a register so that subsequent digits can be received. Now with both mechanisms for sending DTMF, the recipient is already there to receive DTMF tones after the initial INVITE has been sent and received some form of provisional response or 200 OK. As such, it is not needed for that function. It is for that reason I think it was eventually dropped in the ISDN DSS1 documents (the signalling channel always being in existence in ISDN), and possibly that may be the reason it does not appear in the SIP documents. Now I know there are some special obscurities in the North American usage of this that makes two different signals based on timing differences, but please explain if you are using these, and what the result means.

2)      In the North America 911 work, I understood that the CS domain was being separated from the PS (SIP) domain even through the emergency services network and all the way to the PSAP. As such, why are you having to interwork PSTN type signals, which have presumably come from a PSTN endpoint, and if so where in the architecture are you doing it.
Regards

Keith

From: mmusic [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 03 June 2016 13:36
To: Adam Roach
Cc: [email-masked]
Subject: Re: [MMUSIC] Transport of "Flash-hook"

Brian

On Jun 2, 2016, at 6:07 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

And, for clarity:

/a

       SIP    SIP   MF

On Jun 2, 2016, at 5:02 PM, Adam Roach <[email-masked]<mailto:[email-masked]>> wrote:

/a

On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted

On Jun 2, 2016, at 4:15 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

Hi Brian,

On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> 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.

Brian

mmusic mailing list

---

From: Brian Rosen <[email-masked]>
Date: Fri, 3 Jun 2016 12:36:41 -0400

Inline

On Friday, June 3, 2016, Drage, Keith (Nokia - GB) <[email-masked]>
wrote:

> 1)      What are you using it for? In the PSTN, the normal usage was to
> reconnect a register so that subsequent digits can be received. Now with
> both mechanisms for sending DTMF, the recipient is already there to receive
> DTMF tones after the initial INVITE has been sent and received some form of
> provisional response or 200 OK. As such, it is not needed for that
> function. It is for that reason I think it was eventually dropped in the
> ISDN DSS1 documents (the signalling channel always being in existence in
> ISDN), and possibly that may be the reason it does not appear in the SIP
> documents. Now I know there are some special obscurities in the North
> American usage of this that makes two different signals based on timing
> differences, but please explain if you are using these, and what the result
> means.
>
> This is for inter working a legacy PSAP with a CAMA interface that was
facing a selective router. We upgrade the network but need to be able to
support non-upgraded PSAPs. It uses flash in the usual way to engage the
signaling system to look for tones. The actual gateway doesn't have the
ability to interwork the flash digit sequence to the right combination of
INVITE and REFER to do the conferencing and transfer operations that the
selective router would have done.

> 2)      In the North America 911 work, I understood that the CS domain
> was being separated from the PS (SIP) domain even through the emergency
> services network and all the way to the PSAP. As such, why are you having
> to interwork PSTN type signals, which have presumably come from a PSTN
> endpoint, and if so where in the architecture are you doing it.
>
> This is the interwork from the Legacy PSAP Gateway to the ESInet.

A similar problem exists for a Legacy Selective Router Gateway that
actually connects to the selective router and mimics a legacy PSAP.

> Regards
>
>
>
> Keith
>
>
>
> *From:* mmusic [mailto:[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Brian
> Rosen
> *Sent:* 03 June 2016 13:36
> *To:* Adam Roach
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [MMUSIC] Transport of "Flash-hook"
>
>
>
> We probably wouldn’t allow a normative reference to 2833 in some standards
> track RFC we wrote today; we would fix whatever the problem was.
>
>
>
> Brian
>
>
>
> On Jun 2, 2016, at 6:07 PM, Adam Roach <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> And, for clarity:
>
> The SIP GW already sends event 16 when it sees a hookflash? Or do you need
> to update its software to accomodate this change?
>
> /a
>
> actually are 2833 compliant, but I’m trying not to require conformance to
> 2833. Note that “MF” is tone signaled analog telephony.  The actual MF
> protocol used here is CAMA.
>
>
>
> The problem I’m solving is the signaling between the GW and the IWF.  I
> can transport the digits with 4733, but not the flash.
>
>
>
>
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> have a rough picture of the system you're designing that you could share?
> Something that points out old parts versus new parts and highlights where
> RFC 4733 would be used?
>
> /a
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> Hi Ted
>
>
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>
>
> Hi Brian,
>
>
>
> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jun 2016 11:51:34 -0500

Given that we have deployed gateways generating these events per an 
older spec, and given that the code was removed only because of 
perceived lack of use (as opposed to a concrete sense of potential 
harm), it seems reasonable to revive the 2833 meaning of event 16 in a 
formal sense.

I'll note that RFC4733 foresaw this as a reasonable kind of thing that 
might happen; it explicitly says:

> codes 16 [and several others]... are reserved in the first instance 
> for specifications reviving the corresponding RFC 2833 events...

I agree with what I think I hear other people saying: we don't want to 
encourage new uses of flash. At the same time, there's no sensible 
reason to force the E911 folks into doing something nonstandard just 
because we're afraid modern systems might copy the technique.

So I would support MMUSIC adopting and requesting publication for a 
narrowly scoped document that registers event 16 for hook flash, 
assuming the scope is sufficiently well-defined (e.g., indicating that 
this behavior is anticipated to be used by legacy gateways of the style 
Brian describes, rather than native SIP terminals or traditional 
endpoint ATAs).

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Jun 2016 10:49:02 -0700

On Fri, Jun 3, 2016 at 9:51 AM, Adam Roach <[email-masked]> wrote:

> Given that we have deployed gateways generating these events per an older
> spec,

So I think the value of "we" is pretty small here.

> and given that the code was removed only because of perceived lack of use
> (as opposed to a concrete sense of potential harm), it seems reasonable to
> revive the 2833 meaning of event 16 in a formal sense.
>
> codes 16 [and several others]... are reserved in the first instance for
>> specifications reviving the corresponding RFC 2833 events...
>>
>
> encourage new uses of flash. At the same time, there's no sensible reason
> to force the E911 folks into doing something nonstandard

I think the continued invocation of un-upgraded PSAPs is a definite signal
here.  If we took out "NENA" here and said that this was a gateway deployed
by, say, Walmart, would we really get the same result?  They have many
thousands of stores, serve millions upon millions of people in North
America, and have been around long enough that they too might have legacy
code deployed.   Could Walmart ask for this from a global standards body?

I'll try to get my knee to stop jerking on this as soon as possible, but I
have to say I'm still not convinced this is a reasonable thing to
standardize in 2016.  This remains reserved; NENA's PSAPs are very unlikely
to to find other uses of 16 that interfere with what they are doing--but
standardizing this seems seriously retrograde to me.

Ted

> just because we're afraid modern systems might copy the technique.
>
> narrowly scoped document that registers event 16 for hook flash, assuming
> the scope is sufficiently well-defined (e.g., indicating that this behavior
> is anticipated to be used by legacy gateways of the style Brian describes,
> rather than native SIP terminals or traditional endpoint ATAs).
>
>
> /a
>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jun 2016 13:08:01 -0500

On 6/3/16 12:49, Ted Hardie wrote:
> I think the continued invocation of un-upgraded PSAPs is a definite 
> signal here.  If we took out "NENA" here and said that this was a 
> gateway deployed by, say, Walmart...

That seems like a kind of apples-to-bulldozers comparison. One is a 
public safety governmental function with extremely disparate funds 
available (depending on locale) undergoing a tricky multi-decade 
technological upgrade; the other is a monolithic for-profit organization 
under a single IT administration.

This video is pretty amusing overall (warning: not appropriate for more 
conservative workplaces), but the bit in the middle that goes over the 
administrative structure might shine a light on the challenges endemic 
in getting new technology deployed: 
https://www.youtube.com/watch?v=A-XlyB_QQYs

> This remains reserved; NENA's PSAPs are very unlikely to to find other 
> uses of 16 that interfere with what they are doing--but standardizing 
> this seems seriously retrograde to me.

I suppose it makes little practical difference, but it seems kind of an 
ivory-tower out-of-touch style response. "Sure, go off and do it, as 
long as we're not forced to acknowledge it's happening."

I guess I'm having a hard time understanding the harm you clearly see in 
re-registering the code.

/a

---

From: Ted Hardie <[email-masked]>
Date: Fri, 3 Jun 2016 11:36:28 -0700

On Fri, Jun 3, 2016 at 11:08 AM, Adam Roach <[email-masked]> wrote:

>> signal here.  If we took out "NENA" here and said that this was a gateway
>> deployed by, say, Walmart...
>>
>
>
> That seems like a kind of apples-to-bulldozers comparison. One is a public
> safety governmental function with extremely disparate funds available
> (depending on locale) undergoing a tricky multi-decade technological
> upgrade; the other is a monolithic for-profit organization under a single
> IT administration.
>
> So that sounds like your answer is "The value of doing it is based on a
perceived ability of the requester to actually upgrade".  Is that the
difference between this apple and that bulldozer?

(will have to watch video some other time)

This remains reserved; NENA's PSAPs are very unlikely to to find other uses
>> of 16 that interfere with what they are doing--but standardizing this seems
>> seriously retrograde to me.
>>
>
>
> ivory-tower out-of-touch style response. "Sure, go off and do it, as long
> as we're not forced to acknowledge it's happening."
>
>
Brian wouldn't be asking for this if someone wasn't going off to write new
code.  (If this were a completely static system sitting in place, he
wouldn't waste his or our time asking to have the code points continued use
in RFC 2833 style be documented.)  Marking that new code as using something
from an older, deprecated standard seems appropriate to me.  That's where
it is coming from in the system he's describing, and that's really what's
happening.

Writing a new standard that resurrects this in order to avoiding
referencing the older, deprecated standard seems to me to send the wrong
signal.
Unless we want flash to return, new code using it should be explicit that
it is maintaining a deprecated use for a legacy system; resurrecting it as
a standard usage is going to send a signal that we think that new,
interoperable uses of this should be expected.  I don't think we should
send that signal, and I didn't hear anything in Brian's use case that
justifies it.

If Brian would like to write an informational doc that describes flash's
continuing use in gateway systems, to help ensure no one squats on the code
point, I will cheer him on.

My prejudices on this point are pretty thoroughly exposed here, I expect,
so I doubt I have much to add.  I'll answer questions if asked, but I don't
expect to have much more to put into the thread.

Ted
/trying to stop that ol' trick knee

---

From: Adam Roach <[email-masked]>
Date: Fri, 3 Jun 2016 13:50:52 -0500

On 6/3/16 13:36, Ted Hardie wrote:
> So that sounds like your answer is "The value of doing it is based on 
> a perceived ability of the requester to actually upgrade".  Is that 
> the difference between this apple and that bulldozer?

Well, I'm also making a "public benefit" argument (with both 
characteristics being necessary and neither sufficient for the 
distinction), but you caught half of what I was saying.

> referencing the older, deprecated standard seems to me to send the 
> wrong signal. 

Ironically, I think we are disagreeing not because we have different 
goals, but because we have identical goals and different ideas about the 
tactics most likely to achieve those goals. I'd like to see text 
explicitly acknowledging that this usage will be seen in the field -- 
and even described in nicely formatted quasi-governmental documents --  
and explaining why "you, dear reader," should not emulate it.

> If Brian would like to write an informational doc that describes 
> flash's continuing use in gateway systems, to help ensure no one 
> squats on the code point, I will cheer him on.

It's not what I would prefer (I'd actually like to see an IANA update 
that points to a document that puts the proper scoping around how the 
codepoint is being used and how it shouldn't be used), but it certainly 
seems better than just throwing our hands in the air and telling Brian 
to stuff it.

/a

---

From: Brian Rosen <[email-masked]>
Date: Mon, 6 Jun 2016 10:17:25 -0400

Clearly, I agree with Adam.

I want the IANA code point restored to what it’s being used for in the field.

I also don’t want to write a new document that references an old document, and explain that the reason I’m doing that is that a mistake was made when they created the new document.

If I was doing this in the IETF, that would not be allowed; whatever document I was creating would have to have instructions to IANA to restore the code point.

Since 4733 says that new entries in the registry are “Specification Required” and “Expert Review”, I don’t need a standards track document.  Instead, suppose I create a short Informational document that states that it was probably a mistake to drop it, that we’re instructing IANA to restore it, include just enough technical detail to describe the 2833 functionality in the 4733 document context, and state what the intention is (document existing use so that we can reference 4733 and the informational rather than 2833).

Brian

> On Jun 3, 2016, at 2:50 PM, Adam Roach <[email-masked]> wrote:
> 
>> So that sounds like your answer is "The value of doing it is based on a perceived ability of the requester to actually upgrade".  Is that the difference between this apple and that bulldozer?
> 
> 
> Well, I'm also making a "public benefit" argument (with both characteristics being necessary and neither sufficient for the distinction), but you caught half of what I was saying.
> 
> 
>> Writing a new standard that resurrects this in order to avoiding referencing the older, deprecated standard seems to me to send the wrong signal. 
> 
> 
> Ironically, I think we are disagreeing not because we have different goals, but because we have identical goals and different ideas about the tactics most likely to achieve those goals. I'd like to see text explicitly acknowledging that this usage will be seen in the field -- and even described in nicely formatted quasi-governmental documents --  and explaining why "you, dear reader," should not emulate it.
> 
> 
>> If Brian would like to write an informational doc that describes flash's continuing use in gateway systems, to help ensure no one squats on the code point, I will cheer him on.
> 
> 
> It's not what I would prefer (I'd actually like to see an IANA update that points to a document that puts the proper scoping around how the codepoint is being used and how it shouldn't be used), but it certainly seems better than just throwing our hands in the air and telling Brian to stuff it.
> 
> 
> /a
>

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 07 Jun 2016 11:36:22 -0400

Brian Rosen <[email-masked]> writes:
> Instead, suppose I create a short Informational document that states
> that it was probably a mistake to drop it, that we're instructing IANA
> to restore it, include just enough technical detail to describe the
> 2833 functionality in the 4733 document context, and state what the
> intention is (document existing use so that we can reference 4733 and
> the informational rather than 2833).

That makes sense to me.

Dale

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 9 Jun 2016 17:59:09 +0000

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 <[email-masked]> wrote:
>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 9 Jun 2016 19:21:52 +0000

I believe to bring it back you would also need to define flashhook, unless you can find an international definition of the timings elsewhere and reference it.

In terms of timing, a disconnect with a timing of approximately 33% of a 100 ms cycle is a dial pulse (although I believe there are variants that work at twice this speed.

European standards indicate a duration of 50 - 130 ms for register recall.

Somewhere over 500 ms constitutes a hangup.

I believe I have seen PBX systems that have used the period between 130 ms and 500 ms as a second form of hookflash - no access to my early notes at the moment.

In more PBX related signalling systems a off hook to on hook of 140 - 290 ms can be a wink start to indicate starting to send digits.

So the problems are more than one type of hookflash exists, and probably a lack of definition of the timings in an international sense.

I'd also note that if we have "hookflash", why don't we have on-hook, off hook, dial pulse, and so on. 

Personally, as the hookflash is to gain access to something to transmit/receive digits, then maybe you should be turning the RTP DTMF channel on and off if you really want to simulate it!

Keith

---

From: Martin Taylor <[email-masked]>
Date: Fri, 10 Jun 2016 08:49:02 +0000

Signalling of flash-hook is an important aspect of PSTN Emulation with IMS.  There are a bunch of mid-call services that must be supported for POTS such as call transfer and three-way calling which rely on being able to signal flash-hook.

In my experience, most PSTN Emulation implementations use SIP INFO requests to signal flash-hook.  To my knowledge, this has never been standardized but there have been I-Ds on the topic, e.g. draft-hwang-sipping-infomidcall-00 and draft-kaplan-sip-info-use-cases-01.

Many analog telephone adapters support the SIP INFO method of signalling flash-hook.

Martin

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 02 June 2016 20:02
To: [email-masked]
Subject: [MMUSIC] Transport of "Flash-hook"

Brian

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Jun 2016 09:20:59 -0400

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) <[email-masked]> wrote:
> 
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Jun 2016 09:33:28 -0400

The gateways I’m familiar with can generate/accept code 16.  It may be that they can use INFO, but I’m not aware of it.  The gateways that are installed, AFAIK, use code 16.  I have some queries into implementors to verify, and I’ll report what I find.

Brian

> On Jun 10, 2016, at 4:49 AM, Martin Taylor <[email-masked]> wrote:
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Jun 2016 09:38:36 -0400

Recall that 2833/4733 delivers the actual duration of the “tone”.  It would do so with hook flash, and thus it is up to the recipient to determine what the timing should be.  I can put text in that mentions the range from greater than dial pulse to less than hangup (and thus 50-250 or so).

The system can place calls, and those calls may end up on, e.g. an IVR.  So the gateway itself can’t gate the DTMF channel.  The IWF has to pass on DTMF that isn’t for it.

Brian

> On Jun 9, 2016, at 3:21 PM, Drage, Keith (Nokia - GB) <[email-masked]> wrote:
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 10 Jun 2016 18:16:50 -0400

Brian Rosen <[email-masked]> writes:
> 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.

> There are at least 4 brands of gateways that successfully do the right
> thing.   

> Recall that 2833/4733 delivers the actual duration of the "tone".  It
> would do so with hook flash, and thus it is up to the recipient to
> determine what the timing should be.  I can put text in that mentions
> the range from greater than dial pulse to less than hangup (and thus
> 50-250 or so).

It sounds like there is actual interoperation going on.  If you can
capture the specifications for achieving that from the current
implementations, it seems like a reasonable candidate for
standardization.  (Even if we want to mark it 'deprecated'.)

Dale

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 10 Jun 2016 22:46:15 +0000

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:[email-masked]] On Behalf Of Brian Rosen
Sent: 10 June 2016 14:21
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [MMUSIC] Transport of "Flash-hook"

Brian

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Fri, 10 Jun 2016 22:46:15 +0000

The only way I can interpret that without any timing information at all is that you are also sending this signal for decadic dialling pulses, at the shorter end of the period, and also sending it prior to hangup, where the sending equipment has not yet seen the disconnect for long enough to determine it is not a hookflash. As such, it is not a hookflash signal, it is a loop disconnect, loop connect signal.

I'd also note that as those timings do vary from country to country, there will always be interpretation implications running this across an international boundary.

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 10 June 2016 14:39
To: Drage, Keith (Nokia - GB)
Cc: Cullen Jennings (fluffy); [email-masked]
Subject: Re: [MMUSIC] Transport of "Flash-hook"

Brian

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Sat, 11 Jun 2016 07:43:44 +0530

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) <
[email-masked]> 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.
>
> 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
>
> > 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.
> >
> >
> “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.
> >>
> 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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 15 Jun 2016 11:19:37 -0400

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 <[email-masked]> 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) <[email-masked] <mailto:[email-masked]>> wrote:
> From: mmusic [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Brian Rosen
> Sent: 10 June 2016 14:21
> Cc: [email-masked] <mailto:[email-masked]>
> > On Jun 9, 2016, at 1:59 PM, Cullen Jennings (fluffy) <[email-masked] <mailto:[email-masked]>> wrote:
> >
> >
> >> On Jun 2, 2016, at 1:02 PM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
> >>