Subject: [Sipping] Comment on draft-narayanan-sipping-aaa-diameter-00.txt

From: "Cullen Jennings" <[email-masked]>
Date: Sun, 15 Sep 2002 14:01:15 -0700

I am very happy to see some work in this area - thanks.

Given a call-id does not specify a dialog, I don't think it is a good map to
a diameter session-id. It should at least include the to and from tags.

I think a better solution would involve a network generated billing id. (ala
DCS)

Accounting-Input/Output-Octets/Packets serves no purpose I can imagine.

I think it would be good to look at the things people are currently
collecting from SIP and H.323 calls in billing system. Figure out what they
want to accomplish with this information then figure out a good way to do
that.

If you are defining some AVP, you might want to make the media ones specific
to RTP instead of SIP so they can be used by H.323/MGCP/H.248.

I'd give some thought to what you would need to bill for a call that got
transferred and what is needed for a conference call.

Hope that helps,

Cullen

_______________________________________________
Sipping mailing list  https://www1.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: Henning Schulzrinne <[email-masked]>
Date: Sun, 15 Sep 2002 17:19:16 -0400

> I am very happy to see some work in this area - thanks.

Thanks for your comments.

> I think a better solution would involve a network generated billing id. (ala

Generated by the proxy server that sends the DIAMETER messages?

> Accounting-Input/Output-Octets/Packets serves no purpose I can imagine.

This was motivated by the need to deal with "user-to-user" information 
in SIP messages. There appear to be only two approaches:

- Try to prevent user-to-user signaling by stripping SIP signaling to 
keep SIP from becoming a free (3G) IM / SMS service. In my opinion, 
futile and counterproductive.

- Account for user signaling messages, so that users can be charged if 
they decide to embed their file transfers into headers of the SIP INVITE 
messages.

> want to accomplish with this information then figure out a good way to do

Advice and insights on this would be much appreciated. We want to 
accomplish at least two things:

- gain insight into user SIP message behavior statistics
- session duration accounting

(I won't repeat the usual caveats of using SIP information for the latter.)

> to RTP instead of SIP so they can be used by H.323/MGCP/H.248.

We had discussed this and hope to get to that.

> transferred and what is needed for a conference call.

I'm hoping that a "central mixer" conference call looks similar to a 
point-to-point call. Transfer and redirection is tricky, since there are 
many parties that could be charged, depending on the business model.