Subject: Re: [RAI] I-D Action: draft-ietf-sipping-media-policy-dataset-14.txt

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Feb 2012 20:51:07 -0500

(I guess this must go to RAI, since sipping is now closed)

Somehow I managed to ignore this up till now.
I have déjà vu reading this - it feels like SDPng has returned. :-)

I see one possible problem with this:

> 4.1.  Mapping SDP to Session Info Documents
>
>    If a UA has an SDP offer and answer pair [RFC3264] and wants to
>    create a session info document, the UA uses the answer to fill in the
>    elements of the session info document except for the <remote-host-
>    port> and <local-host-port> elements, which are taken from the remote
>    and local SDP respectively.  (The local SDP is the one sent by the
>    UA; the remote session description is the one received from the
>    remote UA.)

I think this isn't quite right. Specifically, the m-line in the offer 
can contain those formats from the offer that the answerer wants to use. 
But it may also contain additional formats that the answerer supports. 
But those added ones, and the formats in the offer that are not in the 
answer, cannot be used for the session at that time.

I think your mapping procedure improperly includes the formats from the 
answer that weren't in the offer.

I guess the mapping could simply say to omit those.
Or you could include <codec> elements for those mentioned in offer or 
answer but not both with enabled=no and perhaps direction to indicate 
which side named it.

	Thanks,
	Paul