Roni,
thanks much for reviewing this document. Comments inline.
1. The draft explains describes two mechanisms the session
independent and the session dependent policies. I did not see what
the relationship between them if any is. I think that at least the
draft should say that they can be implemented independently if there
are no other recommendations.
I've added two sentences to the end of the introduction clarifying this.
If also added a sentence to the end of the Session-independent policy
section clarifying what to do when both mechanisms are used.
2. Section 3.2 describes how a UA discovers the policy servers for
session independent policies based on the configuration framework
ua-profile.
"ua-profile" event package [4] provides a mechanism to discover
policy servers in the local network and the home domain. The "local-
network" profile-type enables a UA to discover a policy server in the
local domain. The "user" profile type enables the discovery of a
policy server in the home domain. A UA compliant to this
specification SHOULD attempt to discover and subscribe to the policy
servers in these two domains"
The configuration framework does not specify the profile data which
is out of scope.
The profile type is not the profile data itself. The profile type
effectively defines how the UA subscribes to the policy server in a
given domain (e.g. in the local or home domain).
So what is the meaning of this section - is this one way to find the
policy server
Yes.
or do you suggest that if you want to have session
independent policies you should have the policy servers defined in
the profile data but then how does a UA identify it in the profile
data, is it by name?
No. The idea is that the UA uses the procedures defined in the config
framework to construct the URI of these servers.
I think this needs more clarification.
I've revised the above paragraph to make this more clear.
3. In section 4.2
" Endpoints set up a separate policy channel to each policy
server and can specifically decide which information they want to
disclose to which policy server"
How does this work with the trust model between the UA and the proxy.
The UA claimed that it got the policy from the proxy but from this
sentence you can assume that the UA got the policy only to what it
asked. I think that the UA need to include in document sent to the
proxy all the information it can map from SDP.
True. The UA can disclose what is requested by a specific policy server
(e.g. offer only or offer/answer). I'll change this sentence accordingly.
4. In section 4.4.2 what will be the proxy behavior if it sends the
Invite with the policy server URI to an endpoint who do not support
session policy. The EP can ignore the request and respond 200 that will
not include the support for the session policy. What will the proxy do
or is it left to local implementation.
The task of the proxy is to convey the policy server URI to the UAS. The
enforcement that the UAS actually uses the URI is outside the scope here
and could happen in the proxy or on the network level (i.e. it is left
to local implementation).
Nevertheless, I think a proxy should be able to know whether the policy
server URI was understood by the UAS (e.g. because it may want to do SDP
modification if it was not understood). To enable this, the UAS now
includes a Supported header into responses that contained a
Policy-Contact header.
5. In section 4.4.6 in the note
" If, however, a policy server cannot respond with
a policy right away, it may return a policy that temporarily
denies the session and update this policy as the actual policy
decision becomes available"
I am not sure how does that work, what will the UA do in this case.
Will it continue with the call without any media sessions?
No, I don't think that would be terribly useful. If the policy server
does not return the admittance decision right away, a UA can decide to
wait, maybe informing the user with something like "All resources are
current busy - Retrying". Alternatively, it could terminate the call
attempt (maybe after a short time).
In section 4.4.3 third line should be field and not filed
Fixed.
Thanks much!
Volker
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
