Subject: [MMUSIC] SDP media capabilities question

From: 贺广武 <[email-masked]>
Date: Thu, 31 Jan 2008 16:37:27 +0800

Hi,Reading the draft(draft-ietf-mmusic-sdp-media-capabilities-02.txt),  I
have the following question:

1) I don’t understand the a=mcap extension intent? Because media types and
media subtypes can provide by m= line, I guess intent of this extension is
only compress SDP packet? Additional, I have no ideal about “a=mcap: 1
audio image text” is correct or wrong.

2) The bandwidth negotiation(a=bcap) can not solve issue in
3.10("draft-ietf-mmusic-sdp-capability-negotiation-08.txt").

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

---

From: Bob Gilman <[email-masked]>
Date: Thu, 31 Jan 2008 23:57:17 -0700

Sammy-

My responses are embedded below.  The idea of negotiating multiple MIME

types for a single media stream may have some merit, as discussed below.

I'd like to hear from my coauthors and the mailing list about
this and

the problems (or solutions) it might generate.

-Bob

Guangwu He wrote:

The offeror might send multiple proposed configurations, one

with PCMU and DTMF events, one with G.729 and DTMF events,

and one with iLBC and DTMF events.

According to this draft,offer is:

a=mcap:1 audio PCMU G.729 iLBC DTMF

m=audio 49170 RTP/AVP 97 98

a=rtpmap:97 PCMU/8000

a=rtpmap:98 DTMF/8000

a=pcfg:1 m=1,4 pt=1:100 4:104

a=pcfg:2 m=2,4 pt=2:101 4:104

a=pcfg:3 m=3,4 pt=3:102 4:104

[rrg]: Yes.  Note that the configuration represented by the m= line is
the

same as pcfg:1, except for payload types.  For completeness, we
should

include at least one ecap attribute to set the encoding rate.

according to RFC3264,offer is:

m=audio 49170 RTP/AVP 97 98 99

a=rtpmap:97 PCMU/8000

a=rtpmap:98 G.729/8000

a=rtpmap:99 iLBC/8000

m=audio 49170 RTP/AVP 100

a=rtpmap:100 DTMF/8000

They are equivalent.

[rrg]: I don't think this version is equivalent.  I can't find the
reference

in RFC 3264 for using two media streams with the same transport
address.

SDP (RFC 4566, section 5.14) states:

"The semantics of multiple "m=" lines using the same transport

address are undefined.  This implies that, unlike limited past

practice, there is no implicit grouping defined by such means
and

an explicit grouping framework ... should instead be used to
express

the intended semantics."

RFC 3264, section 8.3.3, does make a case for negotiating
multiple

MIME types for a single media stream when the same information
may be

encoded either of several ways.  The example given involves audio

encoding of faxmodem signals and data encoding of fax content
(e.g.,

T.38).  If I recall correctly, this problem has been treated in
the

past by a number of techniques:

a. define an audio subtype for an encoding that's
really

equivalent to some other type/subtype, thereby
making

it easy to include in an m=audio line.

b. use the same port number to imply that multiple m=
lines

refer to the same stream.

c. use offer/answer to renegotiate the type/subtype
for an

existing stream.

I know you example is correct,but from
the draft,mcap define is:

a=mcap:<med-cap-num>
<subtype>*[ <subtype>],

not you mention:

a=mcap:<med-cap-num>
<type> <subtype> *[<subtype>],

and in this draft(p10) example is:a=
mcap:2 H263-1998, H264.

Are the draft ambiguous?

[rrg]: Not ambiguous, just wrong :-)  I left out the MIME types in
several

examples.  I've corrected this in the upcoming version (-03).

The draft say:we extend the framework by
defining media capabilities

that can be used to
negotiate media types and their associated

parameters.

according the content of draft,the
framework can not be used to

negotiate media types,but media subtypes.

[rrg]: Although I always assumed the MIME types within a media stream

offer would be the same, I'm inclined to permit the use of
multiple

types.

thinks.

Sammy

Sammy-

1. The mcap attribute permits one to specify a proposed

configuration that contains media subtypes that are

different from the subtype(s) included in the configuration

defined by the m= line.  For example, one might want to

specify an m= line with PCMU audio (by default, the least

preferred configuration), and a (preferred) configuration

offering G.729 and DTMF events.  This is also useful to

agree on a single audio encoding in one exchange: the

offeror might send multiple proposed configurations, one

with PCMU and DTMF events, one with G.729B and DTMF events,

and one with iLBC and DTMF events.  The answerer can  then

respond with the preferred configuration/codec (G.711 and

DTMF events, say) in the answer m= line, along with a pair

of latent configurations that indicate (future) support for

G.729 and iLBC as well.

Your example "a=mcap:1 audio video text" is not what we

intended to define; the format is intended to permit one

MIME type (e.g., audio, video, or text), and multiple

subtypes belonging to that type.  From the draft:

a=mcap:<med-cap-num> <type> <subtype>
*[<subtype>]

A typical mcap might look like:

a=mcap:1 audio PCMU G729 iLBC

which defines three media capabilities, audio/PCMU, audio/G729

and audio/iLBC, numbered respectively as 1, 2, and 3.

2. The bcap attribute is intended to solve the problem

discussed in section 3.10 of Flemming's SDPCapNeg

draft, in the sense that a different maximum bandwidth

can be specified for each configuration proposed within

a media stream.  We haven't proposed a means to

negotiate an overall session bandwidth limit.

Does this answer your questions?

-Bob

-------------------------------------------------------------

Bob Gilman    [email-masked] 303 898 9780

贺广武 wrote:

<>Hi,Reading the draft (draft-ietf-mmusic-sdp-media-capabilities-02.txt),  I have the following question:

1) I don’t understand the a=mcap extension intent? Because media types and media subtypes
can provide by m= line, I guess intent of this extension is only compress SDP packet? Additional, I have no ideal about “a=mcap:1 audio image text” is correct or wrong.

2) The bandwidth
negotiation(a=bcap) can not solve issue in 3.10("draft-ietf-mmusic-sdp-capability-negotiation-08.txt").

Regards

Sammy

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

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