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

["Drage, Keith (Nokia - GB)" <[e-mail]>]

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:[e-mail]] On Behalf Of Brian Rosen
Sent: 03 June 2016 13:36
To: Adam Roach
Cc: [e-mail]
Subject: Re: [MMUSIC] Transport of "Flash-hook"

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 <[e-mail]<mailto:[e-mail]>> 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 6/2/16 16:41, Brian Rosen wrote:
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 <[e-mail]<mailto:[e-mail]>> 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 6/2/16 15:58, Ted Hardie wrote:
Howdy,
In-line.

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

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

Hi Brian,

On Thu, Jun 2, 2016 at 12: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.

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.

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.

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


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.
I am asking to use code 16 to transport flash, in exactly the same way 2833 did.


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.

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.

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






_______________________________________________

mmusic mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/mmusic