Message-ID: <FF8AC5030873D6118BCB0002A58EDA99052BDE1F@mchh2a7e.mchh.siemens.de>
From: Belling Thomas <thomas.belling@siemens.com>
To: "'Magnus Westerlund'" <magnus.westerlund@ericsson.com>
Cc: avt@ietf.org
Subject: RE: [AVT] The need for Offer/Answer sections in RTP payload forma
 t specifications
Date: Wed, 28 Apr 2004 16:12:36 +0200
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Transfer-Encoding: quoted-printable
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
Precedence: bulk
Content-Transfer-Encoding: quoted-printable

Hi Magnus

answers inline

Cheers, Thomas

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
Sent: Wednesday, April 28, 2004 3:04 PM
To: Belling Thomas
Cc: avt@ietf.org
Subject: Re: [AVT] The need for Offer/Answer sections in RTP payload form=
a t specifications


Hi Thomas,

I am not agreeing that it will lead to a frequent call failure. If the=20
receiver declare what it is capable of receiving, and the sender can=20
send any way that fulfils the receivers requirements. In the case of a=20
GSM to IP call it looks like this:

GSM GW: Offer for receiving:
mcp=3D2

IP Terminals Answer:
mcp not present.

Thus in this scenario the GSM GW has put a requirement on the IP=20
terminal sending to only change modes every two frames.

[Thomas] Exactly. My point is that I suspect that many IP terminals will =
not be capable to fulfill this requirement. A call failure would result.


The GSM GW can send any mode change period as the IP terminal does not=20
care. Thus no problem arise.

As I understand it, call time problems will only occur when the two=20
system has sending limitations which is incapable to fulfil the=20
receivers wishes. But there are few cases where this will be totally=20
impossible to make it work. For example
A: mcp=3D2
B: mcp=3D3

Then when A sends to B and wishes to change period it will need to keep=20
track of which frame in the super period of 6 frames it can change on,=20
where it fulfils both changes periods.


[Thomas] Forget about everything but mcp 1 and 2. The problem is GSM spec=
ific, where a mcp 2 applies both for sending and receiving because the mo=
des indicated with every frame at the radio interface refer to uplink and=
 downlink in an alternating manner. In am not are of any other scenarios =
where anything but mcp1 would be encountered for sending and receiving, e=
xcept when interworking to GSM is involved.


Specifying a symmetric negotiation instead of declaration will not help=20
the situation at all, it will only force the parties to reject a call=20
when it doesn't match. If one uses declaration style each of the=20
end-point can make a decision between the cases.

1. Determine that it will work fine and match the super period between=20
both end systems limitations.
2. Try to fulfil them after best possibilities and if it fails let the=20
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.


[Thomas] I was not suggesting a symmetric negotiation either:
My idea is: the offerer expresses what he wants to receive, and is also c=
apable of sending(e.g. mcp 2 for GSM). If the answerer is capable to supp=
ort this value for sending and receiving, it shall apply this value and o=
therwise reply with a mcp it is capable of supporting (e.g. mcp 1 for my =
simple IP terminal).
When receiving an answer with an other mcp than in the offer, the offerer=
 has the choice to transcode or to abort the call (e.g. in my scenario: t=
he interworking node transcodes in this situation)

This may be unusual, but I analysed all realistic interworking scenarios =
(GSM/UMTS -> IP, IP -> GSM/UMTS, GSM/UMTS -> IP -> GSM/UMTS) and am there=
fore confident that this leads to reasonable results in all these cases.


I hope this clarify the issues.

Cheers

Magnus

Belling Thomas wrote:

> Dear Magnus,
>=20
> you suggested interpretation that the mode-change-period (mcp) is only =
related to the expectations of the receiver may lead to frequent call fai=
lures in interworking situations:
>=20
> consider the scenario of a GSM to IP call.
> Here, the GSM side is only able to support mcp 2 both for sending and r=
eceiving.
> Consider a simple IP AMR terminal on the other side that is only capabl=
e of sending with mcp 1 - I expect this to be the rule rather than the ex=
ception.
> 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 t=
he 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 (accept=
ing negative impacts on speech quality during mode changes), or not inser=
ting a transcoder and sending an SDP offer with mcp 2 (the "natural" choi=
ce to interwork the parameter rarther than transcoding). With lhe last ch=
oice the call would fail, because the IP terminal is not able to send wit=
h mcp 2.
>=20
> The rules I suggested earlier may look a bit unusual, but they are able=
 to cover this situation in a satisfying manner.
>=20
> Cheers, Thomas
>=20
>=20
> ----------------------------------
> Dr. Thomas Belling
> Siemens AG          =20
> Sankt-Martin-Str. 76=20
> D-81541 M=FCnchen 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
>=20
>=20
>=20
>=20
> -----Original Message-----
> From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20
> 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 fo=
rma t specifications
>=20
>=20
> Hi Thomas,
>=20
> I am sorry for the late reply. I will comment the first part of the=20
> mail. The actual proposal and your suggestions will be considered,=20
> however I am pretty certain I will have to rewrite this proposal even=20
> further. However the input is really valuable.
>=20
> But lets start with your general comments.
>=20
> Belling Thomas wrote:
>=20
>=20
>>Hi Magnus,
>>
>>a rather late response to your email, but a draft standard replacing
>>RFC3267 will probably not be available tomorrow anyway, with no interne=
t
>>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 processe=
d
>>   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 i=
f
>>   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, th=
e
>>   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 whe=
n
>>defining new RTP payload types. I am not aware of examples where this
>>has been followed up to now.
>>
>=20
>=20
> Yes, one needs to separate the negotiation style and the declarative=20
> style. They are in some cases quite different, as for example the H.264=
=20
> offer answer section has shown me.
>=20
> Further I think that that the above consideration that you quote are=20
> interesting, and it is definitely correct that the interpretation shoul=
d=20
> be defined. However I think that it is a bit unclear when a parameter=20
> falls in the first category and MUST be symmetrically used. It is mostl=
y=20
> a result of the lacking capabilities of the offer answer model. But let=
s=20
> look at the cases you propose.
>=20
>=20
>>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 sendin=
g
>>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.
>=20
>=20
> Yes, it is probably the simplest way for a answer to know that an=20
> offerer is guaranteed to support also sending of a configuration. If on=
e=20
> had known that the offerer does support sending a configuration then th=
e=20
>   answerer could modify the response and have non symmetrical=20
> configurations. However that would require an inclusion of capability=20
> parameters, and would still have the issues that the offerer does not=20
> know the capabilities of the answerer.
>=20
> Further I guess that there are not a serious problem of using symmetric=
=20
> transport configurations. Also the answerer could add further PTs with=20
> other configurations if it desires to receive AMR in further=20
> configurations than the offerer provides.
>=20
>=20
>>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 particula=
r
>>   stream.
>>...
>>   Once the answerer has sent the answer, it MUST be prepared to receiv=
e
>>   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.
>>"
>>
>=20
>=20
> Yes, I don't see a reason for changing this behaviour.
>=20
>=20
>>3. Codec configuration Parameters ("mode-set", "mode-change-period", an=
d
>>"mode-change-neighbor").  Demanding that these parameters are equal in
>>SDP offer and answer would lead to a high call failure rate, as there i=
s
>>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.
>>
>=20
>=20
> These parameters are a bit complicated. As I see it the mode-set is=20
> basically declared parameter from each receiver. It SHOULD only be=20
> specified if one has special requirements. This would result in that on=
e=20
> will be capable of establishing a session unless both end-points are=20
> gateways to networks with restrictions and does have completely=20
> different sets. Otherwise each sender will follow the receivers request=
.=20
> Thus everything should work, as one will not send something that it=20
> locally impossible to send. If a receiver of an offer does not support=20
> transmission of any of the modes, he will need to remove the media in=20
> the response. If the offerer receives an answer with a mode restriction=
=20
> that it doesn't support, it must reject the whole session if no other=20
> established PT works.
>=20
> In the case of mode-change-period, and mode-change-neighbor I think the=
=20
> only reasonable rule it to do the same as for mode-set. This put the=20
> expectation on the sender to follow this if at all possible. Which agai=
n=20
> is supposed to be supported unless we have the CS->GW->RTP->GW->CS case.
>=20
> I don't think there will be a major problem with backwards=20
> compatibility. However I and the other authors should try to get the=20
> updated AMR payload spec out as soon as possible to give the proposed=20
> solution.
>=20
> Feedback on the backwards compatibility issue is appropriate.
>=20
>=20
>>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.
>>
>>
>=20
>=20
> It was a typo to not include both basic modes. However I still think=20
> that octet-align mode is the most simple to implement, however there ar=
e=20
> clearly application cases where bandwidth efficient is most reasonable=20
> to offer.
>=20
> Cheers
>=20
> Magnus Westerlund
>=20
> 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
>=20

--=20

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