Subject: [SIP] A question about Authorization-Token

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Thu, 5 Jul 2001 14:28:10 +0100

Dear All,

Sorry for those who get this twice.
In draft-ietf-sip-call-auth-01.txt, Authorization-Token is introduced.
In 5.2.3, it reads:
		5.2.3. Originating Proxy (OP) 
		The Originating Proxy (OP) authenticates the caller, and
verifies the caller is authorized to receive the requested level of QoS. In
cooperation with originating Policy Decision Point (PDP-o), the OP obtains
and/or generates a Media-Authorization-Token that contains sufficient
information for the UAC to get the authorized bandwidth for the media
streams. 
My question is:  if Caller supports 5 codec, callee returns 3 of the five in
its 183 response, how does the OP know what the final codec is going to be
used. In other words, how does the OP generate a token which "contains
SUFFICIENT information for the UAC to get the authorized bandwidth for the
media streams."?
For the terminating side, the token is generated when INVITE comes in, same
question: how does the terminating proxy generate a token which "contains
SUFFICIENT information for the UAC to get the authorized bandwidth for the
media streams."?
Only PRACK for a 183 contains SUFFICIENT information for the media which is
going to be used. So, if the token is used for QoS Authorization, only PRACK
can trigger this procedure.
Or maybe I misunderstand the popurse of the Token, please point out what I
missed.

thanks

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Hemant Singh <[email-masked]>
Date: Thu, 05 Jul 2001 15:28:03 -0400

If caller sends 5 codecs, and your caller returned 3, the caller has
returned a preferred list where the first codec from the 3 will be picked
by proxy/caller UAC. So really, the one codec that got negotiated is
known after the 183 is received at the OP in your case.
The Media-Auth token can be generated.

Hemant

---

From: "Chen, Xin (Xin)" <[email-masked]>
Date: Fri, 6 Jul 2001 10:03:32 +0100

But in terminating side, the token is generated when INVITE comes the callee
side proxy, at that moment, how does the proxy know the codecs supported by
callee?

Xin Chen

Lucent Technologies
Tel: +44 1793 883137
Mobile: +44 7799 034668

-----Original Message-----
From: Hemant Singh [mailto:[email-masked]]
Sent: 05 July 2001 19:28
To: Chen, Xin (Xin)
Cc: [email-masked]'; [email-masked]'
Subject: Re: [SIP] A question about Authorization-Token

Hemant

---

From: Hemant Singh <[email-masked]>
Date: Fri, 06 Jul 2001 09:36:13 -0400

You are confusing the bandwidth authorization with the bandwidth 
reservation step.
The token is generated during the authorization stage when the codec
type or its bandwidth requirements is not necessarily needed.

Only when one goes to reserve the network bandwidth is the codec type
required and of course the token as well.

For your case at the DP, look at section 6.1.2, Figure 2. Only after the 183
message has reached the UAS, the UAS generates a RSVP-PATHt message that
needs the codec info etc. and the auth token.

Hemant