[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
answers inline
Cheers, Thomas
-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
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 forma t specifications
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.
[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
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.
[Thomas] Forget about everything but mcp 1 and 2. The problem is GSM specific, where a mcp 2 applies both for sending and receiving because the modes 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, except when interworking to GSM is involved.
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.
[Thomas] I was not suggesting a symmetric negotiation either:
My idea is: the offerer expresses what he wants to receive, and is also capable of sending(e.g. mcp 2 for GSM). If the answerer is capable to support this value for sending and receiving, it shall apply this value and otherwise 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: the 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 therefore confident that this leads to reasonable results in all these cases.
I hope this clarify the issues.
Cheers
Magnus
Belling Thomas wrote:
> 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
>
--
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