Subject: Re: [Sipping] Next draft (-03) of P-Charge-Info now out

From: Sumit Garg <[email-masked]>
Date: Fri, 16 May 2008 07:51:28 -0700 (PDT)

How does this Header compare with P-DCS-Billing-Info
defined in RFC3603 and standard in PacketCable
Standards. The latest update to that RFC
draft-andreasen-sipping-rfc3603bis-05 also now support
specifying jip (Jurisdiction Info parameter) within
the same Header.

Without the support of JIP, P-Charge-Info would not
work properly for porting scenarios as the wrong
RateCenter would end-up getting used by a Billing
service for the examples mentioned in the draft.

I understand that that header also required a
unique-ID...but that should not be the reason to have
2 standards.

-Sumit

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Dan York <[email-masked]>
Date: Mon, 19 May 2008 16:18:05 -0400

Sumit,

Comments inline prefixed with "DY>":

On May 16, 2008, at 10:51 AM, Sumit Garg wrote:

> Standards.

DY> Good feedback. This header should be added to to the  
"Alternatives" section of our draft (and I will do so).

> The latest update to that RFC

DY> Nicely done draft.  I'll send some feedback separately to the  
editors on some minor points.

DY> I would also note that this draft - and the published RFC 3603 -  
contain the use of the term "edge router" (for instance, in section 7)  
which was recently a topic of discussion on this list.

> unique-ID...but that should not be the reason to have

DY> For many billing situations, the P-DCS-Billing-Info header looks  
to be an excellent solution. Similar to the work by the 3GPP in RFC  
3455, it looks at the issue of passing billing information in a  
comprehensive manner and created a solution that addresses a wide  
range of billing scenarios.

DY> However, this ability to address a range of situations adds  
complexity.  As I read the draft, each use of P-DCS-Billing-Info MUST  
include in the header the following:
   - Billing-Correlation-ID, a globally unique identifier
   - Financial-Entity-ID
   - RKS-Group-ID (record keeping server)
and may include a variety of additional parameters including the JIP- 
param you mentioned earlier.

DY> While this may work well in many billing scenarios, there are  
other billing scenarios that do not at all need this level of  
complexity.  In those simpler scenarios all that is needed is simply  
another number to use for billing.  That's the point of P-Charge-Info.  
It is providing a simple solution for simple billing scenarios.

DY> On a more semantic level, I would note that P-DCS-Billing-Info  
mandates in section 7.3 the creation of the header at trusted UACs  
which makes a great deal of sense to me in the residential telephony  
systems for which this header is designed.  On the other hand, as  
noted in section 6.2.1, P-Charge-Info is designed to be used among  
proxies and not to be used at all by normal user agents.  (It may,  
though, be used by user agents associated with PSTN gateways.)

DY> Thanks for pointing me to this draft.  I'll include commentary in  
the next P-Charge-Info draft.

Thank you,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Build voice applications based on open standards.
Find out how at http://www.voxeo.com/free