RE: SIP AAA and QoS Attributes

["Roy, Radhika R, ALABS" <rrroy@att.com>]

Inline [RRR]

Thanks to Wolfgang for sending this message - Radhika

-----Original Message-----
From: Wolfgang Beck [mailto:wolfgang.beck01@t-online.de]
Sent: Sunday, January 04, 2004 2:43 PM
To: radiusext@ops.ietf.org
Subject: SIP AAA and QoS Attributes


- SIP UASs (eg. SIP Proxies, PSTN Gateways, Application Servers) use
SIP specific RADIUS (or DIAMETER) attributes to do AAA for SIP specific
services (I am working on an updated version of the sterman draft which
should be available at the beginning of february).

[RRR] Good. Will it also include QoS abstraction/attributes for each
media (audio, video, data) that will be a part of the SDP messages in
SIP?

- RSVP / NSIS etc. routers or other intermediaries involved with
resource
reservation use their own RADIUS (or DIAMETER) attributes. I am really
astonished that there isn't more activity in this area. Who would invest
into a public bandwidth reservation architecture without being able to
charge for it?

[RRR] That is exactly right. Each should use its own way of dealing with
RADIUS/DIAMETER where needed. That is why, I have been directing the
discussion along the same line when QoS attributes are being discussed.
In fact, in this way, RADIUS/DIAMETER may act as glue for various
services/layers.

- Media Accounting is a bit different from QoS acounting. QoS accounting
says: 'A has reserved a flow of x kb/s for 120 seconds', while Media
Accounting says: 'A has sent x packets and received y packets. The
session
duration was z seconds, the average roundtrip delay was p, the average
jitter buffer length was q, there were r seconds with errors etc'. Media
Accounting is necessary if there is no resource reservation available.

[RRR] We can revisit this when we will have more handle on QoS
attributes for billing/accounting, when needed.

SIP and resource reservation should be kept separate. The SIP WG still
fights bravely against any attempts to make SIP a resource reservation
protocol.

[RRR] Absolutely, you are right. For example, RFCs like 3312 provides
indication when resources reservation in SIP should be started and
completed before sending other signaling messages (e.g., reserve
resources before sending the 180 ringing response). However, RFC 3312
never says how resources reservation needs to be done or what kinds of
QoS signaling mechanisms need to be used for resources reservation.


--
Wolfgang Beck
T-Systems GmbH

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>