Subject: [MMUSIC] RE: draft-ietf-mmusic-sdp-capability-negotiation-05.txt - replace/delete operators

From: "Stach, Thomas" <[email-masked]>
Date: Sun, 18 Mar 2007 18:28:02 +0100

Fleming, 

I agree that removing the DELETE/REPLACE operators does not give a complete solution to 
the general problem of negotiating SDP attributes and transport protocols. 
However, the complete solution tends to be rather complex, 
at least more complex than necessary for the best-effort SRTP case.
So,I'd like to propose a lite version of SDP capability negotiation. 
It will not be complete,  but sufficient for best-effort SRTP and its restrictions are clearly understood. 
It could look as follows:
- Support for all attributes of the base spec (tcap, acap, pcfg/acfg csup/creq) with some restriction
- The offerer must not repeat attributes from the actual configuration in a potential configuration.
- The attributes indicated in a potential config are always added to the actual config
- The pcfg line must not contain DELETE/REPLACE operators in the "a=" value
- optional indication of a=csup/creq:cap-lite 

With this functionality it would be possible to implement best effort SRTP with fallback to RTP (as indicated in the actual config) at a reduced level of complexity.
Any opinions?

Regards
Thomas

> -----Original Message-----
> From: Flemming Andreasen [mailto:[email-masked]] 
> Sent: Thursday, March 15, 2007 10:23 PM
> To: Stach, Thomas
> Cc: [email-masked]
> Subject: Re: 
> draft-ietf-mmusic-sdp-capability-negotiation-05.txt - 
> replace/delete operators
> 
> 
> 
> Stach, Thomas wrote:
> > Fleming, 
> >
> > thanks for addressing in draft-05 the issue about 
> > replacement semantics versus additive semantics for the 
> a=acap attribute
> >
> > that the design team discussed in the last telco before the 
> Prague IETF.
> >
> > A short recapitulation for those not involved in the telco:
> > The issue evolved since SDP capability negotiation does not restrict
> > what a=acap can transport. 
> > E.g. and offer like the following would be allowed in draft-04
> >       v=0
> >       o=- 25678 753849 IN IP4 192.0.2.1
> >       s=
> >       t=0 0
> >       c=IN IP4 lost.example.com
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 L16/8000
> >       a=acap:1 a=rtpmap:97 ILBC
> >       a=pcfg:1 a=1
> >
> > Here, the a=acap line repeats the rtpmap attribute from the actual
> > configuration for payload type 97.
> > It is not clear whether the m-line  for pcfg:1 includes the rtpmap
> > attributes
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 L16/8000
> >       a=rtpmap:97 ILBC
> > or 
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 ILBC
> > Of course the first alternative is ambiguous and something 
> must be done.
> >
> > I had some problems to understand how draft-05, resolves this.
> > I believe just replacing the a=pcfg from above with 
> a=pcfg:1 a=/1 is not
> > correct.
> > As I understand it, the / operator removes all a=rtpmap 
> lines and the
> > offer for the potential configuration would get the 
> following m-line 
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:97 ILBC
> > Payload type 96 is no longer defined.
> >
> >   
> Correct.
> > Thus the offer must repeat ALL a=rtpmap lines and would have to look
> > like 
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 L16/8000
> >       a=acap:1 a=rtpmap:97 ILBC
> >       a=acap:2 a=rtpmap:96 L8/8000
> >       a=pcfg:1 a=/1,2
> > or somewhat longer
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 L16/8000
> >       a=acap:1 a=rtpmap
> >       a=acap:2 a=rtpmap:96 L8/8000
> >       a=acap:3 a=rtpmap:97 ILBC
> >       a=pcfg:1 a=-1,2,3
> >
> >   
> Or, in this particular case:
> 
>       m=audio 49230 RTP/AVP 96 97
>       a=rtpmap:96 L8/8000
>       a=rtpmap:97 L16/8000
>       a=acap:1 a=rtpmap:97 ILBC
>       a=acap:2 a=rtpmap:96 L8/8000
>       a=pcfg:1 a=-m:1,2
> 
> 
> > In the end, I think that the replace and delete operators just adds
> > complexity and do not gain much here.
> > The whole issue could be resolved if the spec says something like:
> > "If attributes are common to the actual config and a 
> potential config
> > all of that attributes in the actual config are deleted. 
> The potential
> > config must take care that all necessary attributes are 
> restored again."
> >   
> For the common case, I don't see much difference between what you 
> propose above and what is currently in the spec. You are effectively 
> arguing that the REPLACE and DELETE operators should be removed and 
> instead, the implementation is responsible for detecting that 
> there are 
> rtpmap (or other) attributes in both the actual and potential 
> configuration and the implementation is now responsible for deleting 
> them, whereas the potential configuration still have to 
> explicitly add 
> all necessary rtpmap (or other) attributes to the actual 
> configuration 
> that is being selected.
> 
> Loosing the DELETE operator would mean that we are no longer able to 
> remove attributes with a different name. One example where that is 
> needed is when we have different key-management schemes, or 
> the original 
> actual configuration is secure RTP and hence uses a keying mechanism, 
> whereas the selected one does not (and hence the keying 
> mechanism should 
> really be removed).
> 
> Loosing the REPLACE operator means that we will now *always* have to 
> replace attributes that have the same name. Not necessarily a 
> huge loss, 
> but you could have scenarios where that is less than optimal (for 
> example if the actual configuration included candidate attributes for 
> UDP only, and a potential configuration wanted to add 
> attributes for TCP 
> on top of that).
> 
> If we want to do something here, then I think we should 
> rather consider 
> whether we want to provide more extended replacement semantics for 
> "fmtp" and "rtpmap" attributes and effectively say, that only 
> rtpmap and 
> fmtp attributes that have the same media format (e.g. payload 
> type) will 
> actually be replaced.
> 
> > We would then get back the same syntax from draft-04 and 
> following SDP
> > offer would a have to be sent
> >       m=audio 49230 RTP/AVP 96 97
> >       a=rtpmap:96 L8/8000
> >       a=rtpmap:97 L16/8000
> >       a=acap:1 a=rtpmap:96 L8/8000
> >       a=acap:2 a=rtpmap:97 ILBC
> >       a=pcfg:1 a=1,2
> >
> > I doubt as well that the delete operators (-m:, -s:, -1) 
> are necessary.
> > I can't remember an issue and haven't found an example yet, 
> where the
> > need arises to explicitly delete an attribute line from the 
> actual offer
> > from an offer based on a potential configuration. 
> key-mgmt and crypto attributes are examples of those (see e.g. the 
> example in Section 4.4). The "global" delete (at either session or 
> media-level) is just to make it simpler.
> 
> > If necessary at all
> > that could be done as well by an extension to the 
> capability negotiation
> > framework. The base spec should just mention the potential 
> problem of
> > conflicting attribute in order to provide some guidance 
> that care must
> > be taken in this respect.
> >   
> Per the above, I think we need these abilities in the base 
> spec. Biggest 
> question in my mind is whether we want to make some of them more 
> fine-grained, e.g. for rtpmap and fmtp attributes.
> 
> -- Flemming
> 
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 19 Mar 2007 01:37:38 -0400

> at least more complex than necessary for the best-effort SRTP case.
We received explicit guidance from the ADs at the last IETF to not just 
consider the best-effort SRTP case. We have produced requirements in 
accordance with that as well as a solution document, and you yourself 
have been part of the design team that proceeded this way.

> - The attributes indicated in a potential config are always added to the actual config
This could make it difficult (potentially ambiguous) to negotiate 
alternative keying mechanisms.
> With this functionality it would be possible to implement best effort SRTP with fallback to RTP (as indicated in the actual config) at a reduced level of complexity.
If all you want to solve is the best-effort SRTP case, then why go 
through the complexity of the above. There are much simpler suggestions 
for the best-effort SRTP case only already.

Before we start discussing alternative solutions, I'd like for you to 
take a step back and clearly explain
1) The scope of the problem you want to solve.
2) The problems you have with the current solution (e.g. is it purely 
the delete-attributes stuff that has been introduced or does it go 
beyond that).

Thanks

-- Flemming

---

From: "Stach, Thomas" <[email-masked]>
Date: Mon, 19 Mar 2007 09:50:21 +0100

Fleming,

see inline

-----Original Message-----
From: Flemming Andreasen [mailto:[email-masked]]
Sent: Mon 3/19/2007 06:37
To: Stach, Thomas
Cc: [email-masked]
Subject: Re: draft-ietf-mmusic-sdp-capability-negotiation-05.txt - replace/delete operators

<TS>Yes, and draft-05 addresses the general problem in accordance with this guidance. 
However I'm concerned whether this lays the hurdle relatively high for a "simpler" application of capability negotition.
</TS>

<TS>Yes, but in this case the solution to the general problem would have to be used.
</TS>

<TS> Yes, but they did not get accepted. 
This capabalitiy negotiation-lite proposal is of course more complex as e.g. the Kaplan draft, 
but it could also be applied for other things than best-effort SRTP.
</TS>

<TS>Not surprisingly my main application would be best-effort SRTP
There were as well concerns about the complexity of the solution in the base spec.
So I try to propose something along the line of the solution in the base spec, that
of course has limitation, but is simpler in order to lay the hurdle a little bit lower for initial implementation.
If this concern about complexity is solely with me and if the proposal does not gain any support
I would of course have to step back and will of course accept the solution from draft-05.
That solution is good and complete including the replace/delete-attributes, 
just providing more than necessary for best-effort SRTP, 
which seems currently to be the main application of this spec.

Regards
Thomas
</TS>

Thanks

-- Flemming