Re: [Sipping] draft-york-sipping-p-charge-info-12: ABNF

Dan York <dan-ietf@danyork.org> Mon, 05 December 2011 04:24 UTC

Return-Path: <dan-ietf@danyork.org>
X-Original-To: sipping@ietfa.amsl.com
Delivered-To: sipping@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E4581F0C3F for <sipping@ietfa.amsl.com>; Sun, 4 Dec 2011 20:24:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgS24k9ec8WF for <sipping@ietfa.amsl.com>; Sun, 4 Dec 2011 20:24:33 -0800 (PST)
Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F4611F0C36 for <sipping@ietf.org>; Sun, 4 Dec 2011 20:24:33 -0800 (PST)
Received: by qcsf15 with SMTP id f15so1463784qcs.31 for <sipping@ietf.org>; Sun, 04 Dec 2011 20:24:32 -0800 (PST)
Received: by 10.224.183.65 with SMTP id cf1mr6378515qab.55.1323059071595; Sun, 04 Dec 2011 20:24:31 -0800 (PST)
Received: from pc-00141.lodestar2.local (cpe-66-65-247-87.mass.res.rr.com. [66.65.247.87]) by mx.google.com with ESMTPS id du5sm23094714qab.14.2011.12.04.20.24.30 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 04 Dec 2011 20:24:31 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0E325999-0C7B-4D8D-939D-3D8FD4727CFB"
From: Dan York <dan-ietf@danyork.org>
In-Reply-To: <BBFB72BF-19F1-4CEF-8658-AEF8B3553AF1@acmepacket.com>
Date: Sun, 04 Dec 2011 23:24:28 -0500
Message-Id: <9C261B9F-CB96-4DA2-A5C2-6338F334A450@danyork.org>
References: <7FF1E5E16911C54BB2D57D4C4A2ED35A0C1267A0F5@EXMBXCLUS01.citservers.local> <018301ccaec9$4daa2ec0$e8fe8c40$@us> <BBFB72BF-19F1-4CEF-8658-AEF8B3553AF1@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1251.1)
Cc: Brett Tate <brett@broadsoft.com>, sipping@ietf.org, Richard Shockey <richard@shockey.us>
Subject: Re: [Sipping] draft-york-sipping-p-charge-info-12: ABNF
X-BeenThere: sipping@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "SIPPING Working Group \(applications of SIP\)" <sipping.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipping>, <mailto:sipping-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipping>
List-Post: <mailto:sipping@ietf.org>
List-Help: <mailto:sipping-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipping>, <mailto:sipping-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Dec 2011 04:24:35 -0000

Hadriel,

Soooo... a little background... this P-Charge-Info draft began life in February *2008* as a simple attempt to register a SIP header with IANA per RFC 3427 and to document the then *current practice* where the P-Charge-Info header was being used by my employer at the time (Voxeo, who I recently left in September 2011) and then subsequently how it was being used by people using Sonus Networks equipment. (See http://tools.ietf.org/html/draft-york-sipping-p-charge-info-01 ) 

That was it... a simple attempt to document how the P-Charge-Info header had been used for several *years* inside *existing* private networks so that it could be registered with IANA per RFC 3427.

We (Voxeo) wanted to register the usage so that when we indicated to carriers that we wanted to use P-Charge-Info to exchange billing info, we could point them to a published RFC that defined the header.  The exchange would happen on the private connection between our SIP cloud and theirs, but we wanted easy documentation we could point to. 

We also didn't want further proliferation of even more private headers that we would need to use and so hoped that documenting one would limit the proliferation of more.

Other people and companies subsequently indicated they wanted to use the header as a way to pass the ISUP Charge Number.  Folks from Telcordia, Alcatel-Lucent and other companies have been helping (along with, of course, Sonus Networks). Spencer Dawkins has also become involved because ATIS is apparently looking to reference this header in one of their standards.

Unfortunately, a couple things happened along the way. 

First, our timing was terrible. We got caught up by the RFC3427bis effort that was underway in 2008/9 and that became RFC 5727 in 2010 and changed the way SIP headers were registered. In the midst of that, I received guidance from several folks that we should wait for the completion of that work as the process of registering SIP headers would be "easier".  Second, it turned out that we did need some clarifications on the passing of the ISUP Charge Number via the NPI and NOA parameters, neither of which I personally worked with, and so it required getting assistance from various parties.  Third, I had some changes within my role at my employer that added some delays on my end.

In the meantime, a good number of folks out there started to seriously use this document and this header and have been asking rather regularly for the past year or so about when this work will be completed so they can have a published document that they can reference.  

At this point, all I want to do is get this document moved along the path toward becoming an Informational RFC.

I actually thought it was good to go until last week when these questions were raised about the ABNF. Not being an ABNF expert, I'm trying to come to closure on what I need to get into the draft so that it will be clear to implementors and will work for them.

> I can't remember where Sonus encodes the noa/npi fields, but I believe Dialogic encodes them as header-params in a "P-Charge-Info" header, not userinfo-params.


Given that my co-author, Tolga Asveren, is from Sonus and he has been the main source of info for the noa/npi parameters, I'm going to believe that Sonus encodes them as userinfo-params.  Unfortunately, given the path this draft has taken, Dialogic could have encoded them as header-params based on earlier versions of this draft (up to -09) where they were shown as being header-params. This was corrected in version -10 in October 2010, but obviously anyone doing an implementation in between would have had the guidance to use header-params.

So again, at this point, I'd really just like to get this draft moved along so that we can document the current usage (except, I guess, for Dialogic) within private networks.

Any ideas on how to get it moving faster would be greatly appreciated.

Thanks,
Dan

P.S. As to the "P-Charge-Info" name and RFC 5727, I'll again note that this originated in 2008 with trying to document current usage and pre-dates RFC 5727 (by 2 years). We address that here:

http://tools.ietf.org/html/draft-york-sipping-p-charge-info-12#section-3

On Dec 4, 2011, at 11:06 AM, Hadriel Kaplan wrote:

> 
> If the goal is to make it an interoperable header to be used outside of a private network, rather than to just document a private header used by a particular vendor, then I would suggest this discussion be moved to DISPATCH rather than this supposedly-dead SIPPING mailing list.
> 
> Further, it would probably require changing the header name (per RFC 5727), and getting consensus on the syntax and semantics.  It would hopefully NOT require a new mini-WG, but could be an individual submission handled by the AD or an independent submission to the RFC Editor.
> 
> Lastly, I should note that this draft in its current form contradicts some actual deployed usage of this header - in particular, I can't remember where Sonus encodes the noa/npi fields, but I believe Dialogic encodes them as header-params in a "P-Charge-Info" header, not userinfo-params.  IF two vendors use the same header name but in different ways, then I think it argues even more strongly to use a brand-new header name for this draft. (and don't use "Charge", because that's already used by yet another vendor)
> 
> -hadriel
> 
> 
> 
> On Nov 29, 2011, at 2:01 PM, Richard Shockey wrote:
> 
>> Well well isn't this fascinating.
>> 
>> I was just having a conversation with Dan about this today.
>> 
>> This draft now takes on increasing significance as it solves a nasty little
>> problem of billing in one way SIP traffic (Skype -  Google Voice etal) that
>> is vexing the FCC and the carriers as they try to deal with what is
>> legalistically called "phantom traffic".   It's the preference I'm told is
>> if no calling party number is available use a CIC or OCN code of sorts. In
>> two way it could state the preference for billing which is either The CPN or
>> 'Charging Number' 
>> 
> 
> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use sip-implementors@cs.columbia.edu for questions on current sip
> Use sip@ietf.org for new developments of core SIP


-- 
Dan York  dyork@lodestar2.com
http://www.danyork.com/   skype:danyork
Phone: +1-802-735-1624
Twitter - http://twitter.com/danyork
--------------------------------------------------------
All comments and opinions are entirely my own and have no connection whatsoever to any employer, past or present. Indeed, by tomorrow even I might be disavowing these comments.
--------------------------------------------------------