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

From: Belling Thomas <[email-masked]>
Date: Wed, 28 Apr 2004 14:46:23 +0200

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   [email-masked]

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]] 
Sent: Tuesday, April 06, 2004 10:43 PM
To: Belling Thomas
Cc: [email-masked]
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: [email-masked]

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

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 28 Apr 2004 15:03:34 +0200

Hi Thomas,

I am not agreeing that it will lead to a frequent call failure. If the 
receiver declare what it is capable of receiving, and the sender can 
send any way that fulfils the receivers requirements. In the case of a 
GSM to IP call it looks like this:

GSM GW: Offer for receiving:
mcp=2

IP Terminals Answer:
mcp not present.

Thus in this scenario the GSM GW has put a requirement on the IP 
terminal sending to only change modes every two frames.

The GSM GW can send any mode change period as the IP terminal does not 
care. Thus no problem arise.

As I understand it, call time problems will only occur when the two 
system has sending limitations which is incapable to fulfil the 
receivers wishes. But there are few cases where this will be totally 
impossible to make it work. For example
A: mcp=2
B: mcp=3

Then when A sends to B and wishes to change period it will need to keep 
track of which frame in the super period of 6 frames it can change on, 
where it fulfils both changes periods.

Specifying a symmetric negotiation instead of declaration will not help 
the situation at all, it will only force the parties to reject a call 
when it doesn't match. If one uses declaration style each of the 
end-point can make a decision between the cases.

1. Determine that it will work fine and match the super period between 
both end systems limitations.
2. Try to fulfil them after best possibilities and if it fails let the 
receiver discard the frames.
3. Try to restrain it self from switching.
4. Determine that the setup will not work, and then reject the call.

I hope this clarify the issues.

Cheers

Magnus

-- 

Magnus Westerlund