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

[Brian Rosen <[e-mail]>]

Inline

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

> 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.
>
> 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:[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>] *On Behalf Of *Brian
> Rosen
> *Sent:* 03 June 2016 13:36
> *To:* Adam Roach
> *Cc:* [e-mail] <javascript:_e(%7B%7D,'cvml','[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]
> <javascript:_e(%7B%7D,'cvml','[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]
> <javascript:_e(%7B%7D,'cvml','[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]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>
> Hi Ted
>
>
>
> On Jun 2, 2016, at 4:15 PM, Ted Hardie <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>> wrote:
>
>
>
> Hi Brian,
>
>
>
> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen <[e-mail]
> <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
>
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
>
>
>
>