Subject: [Sipping] Considerations for Session Policies

From: Kumiko Ono <[email-masked]>
Date: Thu, 20 May 2004 21:50:52 +0900

Volker and Gonzalo,

I read "draft-hilt-sipping-consider-policy-00" with great interest.
Here are few comments.

Section 1:
Is there any order of the two operations? I think the diclosing 
operation of the UA usually needs to be done before receiving the 
instruction of session-specific policy. In addition, we need separate 
messages to diclose media information, such as SUBSCRIBE, in order to 
avoid "ghost ring" in the case as shown in Figure 2. Do you have any 
idea to avoid "ghost ring"?

Do we need the other operation that the proxies see if the session 
follows the instruction of policies?

Section 2-4:
Your proposal is to use the redirect model for session-specific policies. 
In my understanding, the two models have the pros and cons as follows:

Piggyback model vs. Redirect model

*Piggyback

pros.
- Less messages to establish a session.
- Easy to correlate a session and the policy.
   In this case, the policy is session-specific.

cons.
- UA needs to set media information to be protected for end-to-middle in 
request/response.
- Proxy needs to add policy information to be protected for middle-to-
end in request/response.
- It is too late to enforce the policy to the SDP offer/anwer in 200/ACK 
messages.
- Policy information is transmitted to a different network.
- Hard to apply to policy changes during a session. 
   The session timer mechanism could be used.

*Redirect model

pros.
- Policy information can be protected for end-to-end, that is between a 
UA and a policy server.
- Policy information is not transmitted outside of the network that has 
the policy.
- Easy to apply to policy changes during a session.

cons.
- More messages to establish a session.
   A UAC can know the server with the error code for the request.
   However, How does a UAS know the server to have session policy?

- Hard to correlate a session and the policy.
  The message of session-specific policy instruction are different from 
messages of session establishment. How does the proxy server determine 
what policy is instructed to the session?

I don't know how the redirect model works on 3pcc control that needs the 
SDP offer/answer in 200/ACK messages. If the UA discloses the media 
information to the proxy using different messages before sending "200 OK",
  the redirect model can be benefical in this case. However, I don't 
know whether this is applicable to 3pcc control.

Thanks a lot,

Kumiko
--
Kumiko Ono
NTT Network Service Systems Labs.
Tel +81 422 59 4508/Fax +81 422 60 4012

_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 24 May 2004 15:54:44 +0300

Kumiko,

inline:

Kumiko Ono wrote:
> instruction of session-specific policy.

Yes, that is the usual order.

> In addition, we need separate 

Preconditions.

> follows the instruction of policies?

Making sure that the UAs follow the policies is out of scope.

> - Less messages to establish a session.

This is not necessary true. Sometimes it involves more messages, 
actually... and a lot of times, piggybacking is just slower. Everytime a 
UA needs to disclose something to its proxy, it needs to trigger an 
end-to-end message exchange. If both terminals are on slow radio 
accesses, the exchange can be much slower than a direct out-of-band 
exchange with the proxy.

>    However, How does a UAS know the server to have session policy?

See above. I do not think this is a disadvantage of this model.

> what policy is instructed to the session?

The proxy can hand the UA a URI whose user part correlates to the 
session. I do not think this is a hard problem.

Thanks,

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo