Draft: draft-ietf-sipping-media-policy-dataset-04 Reviewer: Roni Even Review Date: 3 June 2007 Review Deadline: 11 June 2007 Status: WGLC Summary: The draft is on the right track but has open issues described in the review. Caveat: --------- I am not an expert on relax NG so I can not comment on it. Comments: ---------- 1. The document defines the MPDF which can be used both for session independent and session specific policies. The two mechanisms are loosely related in terms mechanisms but also and when looking at the examples in section 7 they look different in terms of using the schema. The only reason for having them together here is to re-use data elements in the schema. Using the same schema leads to optional elements and merging rules that are relevant only to session specifics policy. 2. One important reason for session policy is support for bandwidth management. The document defines , , 2.1 The bandwidth is measured in kbit/s. How is it related to the B= parameter is SDP in terms of where do you measure the BW (IP layer, RTP, etc.) 2.2 What is the difference between max-bandwidth and max-session-bandwidth and how is it related to the different b= CT/AS/TIAS. I think that section 4.2 should clarify it. 2.3 I am not sure how to specify for to which stream it applies (which m-line). 3. For the media-intermediaries it does not say how to map it to SDP or to SIP to enable this routing when there is more then one specified. 3.1. For outgoing media I assume that the UA that got this parameter can send the media to the first one but how does it route through multiple media intermediaries. 3.2 For incoming media, what do you do with the IP/port of the intermediary, do you put it in the SDP as you IP and port for media. In this case the policy server is in charge of the mapping the correct media routing. This means that the UA needs to give its media receive transport address, works for session dependent but what session independent. 4. In section 7.2 you mention " Examples 1 and 3 are based on one session description, example 2 is based on two session descriptions". Example 3 is missing 5. In section 7.2 maybe have an example that include bandwidth requested from policy server for the session and for a stream. 6. In section 7.2.2 I am a bit confused about the example. This is the document sent by the offerer after receiving the answer from the remote side. I thought that the offerer need to have two different session-info one for the offer and one for the answer. In section 4.2 you refer to local and remote session description, how do send it to the policy server. This was also my impression from the framework.