Subject: [MMUSIC] SDPMedCap m=mcap attribute problem

From: "Guangwu.He" <[email-masked]>
Date: Thu, 27 Mar 2008 11:13:37 +0800

Hi,all
 
SDPMedCap provides five new attributes and four new parameters  for the pcfg
attribute extend, but there is a problem about "a=mcap" attribute.
consider following example:
[offer 1]
      a=creq:med-v0
      m=audio 34560 RTP/AVP 0 18
      a=rtpmap:0 PCMU/8000/1
      a=rtpmap:18 G729/8000/1
      a=mcap:1  G.711/8000/1
      a=mcap:2 PCMU/8000/1
      a=mcap:5 telephone-event
      a=pcfg:1 m=1,5|2,5 pt=1:100,2:101,5:102 
answerer supports SDPMedCap and G.711 so the answer is:
[answer 1]
      a=creq:med-v0
      m=audio 52000 RTP/AVP 100 102            
      a=rtpmap:100  G.711/8000/1
      a=rtpmap:102  telephone-event
      a=acfg:1 m=1,5  pt=1:100,5:102
 
The problem: Intermediaries(e.g.  P-CSCF) examine  the media parameters in
the SDP offer, according to the local policy in the network, for example,
users are not allowed to use G.711 audio codes. if P-CSCF not support
SDPMedCap, it can not "see" the G.711.
 
[Suggest]: why not cancel the "a=mcap" attribute and define  parameter type
"m=" (to the "a=pcfg" and "a=acfg") as:
m=<payload type> *["|"<payload type>]
according to above define, offer is:
[offer 1]
        a=creq:med-v0
        m=audio 34560 RTP/AVP 100 101 0 18 102
        a=rtpmap:0 PCMU/8000/1
        a=rtpmap:18 G729/8000/1
        a=rtpmap:100  G.711/8000/1
        a=rtpmap:101 PCMU/8000/1
        a=rtpmap:102 telephone-event
        a=pcfg:1 m=100,102 | 101,102
 
Intermediaries(e.g P-CSCF) examine  the media parameters and  find G.711 not
allowed to use, intermediaries will return a 488 response containing SDP
payload.
 
Thanks & Regards,
 
Guangwu.He 
_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 27 Mar 2008 10:06:43 +0200

Hi,

The reason for having mcap is to be backward compatible with systems
that do not understand the parameters from this draft, while still
enabling declaration of other codecs for systems who do. This is
standard SDP. In the offer of the first example the P-CSCF can take out
the mcap and pcfg lines if it does not understand them and not send them
to the remote side, if this is the defined policy without breaking the
SDP. 

Your suggestion is that all the potential codecs will be in the m-line
can work today just have also mcap lines for all codecs. The advantage
in the mcap is that they can be specified also at the session level and
be used for latent configuration. 

In your example the P-CSCF passes SDP parameters which it does not
understand (pcfg), that may break other policies like allowed bandwidth
in the case of bcap.

Roni Even 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Guangwu.He
Sent: Thursday, March 27, 2008 5:14 AM
To: [email-masked]
Subject: [MMUSIC] SDPMedCap m=mcap attribute problem

Hi,all

SDPMedCap provides five new attributes and four new parameters  for the
pcfg attribute extend, but there is a problem about "a=mcap" attribute.
consider following example:
[offer 1]
      a=creq:med-v0
      m=audio 34560 RTP/AVP 0 18
      a=rtpmap:0 PCMU/8000/1
      a=rtpmap:18 G729/8000/1
      a=mcap:1  G.711/8000/1
      a=mcap:2 PCMU/8000/1
      a=mcap:5 telephone-event
      a=pcfg:1 m=1,5|2,5 pt=1:100,2:101,5:102 

The problem: Intermediaries(e.g.  P-CSCF) examine  the media parameters
in the SDP offer, according to the local policy in the network, for
example, users are not allowed to use G.711 audio codes. if P-CSCF not
support SDPMedCap, it can not "see" the G.711.

[Suggest]: why not cancel the "a=mcap" attribute and define  parameter
type "m=" (to the "a=pcfg" and "a=acfg") as:
m=<payload type> *["|"<payload type>]
according to above define, offer is:
[offer 1]
        a=creq:med-v0
        m=audio 34560 RTP/AVP 100 101 0 18 102
        a=rtpmap:0 PCMU/8000/1
        a=rtpmap:18 G729/8000/1
        a=rtpmap:100  G.711/8000/1
        a=rtpmap:101 PCMU/8000/1
        a=rtpmap:102 telephone-event
        a=pcfg:1 m=100,102 | 101,102

Intermediaries(e.g P-CSCF) examine  the media parameters and  find G.711
not allowed to use, intermediaries will return a 488 response containing
SDP payload.

Thanks & Regards,

Guangwu.He

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 27 Mar 2008 11:28:15 +0100

Hi
 
I believe that if SDPMedCapNeg is to be used in a "walled-garden"
3GPP-IMS system then the respective standardization bodies will
standardize what codecs are to be allowed already in the SDP offer so I
beleieve that the problem is this case is of a more teoretical nature,
in e.g MMTel the codec set is controlled in e.g 3GPP TS26.114. 
Now there may occur issues in IMS <-> non-IMS interworking scenarios but
I believe that SDP is only one of the issues among other issues like
trust relationships, billing, et.c and this case one must probably solve
the policy issues on a higher level.
 
I believe that SDPMedCapNeg as defined in the last draft will prove
useful in the future and will remove a few of the limitations that exist
with "conventional" or "plain" SDP.  Now there will pop up issues like
the one outlined below but I beleive that with sensible work in other
standardization bodies such as 3GPP we can probably solve these issues.
 
Regards
Ingemar

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Even, Roni
	Sent: den 27 mars 2008 09:07
	To: Guangwu.He; [email-masked]
	Subject: Re: [MMUSIC] SDPMedCap m=mcap attribute problem

	Hi,

	The reason for having mcap is to be backward compatible with
systems that do not understand the parameters from this draft, while
still enabling declaration of other codecs for systems who do. This is
standard SDP. In the offer of the first example the P-CSCF can take out
the mcap and pcfg lines if it does not understand them and not send them
to the remote side, if this is the defined policy without breaking the
SDP. 

	Your suggestion is that all the potential codecs will be in the
m-line can work today just have also mcap lines for all codecs. The
advantage in the mcap is that they can be specified also at the session
level and be used for latent configuration. 

	In your example the P-CSCF passes SDP parameters which it does
not understand (pcfg), that may break other policies like allowed
bandwidth in the case of bcap.

	Roni Even 

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of Guangwu.He
	Sent: Thursday, March 27, 2008 5:14 AM
	To: [email-masked]
	Subject: [MMUSIC] SDPMedCap m=mcap attribute problem

	Hi,all

	SDPMedCap provides five new attributes and four new parameters
for the pcfg attribute extend, but there is a problem about "a=mcap"
attribute.
	consider following example:
	[offer 1]
	      a=creq:med-v0
	      m=audio 34560 RTP/AVP 0 18
	      a=rtpmap:0 PCMU/8000/1
	      a=rtpmap:18 G729/8000/1
	      a=mcap:1  G.711/8000/1
	      a=mcap:2 PCMU/8000/1
	      a=mcap:5 telephone-event
	      a=pcfg:1 m=1,5|2,5 pt=1:100,2:101,5:102 

	The problem: Intermediaries(e.g.  P-CSCF) examine  the media
parameters in the SDP offer, according to the local policy in the
network, for example, users are not allowed to use G.711 audio codes. if
P-CSCF not support SDPMedCap, it can not "see" the G.711.

	[Suggest]: why not cancel the "a=mcap" attribute and define
parameter type "m=" (to the "a=pcfg" and "a=acfg") as:
	m=<payload type> *["|"<payload type>]
	according to above define, offer is:
	[offer 1]
	        a=creq:med-v0
	        m=audio 34560 RTP/AVP 100 101 0 18 102
	        a=rtpmap:0 PCMU/8000/1
	        a=rtpmap:18 G729/8000/1
	        a=rtpmap:100  G.711/8000/1
	        a=rtpmap:101 PCMU/8000/1
	        a=rtpmap:102 telephone-event
	        a=pcfg:1 m=100,102 | 101,102

	Intermediaries(e.g P-CSCF) examine  the media parameters and
find G.711 not allowed to use, intermediaries will return a 488 response
containing SDP payload.

	Thanks & Regards,

	Guangwu.He

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 27 Mar 2008 13:02:12 +0200

Hi,

I think that codec is just one issue with policies.  If the policy
decision is made by an entity who does not understand all the SDP
information that it tried to analyze and yet passes the non recognized
SDP to the other side, this is the problem.

Roni Even

From: Ingemar Johansson S [mailto:[email-masked]] 
Sent: Thursday, March 27, 2008 12:28 PM
To: Even, Roni; Guangwu.He; [email-masked]
Subject: RE: [MMUSIC] SDPMedCap m=mcap attribute problem

Hi

Regards

Ingemar

	Hi,

	Roni Even 

	Hi,all

	Thanks & Regards,

	Guangwu.He

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Thu, 27 Mar 2008 07:25:04 -0700

As you've pointed out, in the case of a middlebox, backward
compatibility is achieved by an entity passing SDP information that it
doesn't recognize.
 
The first example represents a legitimate concern. The middlebox is
expected to enforce a policy in which the codec corresponding to media
type "G.711" is not allowed. The middlebox unknowingly offers "G.711" as
part of a potential configuration.
 
Note: The fact that "G.711" is not an IANA-registered media type
complicates the example, but that's a separate issue.
 
I agree that the second example is not a general solution. However, in
the spirit of the second example, I would expect the middlebox to remove
media formats from the offer which are not allowed.

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Even, Roni
Sent: Thursday, March 27, 2008 6:02 AM
To: Ingemar Johansson S; Guangwu.He; [email-masked]
Subject: Re: [MMUSIC] SDPMedCap m=mcap attribute problem

Hi,

Roni Even  

Hi

Regards

Ingemar

	Hi,

	Roni Even 

	Hi,all

	Thanks & Regards,

	Guangwu.He

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Thu, 27 Mar 2008 08:11:17 -0700

Would it be possible (as an option) to,
 
    1. Restrict the first answer to the actual configuration in the
first offer, and
    2. Include at most one potential configuration in the first answer.
 
There's already a SHOULD requirement for the offerer to initiate a
second offer/answer exchange. Why can't the offerer construct the second
offer based on a potential configuration in the first answer?

Hi,

Roni Even

Hi

Regards

Ingemar

	Hi,

	Roni Even 

	Hi,all

	Thanks & Regards,

	Guangwu.He

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 27 Mar 2008 16:11:38 +0100

Hi
 
I have tried to figure out what happens when middleboxes get an SDP (1st
answer) that is not allowed like is the case is the example below. 
Will the P-CSCF send 488 back to the sender of the answer only or will
it be send also to the offerer ?, my understanding is that the SIP
dialog will be cancelled. Problem is maybe then that the offerer will
not know what is wrong and cannot therefore (easily) determine a better
offer that is more likely to work.
 
/Ingemar

	From: Joe Stone (joestone) [mailto:[email-masked]] 
	Sent: den 27 mars 2008 15:25
	To: Even, Roni; Ingemar Johansson S; Guangwu.He; [email-masked]
	Subject: RE: [MMUSIC] SDPMedCap m=mcap attribute problem

	The first example represents a legitimate concern. The middlebox
is expected to enforce a policy in which the codec corresponding to
media type "G.711" is not allowed. The middlebox unknowingly offers
"G.711" as part of a potential configuration.

	I agree that the second example is not a general solution.
However, in the spirit of the second example, I would expect the
middlebox to remove media formats from the offer which are not allowed.

	Hi,

	I think that codec is just one issue with policies.  If the
policy decision is made by an entity who does not understand all the SDP
information that it tried to analyze and yet passes the non recognized
SDP to the other side, this is the problem.

	Roni Even  

	From: Ingemar Johansson S
[mailto:[email-masked]] 
	Sent: Thursday, March 27, 2008 12:28 PM
	To: Even, Roni; Guangwu.He; [email-masked]
	Subject: RE: [MMUSIC] SDPMedCap m=mcap attribute problem

	Hi

	I believe that if SDPMedCapNeg is to be used in a
"walled-garden" 3GPP-IMS system then the respective standardization
bodies will standardize what codecs are to be allowed already in the SDP
offer so I beleieve that the problem is this case is of a more
teoretical nature, in e.g MMTel the codec set is controlled in e.g 3GPP
TS26.114. 

	Now there may occur issues in IMS <-> non-IMS interworking
scenarios but I believe that SDP is only one of the issues among other
issues like trust relationships, billing, et.c and this case one must
probably solve the policy issues on a higher level.

	I believe that SDPMedCapNeg as defined in the last draft will
prove useful in the future and will remove a few of the limitations that
exist with "conventional" or "plain" SDP.  Now there will pop up issues
like the one outlined below but I beleive that with sensible work in
other standardization bodies such as 3GPP we can probably solve these
issues.

	Regards

	Ingemar

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Even, Roni
		Sent: den 27 mars 2008 09:07
		To: Guangwu.He; [email-masked]
		Subject: Re: [MMUSIC] SDPMedCap m=mcap attribute problem

		Hi,

		The reason for having mcap is to be backward compatible
with systems that do not understand the parameters from this draft,
while still enabling declaration of other codecs for systems who do.
This is standard SDP. In the offer of the first example the P-CSCF can
take out the mcap and pcfg lines if it does not understand them and not
send them to the remote side, if this is the defined policy without
breaking the SDP. 

		Your suggestion is that all the potential codecs will be
in the m-line can work today just have also mcap lines for all codecs.
The advantage in the mcap is that they can be specified also at the
session level and be used for latent configuration. 

		In your example the P-CSCF passes SDP parameters which
it does not understand (pcfg), that may break other policies like
allowed bandwidth in the case of bcap.

		Roni Even 

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Guangwu.He
		Sent: Thursday, March 27, 2008 5:14 AM
		To: [email-masked]
		Subject: [MMUSIC] SDPMedCap m=mcap attribute problem

		Hi,all

		SDPMedCap provides five new attributes and four new
parameters  for the pcfg attribute extend, but there is a problem about
"a=mcap" attribute.
		consider following example:
		[offer 1]
		      a=creq:med-v0
		      m=audio 34560 RTP/AVP 0 18
		      a=rtpmap:0 PCMU/8000/1
		      a=rtpmap:18 G729/8000/1
		      a=mcap:1  G.711/8000/1
		      a=mcap:2 PCMU/8000/1
		      a=mcap:5 telephone-event
		      a=pcfg:1 m=1,5|2,5 pt=1:100,2:101,5:102 

		The problem: Intermediaries(e.g.  P-CSCF) examine  the
media parameters in the SDP offer, according to the local policy in the
network, for example, users are not allowed to use G.711 audio codes. if
P-CSCF not support SDPMedCap, it can not "see" the G.711.

		[Suggest]: why not cancel the "a=mcap" attribute and
define  parameter type "m=" (to the "a=pcfg" and "a=acfg") as:
		m=<payload type> *["|"<payload type>]
		according to above define, offer is:
		[offer 1]
		        a=creq:med-v0
		        m=audio 34560 RTP/AVP 100 101 0 18 102
		        a=rtpmap:0 PCMU/8000/1
		        a=rtpmap:18 G729/8000/1
		        a=rtpmap:100  G.711/8000/1
		        a=rtpmap:101 PCMU/8000/1
		        a=rtpmap:102 telephone-event
		        a=pcfg:1 m=100,102 | 101,102

		Intermediaries(e.g P-CSCF) examine  the media parameters
and  find G.711 not allowed to use, intermediaries will return a 488
response containing SDP payload.

		Thanks & Regards,

		Guangwu.He

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 27 Mar 2008 16:49:08 +0100

Hi
 
The thread below deals with the same issue
http://www.ietf.org/mail-archive/web/mmusic/current/msg06752.html
Looking at this a few weeks later I must however confess that I am not
sure that this solves any problem. Going from an option where the 1st
answer might get rejected you go to an option where the 2nd offer might
be rejected instead. In the later alternative the benefit is possibly
that the offerer has a greater chance to know what was wrong.
 
EUR10000 question is however if this (and other related issues such a
the tampering with the "c=" line in the sdp-cs draft ) are corner cases
that are best resolved with strict reqirements on allowed codecs et.c.
Such requirements are then maybe outside the IETF scope ?.
 
Also, if anything is to be changed regarding this my understanding is
that the changes must be done in the  SDPCapNeg draft as the framework
is defined there.
 
Regards
Ingemar 

	From: Joe Stone (joestone) [mailto:[email-masked]] 
	Sent: den 27 mars 2008 16:11
	To: Even, Roni; Ingemar Johansson S; Guangwu.He; [email-masked]
	Subject: RE: [MMUSIC] SDPMedCap m=mcap attribute problem

	    1. Restrict the first answer to the actual configuration in
the first offer, and
	    2. Include at most one potential configuration in the first
answer.
	 
	There's already a SHOULD requirement for the offerer to initiate
a second offer/answer exchange. Why can't the offerer construct the
second offer based on a potential configuration in the first answer?

	Hi,

	Roni Even

	Hi

	Regards

	Ingemar

		Hi,

		Roni Even 

		Hi,all

		Thanks & Regards,

		Guangwu.He

---

From: Bob Gilman <[email-masked]>
Date: Thu, 27 Mar 2008 16:15:38 -0600

All-
There are a number of reasons we didn't use the payload type number to
identify media capabilities.  The primary one is that one might want to
reuse the same payload type number for different options; using the
media cap number permits "late" binding to a payload type number (in the
pcfg line).  For example, the number of AMR codec format combinations
offered might exceed the number of dynamic payload type numbers
available to distinguish them.

The problem of a middlebox that doesn't understand the cap neg
extensions is, I'm afraid, going to be with us for some time, but
I would hope that entities which wish to meddle with the, SDP will
soon be brought up to spec.  (I suppose I'm an optimist, not a
realist, here :-))  Nevertheless, the existing formulations can permit
the exchange to work as desired.  For example, consider the SDP from
the original example (corrected, I believe, to use G729 and the
standard default payload type numbers, and enhanced slightly to
include telephone-event in the m-line just for this purpose):

       a=creq:med-v0
       m=audio 34560 RTP/AVP 0 18 102
       a=rtpmap:0 PCMU/8000/1
       a=rtpmap:18 G729/8000/1
       a=rtpmap:102 telephone-event
       a=mcap:1 G729/8000/1
       a=mcap:2 PCMU/8000/1
       a=mcap:5 telephone-event
       a=pcfg:1 m=1,5|2,5 pt=1:18,2:0,5:102

If this is sent through a firewall that is designed to reject PCMU,
based on payload type number or rtpmap parameters, then the SDP
should be rejected.  Presumably, the rejection will result in a 488
with some sort of SDP acceptable to the middlebox.  Let's say the
middlebox comes back with something like

       m=audio 12345 RTP/AVP 18 102
       a=rtpmap:0 PCMU/8000/1
       a=rtpmap:18 G729/8000/1
       a=rtpmap:102 telephone-event

Now, the offerer knows it should only (re)offer G.729 with or without
telephone-event:

       a=creq:med-v0
       m=audio 34560 RTP/AVP 18
       a=rtpmap:18 G729/8000/1
       a=mcap:1 G729/8000/1
       a=mcap:5 telephone-event
       a=pcfg:1 m=1,5 pt=1:18,5:102
       a=pcfg:2 m=1 pt=1:18

Now, the answer can come back from the answerer with either

       m=audio 54321 RTP/AVP 18
or
       m=audio 54321 RTP/AVP 18 102

plus the requisite rtpmap line(s) and the corresponding acfg attribute.
The middlebox should be satisfied by this, shouldn't it?

-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

Joe Stone (joestone) wrote:
> ------------------------------------------------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Even, Roni
> *Sent:* Thursday, March 27, 2008 6:02 AM
> *To:* Ingemar Johansson S; Guangwu.He; [email-masked]
> *Subject:* Re: [MMUSIC] SDPMedCap m=mcap attribute problem
> 
> Hi,
> 
> ------------------------------------------------------------------------
> 
> *From:* Ingemar Johansson S [mailto:[email-masked]]
> *Sent:* Thursday, March 27, 2008 12:28 PM
> *To:* Even, Roni; Guangwu.He; [email-masked]
> *Subject:* RE: [MMUSIC] SDPMedCap m=mcap attribute problem
> 
>  
> 
> Hi
> 
>  
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Even, Roni
>     *Sent:* den 27 mars 2008 09:07
>     *To:* Guangwu.He; [email-masked]
>     *Subject:* Re: [MMUSIC] SDPMedCap m=mcap attribute problem
> 
>     Hi,
> 
>     standard SDP. In the offer of the first example the P-CSCF can take
>     out the mcap and pcfg lines if it does not understand them and not
>     advantage in the mcap is that they can be specified also at the
>     understand (pcfg), that may break other policies like allowed
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Guangwu.He
>     *Sent:* Thursday, March 27, 2008 5:14 AM
>     *To:* [email-masked]
>     *Subject:* [MMUSIC] SDPMedCap m=mcap attribute problem
> 
>      
> 
>     Hi,all
> 
>      
> 
>     SDPMedCap provides five new attributes and four new parameters  for
>     the pcfg attribute extend, but there is a problem about "a=mcap"
>     attribute.
>     network, for example, users are not allowed to use G.711 audio
>     codes. if P-CSCF not support SDPMedCap, it can not "see" the G.711.
> 
>      
> 
>     Intermediaries(e.g P-CSCF) examine  the media parameters and  find
>     G.711 not allowed to use, intermediaries will return a 488 response
>     containing SDP payload.
> 
>      
> 
>     Thanks & Regards,
> 
>      
> 
>     Guangwu.He
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Thu, 27 Mar 2008 19:00:26 -0700

Guangwu.He's concern would be best expressed by removing PCMU from the
actual configuration of the initial offer:

       a=creq:med-v0
       m=audio 34560 RTP/AVP 18 102
       a=rtpmap:18 G729/8000/1
       a=rtpmap:102 telephone-event
       a=mcap:1 G729/8000/1
       a=mcap:2 PCMU/8000/1
       a=mcap:5 telephone-event
       a=pcfg:1 m=1,5|2,5 pt=1:18,2:0,5:102

with an answer of the form:

	a=creq:med-v0
	m=audio 12345 RTP/AVP 0 102            
	a=rtpmap:0 PCMU/8000/1
      a=rtpmap:102 telephone-event
	a=acfg:1 m=2,5 pt=2:0,5:102

Again, a non-compliant middlebox (with a policy not to allow PCMU) would
unknowingly offer PCMU.

-----Original Message-----
From: Bob Gilman [mailto:[email-masked]] 
Sent: Thursday, March 27, 2008 5:16 PM
To: Joe Stone (joestone)
Cc: Even, Roni; Ingemar Johansson S; Guangwu.He; [email-masked]
Subject: Re: [MMUSIC] SDPMedCap m=mcap attribute problem

All-

The problem of a middlebox that doesn't understand the cap neg
extensions is, I'm afraid, going to be with us for some time, but I
would hope that entities which wish to meddle with the, SDP will soon be
brought up to spec.  (I suppose I'm an optimist, not a realist, here
:-))  Nevertheless, the existing formulations can permit the exchange to
work as desired.  For example, consider the SDP from the original
example (corrected, I believe, to use G729 and the standard default
payload type numbers, and enhanced slightly to include telephone-event
in the m-line just for this purpose):

       a=creq:med-v0

If this is sent through a firewall that is designed to reject PCMU,
based on payload type number or rtpmap parameters, then the SDP should
be rejected.  Presumably, the rejection will result in a 488 with some
sort of SDP acceptable to the middlebox.  Let's say the middlebox comes
back with something like

       a=creq:med-v0
       m=audio 34560 RTP/AVP 18
       a=rtpmap:18 G729/8000/1
       a=mcap:1 G729/8000/1
       a=mcap:5 telephone-event

       m=audio 54321 RTP/AVP 18
or

-Bob

> type "G.711" is not allowed. The middlebox unknowingly offers "G.711" 
> as part of a potential configuration.
>  

> the spirit of the second example, I would expect the middlebox to 
> remove media formats from the offer which are not allowed.
>  

> standardize what codecs are to be allowed already in the SDP offer so 
> I beleieve that the problem is this case is of a more teoretical 
> nature, in e.g MMTel the codec set is controlled in e.g 3GPP TS26.114.
> 
> Now there may occur issues in IMS <-> non-IMS interworking scenarios 
> but I believe that SDP is only one of the issues among other issues 
> like trust relationships, billing, et.c and this case one must 
> useful in the future and will remove a few of the limitations that 
> exist with "conventional" or "plain" SDP.  Now there will pop up 
> issues like the one outlined below but I beleive that with sensible 
> work in other standardization bodies such as 3GPP we can probably
solve these issues.
> Ingemar
systems
>     bandwidth in the case of bcap.
for

---

From: Bob Gilman <[email-masked]>
Date: Thu, 27 Mar 2008 20:29:21 -0600

I guess I didn't make my intent clear: by listing all the codecs in
the m-line (and indicating the preferred configurations in the pcfg
lines} the middlebox gets to see all the codecs.  It can then reject
the offer if it doesn't permit one or more of the codecs, and can
return the ones it does permit in the SDP included with the 488
message.  The offerer can (re)offer with only the supported codecs.
Of course it would be better to have a more sophisticated middlebox,
but ....
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

---

From: "Joe Stone (joestone)" <[email-masked]>
Date: Thu, 27 Mar 2008 20:27:28 -0700

There's likely a reason why the offerer didn't offer all of the codecs
from all of the potential configurations in the actual configuration.
This reason may not be obvious in a simple example involving only G.711u
and G.729.

I envision certain non-compliant middleboxes (e.g., SBC) filtering out
the "a=pcfg" SDP attribute (thereby disabling capability negotiation
altogether) in order to work-around this type of problem. Time will
tell.

-----Original Message-----
From: Bob Gilman [mailto:[email-masked]] 
Sent: Thursday, March 27, 2008 9:29 PM
To: Joe Stone (joestone)
Cc: Even, Roni; Ingemar Johansson S; Guangwu.He; [email-masked]
Subject: Re: [MMUSIC] SDPMedCap m=mcap attribute problem

I guess I didn't make my intent clear: by listing all the codecs in the
m-line (and indicating the preferred configurations in the pcfg lines}
the middlebox gets to see all the codecs.  It can then reject the offer
if it doesn't permit one or more of the codecs, and can return the ones
it does permit in the SDP included with the 488 message.  The offerer
can (re)offer with only the supported codecs.
Of course it would be better to have a more sophisticated middlebox, but
....
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

> Again, a non-compliant middlebox (with a policy not to allow PCMU) 
> would unknowingly offer PCMU.
> 

> identify media capabilities.  The primary one is that one might want 
> to reuse the same payload type number for different options; using the

> media cap number permits "late" binding to a payload type number (in 
> the pcfg line).  For example, the number of AMR codec format 
> combinations offered might exceed the number of dynamic payload type 
> numbers available to distinguish them.
> 
> would hope that entities which wish to meddle with the, SDP will soon 
> be brought up to spec.  (I suppose I'm an optimist, not a realist, 
> here
> :-))  Nevertheless, the existing formulations can permit the exchange 
> to work as desired.  For example, consider the SDP from the original 

> sort of SDP acceptable to the middlebox.  Let's say the middlebox 
> comes back with something like
> 

>> ---------------------------------------------------------------------
>> -
>> --
>> ---------------------------------------------------------------------
>> -
>> --
>>

>> ---------------------------------------------------------------------
>> -
>> --
>>
not
>> ---------------------------------------------------------------------
>> -
>> --
>>
find
>> ---------------------------------------------------------------------
>> -
>> --
>>

---

From: "Guangwu.He" <[email-masked]>
Date: Fri, 28 Mar 2008 18:35:04 +0800

Hi, all
1. The lots of same codecs format for different options does not exist in
reality, if this situation is present, the best method is use
"a=mfcap"(because "a=mcap" is not use, a=mfcap is also redefine):
Example:
[offer(use SDPMapCap)]:
a=mcap:1-3 AMR/8000/1
a=mcap:4-6 AMR/16000/1
a=mfcap:1,2,3,4 mode-change-capability=1
a=mfcap:5,6 mode-change-capability=2
a=mfcap:1,2,3,5 max-red=220
a=mfcap:3,4,5,6 octet-align=1
a=mfcap:1,3,5 mode-set=0,2,4,7
a=mfcap:2,4,6 mode-set=0,3,5,6
a=pcfg:1 m=1 pt=97
a=pcfg:2 m=4 pt=98
.
[my offer(a new parameter type ("f=") add to the a=pcfg and a=acfg)]
a=rtpmap:97 AMR/8000/1
a=rtpmap:98 AMR/16000/1
a=mfcap:1 mode-change-capability=1
a=mfcap:1 mode-change-capability=2
a=mfcap:3 max-red=220
a=mfcap:4 octet-align=1
a=mfcap:5 mode-set=0,2,4,7
a=mfcap:6 mode-set=0,3,5,6
a=pcfg:1 m=97 f=1,3,5
a=pcfg:2 m=98 f=1,4,6
.
2.Bob' example the a=mcap attributes repeat the a=rtpmap attributes, the
Intermediaries can examine the media parameters, but if SDP have a lots of
codecs, the SDP packet is too big and inefficient .

3.Roni Even say, the advantage in the mcap is that they can be specified
also at the session level and be used for latent configuration. In my
opinion, the a=lcfg that specifies latent media stream configurations when
no corresponding media stream is offered, so it's purpose is, merely
indicate MIME types(other than in m= line) and correlative capability, and
for future offer/answer(so, in a=lcfg list too many parameters is stupid).

Thanks & Regards,

Guangwu.He  

> Sent: Friday, March 28, 2008 6:16 AM
> To: Joe Stone (joestone)
> There are a number of reasons we didn't use the payload type 
> number to identify media capabilities.  The primary one is 
> that one might want to reuse the same payload type number for 
> different options; using the media cap number permits "late" 
> binding to a payload type number (in the pcfg line).  For 
> example, the number of AMR codec format combinations offered 
> might exceed the number of dynamic payload type numbers 
> The problem of a middlebox that doesn't understand the cap 
> neg extensions is, I'm afraid, going to be with us for some 
> time, but I would hope that entities which wish to meddle 
> with the, SDP will soon be brought up to spec.  (I suppose 
> I'm an optimist, not a realist, here :-))  Nevertheless, the 
> existing formulations can permit the exchange to work as 
> desired.  For example, consider the SDP from the original 
> example (corrected, I believe, to use G729 and the standard 
> default payload type numbers, and enhanced slightly to 
> If this is sent through a firewall that is designed to reject 
> PCMU, based on payload type number or rtpmap parameters, then 
> the SDP should be rejected.  Presumably, the rejection will 
> result in a 488 with some sort of SDP acceptable to the 
> middlebox.  Let's say the middlebox comes back with something like
> 
> However, in 
> > *From:* Ingemar Johansson S 
> scenarios 
> > work in other standardization bodies such as 3GPP we can 
> probably solve these issues.
> > 
> >  
> > 
> > Regards
> > 
> > Ingemar
> > 
> >      
> > 
> >     
> > 
> with systems
> it does not
> parameters  for

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Fri, 28 Mar 2008 14:46:48 +0100

Hi

Regarding statement 1) below, I don't agree. The AMR codec is one
example of modern speech codecs with this issue. In a true IP end to end
system you may not have this issue but in order to interoperate with
legacy CS you end up in a situation where you e.g need to negotiate
different mode sets, mode change periods etc. I beleieve 3GPP TS 26.114
appendix A highlights a few of these issues.

Now, if AMR is put aside I believe that you end up in pretty much the
same (or more complex?) situation with modern video codecs such as
H.264. The reason is that given a fairly large span in cellular device
capabilities the offerer should preferrably make it possible to exploit
the receiving endpoints rendering capabilities (and access capabilities)
as much as possible, my gut feeling is that SDPMedCapNeg may become
useful for this purpose.

Regards
Ingemar 

> From: Guangwu.He [mailto:[email-masked]] 
> Sent: den 28 mars 2008 11:35
> To: 'Bob Gilman'; 'Joe Stone (joestone)'
> Cc: 'Even, Roni'; Ingemar Johansson S; [email-masked]
> 1. The lots of same codecs format for different options does 
> not exist in reality, if this situation is present, the best 
> method is use "a=mfcap"(because "a=mcap" is not use, a=mfcap 
> is also redefine):
> Example:
> [offer(use SDPMapCap)]:
> a=mcap:1-3 AMR/8000/1
> a=mcap:4-6 AMR/16000/1
> 2.Bob' example the a=mcap attributes repeat the a=rtpmap 
> attributes, the Intermediaries can examine the media 
> parameters, but if SDP have a lots of codecs, the SDP packet 
> is too big and inefficient .
> 
> 3.Roni Even say, the advantage in the mcap is that they can 
> be specified also at the session level and be used for latent 
> configuration. In my opinion, the a=lcfg that specifies 
> latent media stream configurations when no corresponding 
> media stream is offered, so it's purpose is, merely indicate 
> MIME types(other than in m= line) and correlative capability, 
> and for future offer/answer(so, in a=lcfg list too many 
> parameters is stupid).
> 
> Thanks & Regards,
> 
> Guangwu.He  
> 
> > media cap number permits "late"
> example, the 
> > number of AMR codec format combinations offered might exceed the 
> > number of dynamic payload type numbers available to 
> distinguish them.
> > 
> > here :-))  Nevertheless, the existing formulations can permit the 
> > exchange to work as desired.  For example, consider the SDP 
> from the 
> > original example (corrected, I believe, to use G729 and the 
> standard 
> > default payload type numbers, and enhanced slightly to include 
> > telephone-event in the m-line just for this purpose):
> > 
> >        a=creq:med-v0

---

From: Bob Gilman <[email-masked]>
Date: Fri, 28 Mar 2008 11:28:34 -0600

All-
Thank you for the discussion.  Please see my comments below.
-Bob
-------------------------------------------------------------
Bob Gilman        [email-masked]      +1 303 898 9780

> a=mfcap:6 mode-set=0,3,5,6
[rrg]: The problem with your formulation using an f= parameter is that
        it doesn't tie the format parameters to any particular media
        capability in the case that multiple media capabilities are
        present in a potential configuration (e.g., AMR and telephone-
        events).  I suppose we could fix this with some form similar to
        the pt= parameters, e.g.,
           f=<med-cap-num>:<mfcap-num>[*[";"<med-cap-num>:<mfcap-num>]]
        or
           f=<med-cap-num>:<mfcap-list>[*[";"<mfcap-num>:<mfcap-list>]]
           <mfcap-list>=<mfcap-num>[*[","<mfcap-num>]]

        I think I prefer the way we've done it since it associates the
        codec, parameters, and formatting with one media capability,
        which can then be used compactly in one or more pcfg lines
        (for example, I'd expect to see DTMF telephony events used in
        multiple pcfg lines.)  Having said that, I'd be willing to listen
        to the opinions of others.  In some future time, I hope that
        that every device recognizes media capabilities, and the default
        media subtypes/payload-type-numbers in the m-line become rather
        superfluous - that is, they represent a trivial configuration
        that doesn't require rtpmap or fmtp attributes.  That way, we
        don't waste message space by duplicating a lot of rtpmap/mcap
        and/or fmtp/mfcap contents.

> codecs, the SDP packet is too big and inefficient .
[rrg]: I agree that that's a problem if the middlebox needs to look at
        all the parameters (as it may well need to do in order to
        determine bandwidth for, e.g., video.)  Unfortunately, there's no
        real substitute for the middlebox understanding the entire SDP
        record if it's going to mess with it.  The example I gave was one
        method that could be used to work with an older box if necessary.
        On the other hand, perhaps it's only necessary to put the "worst-
        case" options in the m-line so the middlebox will respond with
        the acceptable parameters if the offer is blocked.  Of course,
        that means the offerer must know what "worst-case" means to the
        middlebox.
> for future offer/answer(so, in a=lcfg list too many parameters is stupid).
[rrg]: Well, you'd like to be able to indicate sufficient parameters in
        an lcfg to insure that a later offer based on it will be
        accepted by the other party.  If you can get away without the
        parameters, you don't need to include them, of course.