Subject: Re Re: SIP billing ( was Re: What is the view towards H.323?)

From: "Dean Willis" <[email-masked]>
Date: Fri, 13 Nov 1998 17:05:40 -0600

Jonathan Rosenberg wrote:
>Well said. I agree on all points.
Thanks!

Jonathan Rosenberg went on to say:
> Dean Willis wrote:
>> With respect to "draft-pan-diameter-sip-00.txt" -- it's a start. Is
it
>> really necessary to add DIAMETER into SIP, or could we just let each
of
>> the "value add" function providers apply DIAMETER on its own, using
the
>> SIP mechanisms for authentication source, then recording the
transaction
>> using the "accounting" parts?

>I don't think this draft is proposing to add DIAMETER into SIP, but
>rather a way to add SIP authorization to DIAMETER (big difference).

You're absolutely right -- I transposed my nouns in the first posting.
Apologies! I was however questioning the implications of the following
passage from the draft:

--quote--
3.5. Server Considerations
   DIAMETER/SIP policy servers may or may not support SIP protocol.  As
   a result, clients have the option to either 1) send the entire SIP
   message to the servers, or 2) parse the SIP message first and send
   pre-defined SIP AVP's to the servers.
--endquote--

At first reading, I'm not terribly comfortable with having yet another
server that needs a complete rebuild every time SIP deltas. I rather
prefer option 2, and keeping the interface to very clean AVPs.

--
Dean Willis

[email-masked]
MCI Data Architecture LOC 1916/041
IP Telephony Architecture and Standards
voice  972-729-4162 or v 772-4162
page   888-266-1761
fax    972-729-3034

---

From: Ping Pan <[email-masked]>
Date: Sat, 14 Nov 1998 07:54:42 +0800

> prefer option 2, and keeping the interface to very clean AVPs.

Hi, Dean,

I have to admit that we only had option (2) in mind at beginning, :-) then
added option (1) later on for the following reasons:

1) SIP INVITE message has a lot of information that may or may not be
useful for accounting. A DIAMETER client can either somehow be informed on
what to parse, or just parse the entire SIP payload and package them into a
bunch of AVPs before sending them up to the policy server. If that's the
case, why not just send the entire packet up?

2) As SIP getting better, more and more features may be added into the
INVITE message. Unless we want to upgrade all SIP-DIAMETER interface every
time when a new feature being defined, we can always rely on option (1) to
send up total information to the servers.

I'm not sure which way is better. We had had a similar argument during COPS
(RAP protocol) design long time back.

Anyway, there are still a lot of stuff that needs to be worked out. Let's
get it going together. :-)

Thanks!

- Ping

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 13 Nov 1998 19:31:31 -0500

> >Well said. I agree on all points.

And integrated into the SIP FAQ at http://www.cs.columbia.edu/~hgs/sip

> prefer option 2, and keeping the interface to very clean AVPs.

Agreed; there's a trade-off in that transcoding to AVPs means that only
certain header field information will be made available to the server.
Plus, all the transcoding into AVPs (e.g., for the authentication
header) is a bit of a pain. In the first approach, if a new
billing-related SIP header field needs to be defined, the SIP server can
stay the same (it doesn't need to know about the field anyway), and the
new field will be passed to the billing server as is. One solution would
be to do both:

- define standard, protocol (SIP/H.323)-independent fields (probably
containing information in the From and To and possibly a few other
fields; for example?)

- just in case, allow transport of SIP requests as-is for
special-purpose applications.

Henning