Subject: [Sipping] Re: Review of draft-ietf-sipping-media-policy-dataset-04

From: Volker Hilt <[email-masked]>
Date: Sun, 18 Nov 2007 22:15:20 -0500

Roni,

thanks much for the detailed review and apologies for the late response! 
My comments are inline.

Even, Roni wrote:
> Hi, The draft is on the right track but has open issues described in
> the review.
> 
> 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.
> 
I agree that a document is structured differently depending on whether 
it is used for session-specific or session-independent policies. 
However, since the two usages are related in a sense that both deal with 
conveying policies and both share many of the elements defined I think 
it is fine to have them together in one draft. This also avoids that we 
end up with two elements for the same information defined (possibly 
differently) in two places.

> 2. One important reason for session policy is support for bandwidth
> management. The document defines <max-bandwidth>,
> <max-session-bandwidth>, <max-stream-bandwidth>
> 
> 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.)
> 
I've clarified the calculation of the bandwidth and the relation to SDP.

> 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.
> 
I've clarified this in the draft.

The draft currently supports CT and AS but does not support TIAS 
bandwidth limits. It should not be a problem to add this later on by 
defining, e.g., <max-bw-ti>, <max-session-bw-ti> and <max-stream-bw-ti> 
elements if this is needed.

> 2.3  I am not sure how to specify for <max-stream-bandwidth> to which
> stream it applies (which m-line).
> 
I've added a label and a media-type attribute to the <max-stream-bw> 
element. With this, it is possible to define limits for a single stream 
(using the stream label) or for a media type (e.g., audio).

> 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.
> 
Routing streams through multiple intermediaries is indeed underspecified 
and probably needs clarification in this draft and possibly also in the 
session policy framework.

I haven't addressed this issue yet and will produce an new version of 
this draft or both drafts, if needed.

> 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.
> 
Yes, fixed intermediaries don't work for session-independent policies. 
I've therefore removed the intermediaries element from session policy 
documents.

> 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
> 
Fixed.

> 5. In section 7.2 maybe have an example that include bandwidth
> requested from policy server for the session and for a stream.
> 
Done.

> 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.
> 
A session info document can represent both the offer and answer if local 
and remote addresses are present. So I don't think this is in 
contradiction to the framework. I've added a comment on that to the draft.

Thanks,

Volker

_______________________________________________
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