Subject: [MMUSIC] SPD(Med)CapNeg : Potential configurations and pruning

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 1 Aug 2008 11:33:48 +0200

Hi

As I believe that nobody understood what I was trying to say during the MMUSIC session, here a more elaborate explanation. 
It is possible that I kick in an open door and that some text like this already exist in the drafts.

Consider that and SDP offer (with SDP(Med)CapNeg) offer is sent from Alice to Bob, along the path is a policy function (e.g a SBG) that is SDP(Med)CapNeg aware. Due to local policys or hardware/software restrictions Bob or the policy function the SDP may be pruned (i.e unsupported potenial configurations are removed).
If we have the wierd SDP
================
m=audio .....
a=tcap:1 RTP/AVP RTP/SAVP
a=acap:1 crypto:1 xxxxxxxx
a=mcap:1 codec-foo
a=mcap:2 codec-bar
a=pcfg:1 t=2 a=1 m=2
a=pcfg:2 t=1 m=1
================
Consider that a policy function in the network does not support SAVP and codec-foo, this could be due to general policy or hardware limitations. The consequence is then that both a=pcfg lines are removed. 
A better option is then to formulate something like 
================
m=audio .....
a=tcap:1 RTP/AVP RTP/SAVP
a=acap:1 crypto:1 xxxxxxxx
a=mcap:1 codec-foo
a=mcap:2 codec-bar
a=pcfg:1 t=2 a=1 m=2|1
a=pcfg:2 t=1 m=2|1
================
Which after the policing will reduce to 
================
m=audio .....
a=tcap:1 RTP/AVP RTP/SAVP
a=acap:1 crypto:1 xxxxxxxx
a=mcap:1 codec-foo
a=mcap:2 codec-bar
a=pcfg:2 t=1 m=2
================

Although the example above is quite silly we may end up in similar scenarios esp. as there are a alot of speech codecs out there. Having some text that describes this potential problem and some best practice would be good to have in the draft (unless it is already written somewhere..)

Hope that this explains my mumbling earlier
 
/Ingemar

******************************************* 
Ingemar Johansson 
Senior Research Engineer, IETF "nethead" 
EAB/TVP - Multimedia Technologies 
Ericsson Research Ericsson AB 
Box 920 S-971 28 Luleå, Sweden 
Tel: +46 (0)8 4043042 
ECN: 850-43042 
ECC: 850-43074 
Mobile: +46 (0)730 783289 
******************************************* 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Bob Gilman <[email-masked]>
Date: Sun, 03 Aug 2008 12:42:58 -0600

Ingemar-
I think your suggestion is a good one.  Perhaps the advantage of
including as many combinations as supportable should be pointed out
in the Security Considerations for CapNeg-aware middleboxes.  We
tried to make it rather efficient to include lots of potential and
latent configurations, and lots of optional potential or latent
condigurations in session capabilities, but you're correct that it's
easy to appear flexible, yet over-constrain the session in light of
perhaps-unknown middlebox policies.
I'll try to add something if Roni and Flemming agree.
-Bob
-------------------------------------------------------------
Bob Gilman [email-masked] +1 303 898 9780

Ingemar Johansson S wrote:
> Hi
> 
> As I believe that nobody understood what I was trying to say during
> the MMUSIC session, here a more elaborate explanation. It is possible
> that I kick in an open door and that some text like this already
> exist in the drafts.
> 
> Consider that and SDP offer (with SDP(Med)CapNeg) offer is sent from
> Alice to Bob, along the path is a policy function (e.g a SBG) that is
> SDP(Med)CapNeg aware. Due to local policys or hardware/software
> restrictions Bob or the policy function the SDP may be pruned (i.e
> unsupported potenial configurations are removed). If we have the
> wierd SDP
> ================
> m=audio .....
> Consider that a policy function in the network does not support SAVP
> and codec-foo, this could be due to general policy or hardware
> limitations. The consequence is then that both a=pcfg lines are
> removed. A better option is then to formulate something like
> ================
> m=audio .....
> Although the example above is quite silly we may end up in similar
> scenarios esp. as there are a alot of speech codecs out there. Having
> some text that describes this potential problem and some best
> practice would be good to have in the draft (unless it is already
> written somewhere..)
> 
> ******************************************* Ingemar Johansson Senior
> Research Engineer, IETF "nethead" EAB/TVP - Multimedia Technologies 
> Ericsson Research Ericsson AB Box 920 S-971 28 Luleå, Sweden Tel: +46
> (0)8 4043042 ECN: 850-43042 ECC: 850-43074 Mobile: +46 (0)730 783289