| 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.
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: On Dec 4, 2011, at 11:06 AM, Hadriel Kaplan wrote:
-- Dan York dyork@xxxxxxxxxxxxx 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. -------------------------------------------------------- |
_______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
