Dear Magnus,
you suggested interpretation that the mode-change-period (mcp) is only related to the expectations of the receiver may lead to frequent call failures in interworking situations:
consider the scenario of a GSM to IP call.
Here, the GSM side is only able to support mcp 2 both for sending and receiving.
Consider a simple IP AMR terminal on the other side that is only capable of sending with mcp 1 - I expect this to be the rule rather than the exception.
It would be desirable to transcode in such a situation in the IP to GSM interworking node.
The interworking node would receive a GSM "offer" with AMR-FR. It has the choice always to insert a transcoder in this situation (not knowing if the peer supports sending with mcp 2) and sending an SDP offer with mcp 1, not inserting a transcoder but sending an SDP offer with mcp 1 (accepting negative impacts on speech quality during mode changes), or not inserting a transcoder and sending an SDP offer with mcp 2 (the "natural" choice to interwork the parameter rarther than transcoding). With lhe last choice the call would fail, because the IP terminal is not able to send with mcp 2.
The rules I suggested earlier may look a bit unusual, but they are able to cover this situation in a satisfying manner.
Cheers, 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, April 06, 2004 10:43 PM
To: Belling Thomas
Cc: avt@ietf.org
Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications
Hi Thomas,
I am sorry for the late reply. I will comment the first part of the
mail. The actual proposal and your suggestions will be considered,
however I am pretty certain I will have to rewrite this proposal even
further. However the input is really valuable.
But lets start with your general comments.
Belling Thomas wrote:
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.
Yes, one needs to separate the negotiation style and the declarative
style. They are in some cases quite different, as for example the H.264
offer answer section has shown me.
Further I think that that the above consideration that you quote are
interesting, and it is definitely correct that the interpretation should
be defined. However I think that it is a bit unclear when a parameter
falls in the first category and MUST be symmetrically used. It is mostly
a result of the lacking capabilities of the offer answer model. But lets
look at the cases you propose.
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.
Yes, it is probably the simplest way for a answer to know that an
offerer is guaranteed to support also sending of a configuration. If one
had known that the offerer does support sending a configuration then the
answerer could modify the response and have non symmetrical
configurations. However that would require an inclusion of capability
parameters, and would still have the issues that the offerer does not
know the capabilities of the answerer.
Further I guess that there are not a serious problem of using symmetric
transport configurations. Also the answerer could add further PTs with
other configurations if it desires to receive AMR in further
configurations than the offerer provides.
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.
"
Yes, I don't see a reason for changing this behaviour.
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
giv!
en 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.
These parameters are a bit complicated. As I see it the mode-set is
basically declared parameter from each receiver. It SHOULD only be
specified if one has special requirements. This would result in that one
will be capable of establishing a session unless both end-points are
gateways to networks with restrictions and does have completely
different sets. Otherwise each sender will follow the receivers request.
Thus everything should work, as one will not send something that it
locally impossible to send. If a receiver of an offer does not support
transmission of any of the modes, he will need to remove the media in
the response. If the offerer receives an answer with a mode restriction
that it doesn't support, it must reject the whole session if no other
established PT works.
In the case of mode-change-period, and mode-change-neighbor I think the
only reasonable rule it to do the same as for mode-set. This put the
expectation on the sender to follow this if at all possible. Which again
is supposed to be supported unless we have the CS->GW->RTP->GW->CS case.
I don't think there will be a major problem with backwards
compatibility. However I and the other authors should try to get the
updated AMR payload spec out as soon as possible to give the proposed
solution.
Feedback on the backwards compatibility issue is appropriate.
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.
It was a typo to not include both basic modes. However I still think
that octet-align mode is the most simple to implement, however there are
clearly application cases where bandwidth efficient is most reasonable
to offer.
Cheers
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