[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications
Hi Magnus,
a rather late response to your email, but a draft standard replacing RFC3267 will probably not be available tomorrow anyway, with no internet draft existing up to now.
I want to suggest some improvments to yout text, and start with an explanation:
The main issue that needs to be clarified in my understanding is the difference between what Jonathan Rosenberg called *negotiated* or *declarative" attributes.
In RFC 3264, Section 6.1, I read:
"
The interpretation of fmtp parameters in an offer depends on the
parameters. In many cases, those parameters describe specific
configurations of the media format, and should therefore be processed
as the media format value itself would be. This means that the same
fmtp parameters with the same values MUST be present in the answer if
the media format they describe is present in the answer. Other fmtp
parameters are more like parameters, for which it is perfectly
acceptable for each agent to use different values. In that case, the
answer MAY contain fmtp parameters, and those MAY have the same
values as those in the offer, or they MAY be different. SDP
extensions that define new parameters SHOULD specify the proper
interpretation in offer/answer.
"
As a general remark, it is beneficial to remember the recommendation of RFC 3264 to define an SDP offer/answer handling for MIME parameters when defining new RTP payload types. I am not aware of examples where this has been followed up to now.
For the AMR MIME parameters, I see three classes:
1. Parameters defining the transport format:
(octet-align, crc, robust-sorting, interleaving, and channels)
The sender and receiver of an RTP stream need to agree on the transport format to be used.
For a bidirectional media stream, one could try to allow different transport formats for the RTP IP flows in different directions. However, I do not see a real requirement for such semantics. It is highly probable that a host supports the same transport format both for sending and receiving. And it seems to be difficult to find SDP offer-answer semantics that would allow expressing different transport formats for both directions, while at the same time satisfying the requirement that both an RTP sender an an RTP receiver needs to express a supported transport format.
I therefore suggest that an SDP answerer MUST include these parameters unmodified compared to the SDP offer.
Between the lines of your proposed text, I read that you have the same understanding.
2. packetisation time (ptime,maxptime)
In RFC 3264, Section 6.1, the handling is defined for "ptime", and "maxptime" should follow the same principle. For a bidirectional media stream, it is allowed to use different packetisation times for IP flows in opposite directions:
"
The answerer MAY include a non-zero ptime attribute for any media
stream; this indicates the packetization interval that the answerer
would like to receive. There is no requirement that the
packetization interval be the same in each direction for a particular
stream.
...
Once the answerer has sent the answer, it MUST be prepared to receive
media for any recvonly streams described by that answer. ...
When sending media, it SHOULD use a packetization
interval equal to the value of the ptime attribute in the offer, if
any was present.
"
3. Codec configuration Parameters ("mode-set", "mode-change-period", and
"mode-change-neighbor"). Demanding that these parameters are equal in SDP offer and answer would lead to a high call failure rate, as there is a fair chance that hosts do not support all conceivable combinations of these parameters. For instance, an SDP answerer might support only a subset of the modes in the mode set of the SDP offer. Furthermore, an AMR client might not support a mode-change-period other than 1 or a restriction to mode-change-neighbor when sending, but be capable to handle received AMR with other settings. The interoberability to the usage in 3GPP should also be considered when defining a proper handling of these parameters. In particular, the parameters mode-change-period", and "mode-change-neighbor" were probably introduced with this as only purpose. In the interworking scenarios with the Cs domain of 3GPP, the network is able to insert transcoders, if a mismatch of the parameters between SDP offer and answer occurs, and therefore priority should be given to call completion. I suggest defining suitable negotiation rules for all of these parameters.
The tricky issue will be backward compatibility to RFC3264, where the rules were open. My hope for the "mode-set" parameter is that the suggested rules were intuitively followed in implementations. My hope for the "mode-change-period" and "mode-change-neighbor" parameters is that they were not used up to now.
As a minor issue,I noticed that RFC 3264 states in clause 4.5:
"To achieve basic interoperability an implementation SHOULD at least implement both
bandwidth-efficient and octet-aligned mode for single channel."
You suggest "the offerer is RECOMMENDED to also offer an payload type containing only the
octet-align configuration with a single channel"
The restriction to octet alligned seems a bit arbitrary, and I would therefore suggest recommending that either a simple octet-alligned or bandwidth-efficient configuration should also be offered.
I would therefore like to suggest the following improvments to your text (marked as >>> <<<) :
8.3.1 Offer-Answer Model Considerations
To achieve good interoperability with the AMR or the AMR-WB RTP payload
in an Offer-Answer usage in SDP >>>[RFC3264]<<< the following >>>applies<<<:
- Each combination of the RTP payload >>>transport format<<< configuration parameters
(octet-align, crc, robust-sorting, interleaving, and channels) is unique
in its bit-pattern and not compatible with any other combination. Due to
the application dependent nature of any configuration and they being
optionally to implement, care must be taken. When creating an offer in
an application desiring to use the more advance features (crc,
robust-sorting, interleaving, or more than one channel), the offerer is
RECOMMENDED to also offer an payload type containing only the
octet-align >>> or bandwidth efficient <<< configuration with a single channel. If multiple
configurations are of interest to the application they may all be
offered, however care should be taken to not offer too many payload types.
>>> An SDP answerer MUST include the received parameters "octet-align", "crc",
"robust-sorting", "interleaving" and "channels" for a media format in the SDP offer unmodified in the SDP answer, unless it removes the media format. The SDP offerer and answerer MUST encode AMR or WB-AMR packets for this media format as described by these parameters.<<<
>>>
- If an SDP offer containing a "mode-set" parameter for a media format is received, the SDP answerer MUST include the "mode-set" parameter for this media format in the SDP answer, unless it removes the media format. The SDP answerer MUST remove modes it does not support from the mode set, and MUST NOT add any modes. If no mode set for a media format was contained in the SDP offer, but the SDP answerer does not support all modes, the SDP answerer MUST include a "mode-set" parameter without the unsupported modes for the media format in the SDP answer, unless it removes the media format. The SDP answerer MAY also remove modes it does support but not want to use. The SDP offerer and answerer MUST only use the modes in the SDP answer to encode AMR or WB-AMR and to request mode changes. <<<
- The parameters "mode-change-period" and "mode-change-neighbor" SHOULD only be used when really needed due to gateway scenarios.
>>>In an SDP offer, the parameters express the configuration the offerer will use to encode AMR or WB-AMR of a media format, and also the configuration it whishes for received AMR or WB-AMR. If an SDP offer for a media format is received, and the SDP answerer is not capable to decode AMR or WB-AMR with the "mode-change-period" and "mode-change-neighbor" configuration implied in the offer for this media format, the SDP answerer MUST reject this media format. Otherwise, if an SDP offer for a media format is received, and the SDP answerer is not capable to encode AMR or WB-AMR with the "mode-change-period" and "mode-change-neighbor" configuration implied in the offer, the SDP answer MUST include a "mode-change-period" and "mode-change-neighbor" configuration it is capable to encode in the SDP answer for this media format, unless it removes the media format. Otherwise, if an SDP answer containing the parameter "mode-change-period" or "mode-change-neighbor" for a media format is received, the SDP answerer SHOULD include the parameter unmodified in the SDP answer. The SDP answerer MUST encode AMR or WB-AMR as expressed by the "mode-change-period" and "mode-change-neighbor" configuration in the SDP answer. If the SDP offerer receives an SDP answer with a "mode-change-period" and "mode-change-neighbor" configuration it is not able to decode, the SDP offerer MUST reject this media format in a new SDP offer.<<< (For backward compatibility, perhaps some "MUST"s need to become "SHOULD"s, depending what has alredy been implemented)
- The parameters "maxptime" and "ptime" >>will<< in most cases not >>a<<ffect
the interoperability, however the setting of the parameters can >>a<<ffect
the performance of the application. >>> The SDP offer-answer handling of the "ptime" parameter is described in [RFC3264]. The "maxptime" parameter MUST be handled in the same way. <<<
Best regards, Thomas
----------------------------------
Dr. Thomas Belling
Siemens AG
Sankt-Martin-Str. 76
D-81541 München Germany
ICM N PG SP ST N1
MCH M 34 307
Tel +49 89 636 75207
Fax +49 89 636 75577
Mobile +49 172 2974678
Email Thomas.Belling@siemens.com
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: Tuesday, January 27, 2004 11:57 AM
To: Belling Thomas
Cc: avt@ietf.org
Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications
Hi Thomas,
Belling Thomas wrote:
>Dear Magnus and Collin,
>
>thank you for this initiative.
>We also had some internal dicussions about the AMR RTP payload format,
>RFC 3267, with that respect.
>Is there any intention to remmedy this, e.g. by updating the RFC or
>writing an additional one?
>
>Best regards, Thomas
>
>
>
We authors are planning on updating RFC 3267 to go draft standard, then
we can address this.. We will also fix some small issues with the text,
however the current errata for RFC 3267 is very short.
I have written an initial proposal for this text which I include below,
however please remember that it is a first version. Comments are welcome.
Cheers
Magnus
---------- Text Proposal for new chapter 8.3 -------------
8.3. Mapping MIME Parameters into SDP
The information carried in the MIME media type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[11], which is commonly used to describe RTP sessions. When SDP is
used to specify sessions employing the AMR or AMR-WB codec, the
mapping is as follows:
- The MIME type ("audio") goes in SDP "m=" as the media name.
- The MIME subtype (payload format name) goes in SDP "a=rtpmap"
as the encoding name. The RTP clock rate in "a=rtpmap" MUST be
8000 for AMR and 16000 for AMR-WB, and the encoding parameters
(number of channels) MUST either be explicitly set to N or
omitted, implying a default value of 1. The values of N that
are allowed is specified in Section 4.1 in [24].
- The parameters "ptime" and "maxptime" go in the SDP "a=ptime"
and "a=maxptime" attributes, respectively.
- Any remaining parameters go in the SDP "a=fmtp" attribute by
copying them directly from the MIME media type string as a
semicolon separated list of parameter=value pairs.
8.3.1 Offer-Answer Model Considerations
To achieve good interoperability with the AMR or the AMR-WB RTP payload
in an Offer-Answer usage in SDP the following considerations should be made:
- Each combination of the RTP payload configuration parameters
(octet-align, crc, robust-sorting, interleaving, and channels) is unique
in its bit-pattern and not compatible with any other combination. Due to
the application dependent nature of any configuration and they being
optionally to implement, care must be taken. When creating an offer in
an application desiring to use the more advance features (crc,
robust-sorting, interleaving, or more than one channel), the offerer is
RECOMMENDED to also offer an payload type containing only the
octet-align configuration with a single channel. If multiple
configurations are of interest to the application they may all be
offered, however care should be taken to not offer too many payload types.
- The parameters "mode-set", "mode-change-period", and
"mode-change-neighbor" SHOULD only be used when really needed due to
gateway scenarios, however their nature are such that they must either
be supported or no interoperability exist.
- The parameters "maxptime" and "ptime" should in most cases not effect
the interoperability, however the setting of the parameters can effect
the performance of the application.
8.3.2 Examples
Some example SDP session descriptions utilizing AMR and AMR-WB
encodings follow. In these examples, long a=fmtp lines are folded to
meet the column width constraints of this document; the backslash
("\") at the end of a line and the carriage return that follows it
should be ignored.
Example of usage of AMR in a possible GSM gateway scenario:
m=audio 49120 RTP/AVP 97
a=rtpmap:97 AMR/8000/1
a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \
mode-change-neighbor=1
a=maxptime:20
Example of usage of AMR-WB in a possible VoIP scenario where UEP may
be used (99) and a fallback declaration (98):
m=audio 49120 RTP/AVP 99 98
a=rtpmap:99 AMR-WB/16000
a=fmtp:99 octet-align=1; crc=1
a=rtpmap:98 AMR-WB/16000
a=fmtp:98 octet-align=1
Example of usage of AMR-WB in a possible streaming scenario (two
channel stereo):
m=audio 49120 RTP/AVP 99 100
a=rtpmap:99 AMR-WB/16000/2
a=fmtp:99 interleaving=30
a=maxptime:100
Note that the payload format (encoding) names are commonly shown in
upper case. MIME subtypes are commonly shown in lower case. These
names are case-insensitive in both places. Similarly, parameter
names are case-insensitive both in MIME types and in the default
mapping to the SDP a=fmtp attribute.
--
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt