Return-Path: X-Original-To: mmusic@ietfa.amsl.com Delivered-To: mmusic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC7312D13E for ; Fri, 3 Jun 2016 05:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJGOrjyz9SXd for ; Fri, 3 Jun 2016 05:36:23 -0700 (PDT) Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DE212D126 for ; Fri, 3 Jun 2016 05:36:23 -0700 (PDT) Received: by mail-qg0-x233.google.com with SMTP id j96so1101416qge.0 for ; Fri, 03 Jun 2016 05:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=bLc6KEnzaJGjah52riDibXhDUaS/PgxPtSeXg+VpmXQ=; b=t/hgphEJNbnUOtq2Jik0/ycPAiG9+BECo0EPSKFsrr7JT0N9tznQJ76Ac3WGZMXdU6 Ma0n4Fb/P8uhPWDFfjsaTGCUd/ELdFUlAbDTVAlKPF+kAzJbegQWQVQ78Gw6Yk8PYlzc MzpIuvQlNjfiHNryHkL63b/CP0YBse08fQeJ2W6iPGRvs6bjiEHGCiiA1Eor7zGdH6NE Os792tAK7RHK8fDvu2C6lDdrc0hOa8Fe/Gjw0XG738QXOiyZWzQGIw5XBp0MAXD5EobA 7ZENMvmcB1NHCqdceFyifJD3SirPXE5yJVeL6misHwR5Pcfs/8MuZj3np2J1At0TkqWg TGqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=bLc6KEnzaJGjah52riDibXhDUaS/PgxPtSeXg+VpmXQ=; b=VTIsrj5oFzPH+c9cY7eBCH8MLeaf/iaByGZsDs+eJ96WK+8PrHMMMoZdc9CTZ+RbWe 6omSIPIc7YC/VTH9FlbDO9OFvVLH1k/+PLGKSUiZCcOIIOnrW/xyTOoheu0ZG+J9oXJa ZOGUFvdJ5s4Kqb99OBbFvawnwTPsHnhL6UOpuPe5Nch03udNwqpkF8w8yqU8SOiPJORo R0nIBcqho9V+Vx9bFXOkoba5u7FudIcE0gMKDx1ACSQUs3iFlzJADR2AUKpz7FnBdXng vWz2cLiCjY4ebKWv6iCNQwEk54l+ec59TuVtHQMypYFYjieVsaiiIIzsJYQyHxbYOqt4 HTHw== X-Gm-Message-State: ALyK8tKxRvDG6NJnhvUrUS2BO+llKIGpVkQncQj8QO8Wqifd8t79J9kic4DInYfB10uCog== X-Received: by 10.140.228.134 with SMTP id y128mr2961384qhb.81.1464957382376; Fri, 03 Jun 2016 05:36:22 -0700 (PDT) Received: from [10.33.192.30] ([156.154.81.54]) by smtp.gmail.com with ESMTPSA id 76sm984856qgt.34.2016.06.03.05.36.20 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Jun 2016 05:36:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Brian Rosen In-Reply-To: Date: Fri, 3 Jun 2016 08:36:18 -0400 Message-Id: <187FEEA4-E8C4-44AF-B5D6-FA36F87E256B@brianrosen.net> References: <53ADF51F-7024-4A20-AC6D-C300D39BE9CC@brianrosen.net> <4420fe41-8d20-876c-f1e5-090356c887bb@nostrum.com> <9B412CAA-22BC-4915-BC95-EE363F2EBDFF@brianrosen.net> To: Adam Roach X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "mmusic@ietf.org" Subject: Re: [MMUSIC] Transport of "Flash-hook" X-BeenThere: mmusic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multiparty Multimedia Session Control Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jun 2016 12:36:27 -0000 --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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. =20 We probably wouldn=E2=80=99t 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 wrote: >=20 > And, for clarity: >=20 > The SIP GW already sends event 16 when it sees a hookflash? Or do you = need to update its software to accomodate this change? >=20 > /a >=20 > On 6/2/16 16:41, Brian Rosen wrote: >> Sure >>=20 >>=20 >> SIP SIP MF >> SIP-UA =E2=80=94=E2=80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 = Legacy PSAP >>=20 >> A call is up from the SIP-UA to the Legacy PSAP through the IWF and = GW. >>=20 >> The Legacy PSAP is trying to tell the SIP UA to transfer the call >>=20 >> GW is an existing off the shelf, normal IP-PSTN gateway, most of = which actually are 2833 compliant, but I=E2=80=99m trying not to require = conformance to 2833. Note that =E2=80=9CMF=E2=80=9D is tone signaled = analog telephony. The actual MF protocol used here is CAMA. >>=20 >> IWF is a B2BUA that has code we can do anything reasonable with, = which will conform to NENA standards. >>=20 >> The Legacy PSAP signals a transfer by sending FLASH, digit, digit, = digit=E2=80=A6. >>=20 >> The GW gets this signaling, but doesn=E2=80=99t really know what to = do with it, so it passes the sequence to the IWF >>=20 >> The IWF recognizes this is a transfer request, and generates the = REFER to the SIP UA. >>=20 >> The problem I=E2=80=99m solving is the signaling between the GW and = the IWF. I can transport the digits with 4733, but not the flash. >>=20 >>=20 >>> On Jun 2, 2016, at 5:02 PM, Adam Roach < = adam@nostrum.com > = wrote: >>>=20 >>> 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? >>>=20 >>> /a >>>=20 >>> On 6/2/16 15:58, Ted Hardie wrote: >>>> Howdy, >>>>=20 >>>> In-line. >>>>=20 >>>> On Thu, Jun 2, 2016 at 1:49 PM, Brian Rosen < = br@brianrosen.net > = wrote: >>>> Hi Ted >>>>=20 >>>>> On Jun 2, 2016, at 4:15 PM, Ted Hardie < = ted.ietf@gmail.com = > wrote: >>>>>=20 >>>>> Hi Brian, >>>>>=20 >>>>> On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen < = br@brianrosen.net > = wrote: >>>>> Back in RFC2833, the DTMF tones section, code 16 was defined for = =E2=80=9CFlash=E2=80=9D, 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. >>>>>=20 >>>>> 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=E2=80=99m sorry, I don=E2=80=99t understand. >>>>=20 >>>> 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. >>>> =20 >>>> We=E2=80=99re writing a new standard, and I=E2=80=99d 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=E2=80=99= t have a way to signal flash. >>>>=20 >>>>>=20 >>>>>=20 >>>>> 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.=20 >>>>>=20 >>>>>=20 >>>>> 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. =20 >>>> I=E2=80=99m 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=E2=80=99t 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=E2=80=99m = requiring conformance to an obsolete document. >>>>>=20 >>>>>=20 >>>>> 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=E2=80=9D? >>>> It=E2=80=99s approximately true, but it=E2=80=99s 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. >>>> =20 >>>> The older system is standards based, the new system is standards = based, and I need to interwork them in a standards based manner. =20 >>>>=20 >>>> You want everyone else to re-implement flash so that NENA doesn't = replace their proprietary/superseded system? >>>> =20 >>>>> =20 >>>>> We have no other way to transport flash to interwork with our = newer SIP based emergency calling systems. >>>>>=20 >>>>> I=E2=80=99m 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. >>>>>=20 >>>>> 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. >>>>=20 >>>>=20 >>>> 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.=20 >>>>>=20 >>>>> Just my two cents, dislodged by a knee-jerk reaction to making = DTMF more important, >>>> Yeah, I=E2=80=99m not thrilled with more backwards compatibility = stuff either, but I=E2=80=99m also not a fan of an organization like = NENA making up standards using SDP, or requiring conformance to obsolete = standards. >>>>=20 >>>> How about they expressing what the actual gateway signalling = requirements are and we solve them without zombie DTMF shuffling about? >>>>=20 >>>> Just a thought, >>>>=20 >>>> Ted >>>> =20 >>>>=20 >>>> Brian >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> mmusic mailing list >>>> mmusic@ietf.org >>>> https://www.ietf.org/mailman/listinfo/mmusic = >>>=20 >>=20 >=20 --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99t 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 <adam@nostrum.com> = wrote:

=20 =20
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 =E2=80=94=E2= =80=94 IWF =E2=80=94=E2=80=94 GW=E2=80=94=E2=80=94 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=E2=80=99m trying not to require = conformance to 2833. Note that =E2=80=9CMF=E2=80=9D 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=E2=80=A6.

The GW gets this signaling, but doesn=E2=80=99t 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=E2=80=99m 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 = <adam@nostrum.com> 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 = <br@brianrosen.net> wrote:
Hi Ted

On Jun 2, 2016, = at 4:15 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

Hi Brian,
On Thu, Jun 2, 2016 at 12:02 PM, Brian Rosen = <br@brianrosen.net> wrote:
Back in RFC2833, the DTMF tones section, code 16 was defined for =E2=80=9CFlash=E2=80=9D,= 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=E2=80=99m sorry, I don=E2=80=99= 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=E2=80=99re = writing a new standard, and I=E2=80=99d 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=E2=80=99= 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=E2=80=99m 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=E2=80= =99t 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=E2=80=99m 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=E2=80=9D?
It=E2=80=99s approximately = true, but it=E2=80=99s 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=E2=80=99m 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=E2=80=99m not = thrilled with more backwards compatibility stuff either, but I=E2=80=99m 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
mmusic@ietf.org
https://www.ietf.org=
/mailman/listinfo/mmusic





= --Apple-Mail=_CF7FC190-2E4B-403A-B89B-8ECC854E8A5B--