Re: [AVT] The need for Offer/Answer sections in RTP payload forma t specifications

[Magnus Westerlund <[e-mail]>]

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 [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]



_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt