<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Is this an Interstate or IntRAstate call I&#8217;m making? Determination of Jursidiction.</title>
	<atom:link href="http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/feed/" rel="self" type="application/rss+xml" />
	<link>http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/</link>
	<description>Notes, Hints, Tricks and Rants on SIP and Other Experiments in our Labs</description>
	<pubDate>Thu, 20 Nov 2008 17:14:10 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: Dan York</title>
		<link>http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/#comment-18</link>
		<dc:creator>Dan York</dc:creator>
		<pubDate>Wed, 19 Mar 2008 00:54:47 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/#comment-18</guid>
		<description>Mark,

Good question.  Let me explain about how this draft came about.  RFC 3427 defines a process whereby people can create "private headers" for SIP (referred to as "P-headers") that pass data of purely informational nature between SIP devices that are typically within the same "trust domain", i.e. the parties exchanging the information have some type of established relationship.  This process was established so that people could experiment with SIP in lab/educational environments and try out various different types of new headers. This is very similar to and was modeled after the "X-headers" that exist in email.

RFC 3427 also states very definitively that when a P-header leaves the lab environment and enters into production usage, it is to be registered with IANA to avoid naming conflicts and so that others know of its usage.  The process of registration involves submitting an Internet-Draft and ultimately getting that established as an Informational RFC.

Now, several years ago, Sonus Networks started using this P-Charge-Info P-header within their devices.  When we were discussing how to solve the Interstate-vs-Intrastate issue with one of our carriers, that carrier, who had Sonus equipment, suggested we use the P-Charge-Info header as a way to pass billing information back and forth.  We investigated the idea, found it easy to implement, did so, and definitely liked the results.  So we're now using it with multiple carriers and are quite happy.  So yes, the carriers we work with *are* recognizing it for billing purposes.

However, being huge supporters of open standards - and the open standard *process*, we noticed that while the P-Charge-Info header was in common production usage it had not been officially registered with IANA. We wanted to do so in part because it is "the right thing" to do by the official IETF process, and also because we wanted something to which we can point new carriers to when we talk about this header.  We approached Sonus Networks about whether they wanted to join with us in the submission to the IETF.  They did, and so Tolga Asveren from Sonus Networks and I submitted this Internet-Draft.

So this draft is just the first step in an IETF process that will take a while.  We've already received a good bit of feedback and Tolga and I will be submitting another revision soon. (And any and all feedback is welcome!)  Ultimately our goal is to document the current usage, register it with IANA and make it so that others can clearly implement the header in ways that make sense.

Hopefully that helps explain the origin of both the draft and the header.  If you have further question, please do feel free to leave them here.

Dan</description>
		<content:encoded><![CDATA[<p>Mark,</p>
<p>Good question.  Let me explain about how this draft came about.  RFC 3427 defines a process whereby people can create &#8220;private headers&#8221; for SIP (referred to as &#8220;P-headers&#8221;) that pass data of purely informational nature between SIP devices that are typically within the same &#8220;trust domain&#8221;, i.e. the parties exchanging the information have some type of established relationship.  This process was established so that people could experiment with SIP in lab/educational environments and try out various different types of new headers. This is very similar to and was modeled after the &#8220;X-headers&#8221; that exist in email.</p>
<p>RFC 3427 also states very definitively that when a P-header leaves the lab environment and enters into production usage, it is to be registered with IANA to avoid naming conflicts and so that others know of its usage.  The process of registration involves submitting an Internet-Draft and ultimately getting that established as an Informational RFC.</p>
<p>Now, several years ago, Sonus Networks started using this P-Charge-Info P-header within their devices.  When we were discussing how to solve the Interstate-vs-Intrastate issue with one of our carriers, that carrier, who had Sonus equipment, suggested we use the P-Charge-Info header as a way to pass billing information back and forth.  We investigated the idea, found it easy to implement, did so, and definitely liked the results.  So we&#8217;re now using it with multiple carriers and are quite happy.  So yes, the carriers we work with *are* recognizing it for billing purposes.</p>
<p>However, being huge supporters of open standards - and the open standard *process*, we noticed that while the P-Charge-Info header was in common production usage it had not been officially registered with IANA. We wanted to do so in part because it is &#8220;the right thing&#8221; to do by the official IETF process, and also because we wanted something to which we can point new carriers to when we talk about this header.  We approached Sonus Networks about whether they wanted to join with us in the submission to the IETF.  They did, and so Tolga Asveren from Sonus Networks and I submitted this Internet-Draft.</p>
<p>So this draft is just the first step in an IETF process that will take a while.  We&#8217;ve already received a good bit of feedback and Tolga and I will be submitting another revision soon. (And any and all feedback is welcome!)  Ultimately our goal is to document the current usage, register it with IANA and make it so that others can clearly implement the header in ways that make sense.</p>
<p>Hopefully that helps explain the origin of both the draft and the header.  If you have further question, please do feel free to leave them here.</p>
<p>Dan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark headd</title>
		<link>http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/#comment-16</link>
		<dc:creator>Mark headd</dc:creator>
		<pubDate>Mon, 17 Mar 2008 20:27:06 +0000</pubDate>
		<guid isPermaLink="false">http://blogs.voxeo.com/voiplab/2008/03/17/is-this-an-interstate-or-intrastate-call-im-making-determination-of-jursidiction/#comment-16</guid>
		<description>So, even though the above is a draft, is Voxeo currently using the 'P-Charge-Info' header for outbound calls?  Are the carriers recognizing it for billing purposes?</description>
		<content:encoded><![CDATA[<p>So, even though the above is a draft, is Voxeo currently using the &#8216;P-Charge-Info&#8217; header for outbound calls?  Are the carriers recognizing it for billing purposes?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
