Dear all,
I sent the following mail to the sip-impl mailing list some days ago, but I
havn't received it via the mailing list.
I'm not sure that it was sent correctly, so, I resend it.
Excuse me, if you receive it twice.
*****
Dear Jonathan,
Thank you for your reply.
You seem to assume that the bill is computed by the billing system after cal
ls, but I think someone on a call path has to have all information about the
call to calculate the billing at the time of releasing the call to provide
the following services:
- public phone (to indicate how many coins to be dropped)
- announce of charge
To achieve these services that require computing the bill call by call and r
eal time, isn't SIP a good candidate to provide a container to carry some in
formation?
> > >> From: Jonathan Rosenberg <[EMAIL PROTECTED]>
> > >> To: "'Takumi Ohba'" <[EMAIL PROTECTED]>,
> > >>[EMAIL PROTECTED]
> > >> Subject: RE: [RE: [RE: [Sip-implementors] billing information]]
> > >> Date: Fri, 27 Apr 2001 04:47:57 -0400
> > >> MIME-Version: 1.0
> > >> Status:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> > -----Original Message-----
> > >> > From: Takumi Ohba [mailto:[EMAIL PROTECTED]]
> > >> > Sent: Thursday, April 26, 2001 9:10 AM
> > >> > To: [EMAIL PROTECTED]
> > >> > Subject: Re: [RE: [RE: [Sip-implementors] billing information]]
> > >> >
> > >> >
> > >> > Hi,
> > >> >
> > >> > I think that carrying some billing information is necessary
> > >> > in addition to
> > >> > an ID for association.
> > >> >
> > >> > For example,
> > >> > - The one who calculates the billing does not always the one
> > >> > who determines
> > >> > charging rate. If the charging rate varies call by call basis, it is
> > >> > appropriate to carry such information in SIP message.
> > >>
> > >> No.
> > >>
> > >> You need to carry information in SIP when the caller and callee and
> > proxies
> > >> need to exchange information. This has nothing to do with exchange of
> > >> information between the entity providing the service (the gateways, for
> > >> example), and the entity providing the call detail records, or between
> > the
> > >> entity providing the call detail records, and the billing service.
> > >>
> > >> Pictorially:
> > >>
> > >> Please view in a fixed-width font such as Courier.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> to
> > >> PSTN --
> > >> --
> > >> ---
> > >> --
> > >> +-----+ +------+ +------+ --
> > >> | | SIP | | SIP |Callee|--
> > >> |Caller-------------|Proxy |---------- | GW |
> > >> | | | | | |
> > >> +-----+ +------+ +------+
> > >> |
> > >> |
> > >> |
> > >> | call record
> > >> | information
> > >> |
> > >> |
> > >> |
> > >> +------+ +------+
> > >> |bill | CDR xfer |CDR |
> > >> |generator-------- |generator
> > >> | | | |
> > >> +------+ +------+
> > >> |
> > >> |
> > >> |bill (paper, email)
> > >> |
> > >> |
> > >> |
> > >> |
> > >>
> > >>
> > >> The called gateway sends information about the call (duration, caller,
> > >> callee) to a system that generates the CDR. This does not require pri
cing
> > >> information. THis is not SIP either. This is some kind of logging
> > protocol
> > >> like syslog or something. The CDR generator sends the CDR to the bill
ing
> > >> system. This protocol is not SIP either. The CDR doesn't contain pric
iing
> > >> information at all; the IPDR CDR format (in XML) has no reference to
> > pricing
> > >> whatsoever. The transfer of the CDR to the billing generation system is
> > with
> > >> some non-SIP protocol; IPDR specifies SOAP. The bill generator has
> > pricing,
> > >> which is reflected in the computation of the actual bill.
> > >>
> > >> Note that at no time in this system does pricing information need to be
> > >> transferred in a protocol.
> > >>
> > >> > - Area information is necessary when the charge rate depends
> > >> > on the distance
> > >> > between calling and called users. However, such information
> > >> > is not derived
> > >> > from "From" and "To" headed fields, if the user's address does not
> > >> > correspond to charging areas.
> > >>
> > >> If the callers address has no area information, like when they are
> > calling
> > >> from an IP phone, billing based on the locale of the caller is a
> > proposition
> > >> fraught with opportunity for fraud.
> > >>
> > >> > - If the bill for a call is balanced among network operators
> > >> > call by call
> > >> > basis, it is necessary to carry some kind of network operators'
> > >> > identification to confirm the correctness of the check. (It
> > >> > is assumed that
> > >> > the billing depends on the operators gone through.)
> > >>
> > >> Thats the purpose of the OSP token for SIP:
> > >>
> > http://search.ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt
> > >>
> > >> this does not require pricing information to be conveyed, only an
> > >> authorization token.
> > >>
> > >> OSP itself would convey pricing information in the case of a settlement
> > >> provider. For peer to peer, the pricing information would be negotiated
> > out
> > >> of band, and there is no need to convey it in any protocol.
> > >>
> > >> >
> > >> > I think that such information is strongly depend on the way
> > >> > of billing and
> > >> > the billing system used in the network, therefore SIP should
> > >> > provide general
> > >> > mechanism to carry billing information.
> > >>
> > >> No. This is not needed. Just because you need billing, doesn't mean
> > billing
> > >> information needs to be carried in SIP. Existing SIP networks which b
ill
> > for
> > >> services are not requiring anything you have proposed.
> > >>
> > >> -Jonathan R.
> > >>
> > >> ---
> > >> Jonathan D. Rosenberg 72 Eagle Rock Ave.
> > >> Chief Scientist First Floor
> > >> dynamicsoft East Hanover, NJ 07936
> > >> [EMAIL PROTECTED] FAX: (973) 952-5050
> > >> http://www.jdrosen.net PHONE: (973) 952-5000
> > >> http://www.dynamicsoft.com
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
