Re: draft-york-sipping-p-charge-info-12: ABNF
Dan York <[email protected]> Sun, 4 Dec 2011 23:24:28 -0500
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
--===============3180354345069712178== Content-Type: multipart/alternative; boundary="Apple-Mail=_0E325999-0C7B-4D8D-939D-3D8FD4727CFB" --Apple-Mail=_0E325999-0C7B-4D8D-939D-3D8FD4727CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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 )=20 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.=20 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.=20 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. =20 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: >=20 > 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. >=20 > 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. >=20 > 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) >=20 > -hadriel >=20 >=20 >=20 > On Nov 29, 2011, at 2:01 PM, Richard Shockey wrote: >=20 >> Well well isn't this fascinating. >>=20 >> I was just having a conversation with Dan about this today. >>=20 >> 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'=20 >>=20 >=20 > _______________________________________________ > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping > This list is for NEW development of the application of SIP > Use [email protected] for questions on current sip > Use [email protected] for new developments of core SIP --=20 Dan York [email protected] 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. -------------------------------------------------------- --Apple-Mail=_0E325999-0C7B-4D8D-939D-3D8FD4727CFB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; = ">Hadriel,<div><br></div><div>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 <a = href=3D"http://tools.ietf.org/html/draft-york-sipping-p-charge-info-01">ht= tp://tools.ietf.org/html/draft-york-sipping-p-charge-info-01</a> )&nb= sp;</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Unfortunately, a couple things = happened along the way. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>At this point, all I = want to do is get this document moved along the path toward becoming an = Informational RFC.</div><div><br></div><div>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.</div><div><br></div><div><blockquote = type=3D"cite"><div>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.</div></blockquote></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Any ideas on how to get it moving = faster would be greatly = appreciated.</div><div><br></div><div>Thanks,</div><div>Dan</div><div><br>= </div><div>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:</div><div><br></div><div><a = href=3D"http://tools.ietf.org/html/draft-york-sipping-p-charge-info-12#sec= tion-3">http://tools.ietf.org/html/draft-york-sipping-p-charge-info-12#sec= tion-3</a></div><div><br><div><div>On Dec 4, 2011, at 11:06 AM, Hadriel = Kaplan wrote:</div><br class=3D"Apple-interchange-newline"><blockquote = type=3D"cite"><div><br>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.<br><br>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.<br><br>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)<br><br>-hadriel<br><br><br><br>On Nov 29, 2011, at 2:01 PM, = Richard Shockey wrote:<br><br><blockquote type=3D"cite">Well well isn't = this fascinating.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">I was just = having a conversation with Dan about this = today.<br></blockquote><blockquote = type=3D"cite"><br></blockquote><blockquote type=3D"cite">This draft now = takes on increasing significance as it solves a nasty = little<br></blockquote><blockquote type=3D"cite">problem of billing in = one way SIP traffic (Skype - Google Voice etal) = that<br></blockquote><blockquote type=3D"cite">is vexing the FCC and the = carriers as they try to deal with what is<br></blockquote><blockquote = type=3D"cite">legalistically called "phantom traffic". It's = the preference I'm told is<br></blockquote><blockquote type=3D"cite">if = no calling party number is available use a CIC or OCN code of sorts. = In<br></blockquote><blockquote type=3D"cite">two way it could state the = preference for billing which is either The CPN = or<br></blockquote><blockquote type=3D"cite">'Charging Number' = <br></blockquote><blockquote = type=3D"cite"><br></blockquote><br>_______________________________________= ________<br>Sipping mailing list <a = href=3D"https://www.ietf.org/mailman/listinfo/sipping">https://www.ietf.or= g/mailman/listinfo/sipping</a><br>This list is for NEW development of = the application of SIP<br>Use <a = href=3D"mailto:[email protected]">[email protected]= bia.edu</a> for questions on current sip<br>Use <a = href=3D"mailto:[email protected]">[email protected]</a> for new developments of = core SIP<br></div></blockquote></div><div = apple-content-edited=3D"true"><div style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><div><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; "><br></div></div></div></div></div></div><div> <span class=3D"Apple-style-span" style=3D"border-collapse: separate; = color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; = font-variant: normal; font-weight: normal; letter-spacing: normal; = line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: = 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: = 0px; -webkit-border-horizontal-spacing: 0px; = -webkit-border-vertical-spacing: 0px; = -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span = class=3D"Apple-style-span" style=3D"border-collapse: separate; color: = rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: = normal; font-weight: normal; letter-spacing: normal; line-height: = normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; = text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; = -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: = 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: = auto; -webkit-text-stroke-width: 0px; font-size: medium; "><div = style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; "><div><div style=3D"word-wrap: = break-word; -webkit-nbsp-mode: space; -webkit-line-break: = after-white-space; ">-- <br>Dan York <a = href=3D"mailto:[email protected]">[email protected]</a><br><a = href=3D"http://www.danyork.com/">http://www.danyork.com/</a> &n= bsp;<a href=3D"skype:danyork">skype:danyork</a><br>Phone: = +1-802-735-1624<br>Twitter - <a = href=3D"http://twitter.com/danyork">http://twitter.com/danyork</a></div><d= iv style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; = ">--------------------------------------------------------</div></div><div= style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; = -webkit-line-break: after-white-space; ">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.</div><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: = space; -webkit-line-break: after-white-space; = ">--------------------------------------------------------</div></div></sp= an></span> </div> <br></body></html>= --Apple-Mail=_0E325999-0C7B-4D8D-939D-3D8FD4727CFB-- --===============3180354345069712178== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use [email protected] for questions on current sip Use [email protected] for new developments of core SIP --===============3180354345069712178==--