Subject: [AVT] Negotiation of redundancy level for RFC 2198 and RFC 4102

From: Gunnar Hellström <[email-masked]>
Date: Wed, 16 Jan 2008 20:41:10 +0100

Colin,
When RFC 4102 - RFC 4103 were drafts, we had discussions about the exact
meaning of the sdp declarations for redundancy according to RFC 2198 and RFC
4102.
It was then agreed to expect a possible revision of RFC 2198 to explain the
exact meaning of an sdp negotiation of the redundancy declaration.
I am getting questions about the interpretation of the fmtp parameters and
want to reach a common view about it.
 
The parameters are like this:
a=rtpmap 100 red/1000
a=fmtp 100 98/98/98
 
The usual response I give is that there is no real negotiation defined. The
fmtp parameters indicate the intended redundancy pattern to be TRANSMITTED.
The example would tell that I intend to transmit payload type 98 as the
primary and two redundant generations. 
 
I realize now that this must be modified to mean that for sendrcv and
sendonly modes the parameters mean what I intend to transmit, while for
recvonly it needs to indicate the codecs and generations I am prepared to
receive.
 
The declaration for recvonly leads to a kind of negotiation. If I indicate
what I am prepared to receive, then I would expect the transmitting part to
follow that declaration or possibly send fewer generations but according to
the declared codecs.
 
I have not noticed any efforts to revise RFC 2198.
 
Questions: 
 
Is there any revision of RFC 2198 or its sdp parameter meaning on its way?
 
Is my interpretation of the redundancy sdp parameters agreeable?
 
Gunnar
 
-------------------------------------------------------------------
Gunnar Hellström
Omnitor
 
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Colin Perkins <[email-masked]>
Date: Sat, 19 Jan 2008 11:52:46 +0000

Gunnar,

On 16 Jan 2008, at 19:41, Gunnar Hellström wrote:
> When RFC 4102 - RFC 4103 were drafts, we had discussions about the  
> exact meaning of the sdp declarations for redundancy according to  
> RFC 2198 and RFC 4102.
> It was then agreed to expect a possible revision of RFC 2198 to  
> explain the exact meaning of an sdp negotiation of the redundancy  
> declaration.
> I am getting questions about the interpretation of the fmtp  
> parameters and want to reach a common view about it.
>
> The usual response I give is that there is no real negotiation  
> defined. The fmtp parameters indicate the intended redundancy  
> pattern to be TRANSMITTED.  The example would tell that I intend to  
> transmit payload type 98 as the primary and two redundant generations.
>
> I realize now that this must be modified to mean that for sendrcv  
> and sendonly modes the parameters mean what I intend to transmit,  
> while for recvonly it needs to indicate the codecs and generations  
> I am prepared to receive.
>
> The declaration for recvonly leads to a kind of negotiation. If I  
> indicate what I am prepared to receive, then I would expect the  
> transmitting part to follow that declaration or possibly send fewer  
> generations but according to the declared codecs.

I don't think that's appropriate. The sender should look at the RTCP  
reception reports being returned, and use an appropriate amount of  
redundancy to conceal the observed loss. The receiver should be able  
to parse packets containing any amount of redundancy, using it for  
repair as appropriate (and discarding any excess generations of  
redundancy). RFC 2198 is clear that a receiver doesn't need to know  
how many generations of redundancy will be used in order to decode  
the received stream.

> Is there any revision of RFC 2198 or its sdp parameter meaning on  

I have no plans to revise RFC 2198.

-- 
Colin Perkins
http://csperkins.org/

---

From: Gunnar Hellström <[email-masked]>
Date: Sat, 19 Jan 2008 16:29:14 +0100

Colin,
Thanks, I think your current conclusion sounds feasible.

However, in RFC 4102 we entered after discussion in avt: "The level of
redundancy is shown by the number of elements in the payload type list."

But it does not say if that is what it intends to send initially, or
recommends the other party to send. 

RFC 3264 Offer/answer model says
"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."

The question is now: What kind of parameters are the fmtp parameters for RFC
2198/RFC 4102?

RFC 2198 says:
"However
   to send a redundant stream, the sender needs to know which codecs are
   recommended for the primary and secondary (and tertiary, etc)
   encodings.  This information is specific to the redundancy format,
   and is specified using an additional attribute "fmtp" which conveys
   format-specific information.  A session directory does not parse the
   values specified in an fmtp attribute but merely hands it to the
   media tool unchanged.  For redundancy, we define the format
   parameters to be a slash "/" separated list of RTP payload types.

   Thus a complete example is:

       m=audio 12345 RTP/AVP 121 0 5
       a=rtpmap:121 red/8000/1
       a=fmtp:121 0/5

   This specifies that the default format for senders is redundancy with
   PCM as the primary encoding and DVI as the secondary encoding.
   Encodings cannot be specified in the fmtp attribute unless they are
   also specified as valid encodings on the media ("m=") line."

Since this excerpt talks about that "the sender needs to know", I get the
imression that the example sdp shows a received sdp, and it talks about how
the rtp transmission will be composed from the part who received the sdp. 
Right?

Local capabilities at the sdp receiving side may then reduce the list of
available codecs 

Shall we assume the same rule for the initial number of redundancy levels?
If the offering Alice says 
a=fmtp:100 98/98/98 
it suggests that the receiver of this sdp should transmit one original and
two redundant levels of payload 98, redundancy packetized as rtp payload
100.
If the receiver, Bob, of that sdp can compose one level, but cannot compose
two levels, Bob should respond:
a=fmtp:100 98/98
and Bob shall then only send one original and one redundant level initially.
Alice however gets the confirmation that Bob can handle PT 98 as primary and
PT 98 as redundant. She can decide to send one original and one redundant
generation, or one original and two redundant. And then she may vary the
number of generations during the session. 

Is this the right assumption, and does it need to be documented somewhere?

Gunnar

-------------------------------------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
Tel: +46708204288
www.omnitor.se

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]] 
Sent: Saturday, January 19, 2008 12:53 PM
To: Gunnar Hellström
Cc: avt IETF
Subject: Re: [AVT] Negotiation of redundancy level for RFC 2198 and RFC 4102

Gunnar,

On 16 Jan 2008, at 19:41, Gunnar Hellström wrote:
> exact meaning of the sdp declarations for redundancy according to RFC 
> 2198 and RFC 4102.
> I am getting questions about the interpretation of the fmtp parameters 
> and want to reach a common view about it.
>
> defined. The fmtp parameters indicate the intended redundancy pattern 
> to be TRANSMITTED.  The example would tell that I intend to transmit 
> payload type 98 as the primary and two redundant generations.
>
> sendonly modes the parameters mean what I intend to transmit, while 
> for recvonly it needs to indicate the codecs and generations I am 
> prepared to receive.
>

I don't think that's appropriate. The sender should look at the RTCP
reception reports being returned, and use an appropriate amount of
redundancy to conceal the observed loss. The receiver should be able to
parse packets containing any amount of redundancy, using it for repair as
appropriate (and discarding any excess generations of redundancy). RFC 2198
is clear that a receiver doesn't need to know how many generations of
redundancy will be used in order to decode the received stream.

--
Colin Perkins
http://csperkins.org/

__________ NOD32 2805 (20080118) Information __________

Detta meddelande är genomsökt av NOD32 Antivirus.
http://www.nod32.com

---

From: Bob Gilman <[email-masked]>
Date: Sun, 20 Jan 2008 10:53:50 -0700

Gunnar, Colin-
For a number of reasons, it seems better to interpret the  payload type
values in an m= line (and correspoinding fmtp lines) as the payload types
the SDP-sender expects to receive if the session is receive-only or send-
receive, and as a suggestion if the session is send-only.  The SDP response
should indicate the payload types and formats the responder expects.  From
RFC 3264 (the offer/answer model, Section 5.1 Unicast Streams :
<>  "The list of media formats for each media stream conveys two pieces of
   information, namely the set of formats (codecs and any parameters
   associated with the codec, in the case of RTP) that the offerer is
   capable of sending and/or receiving (depending on the direction
   attributes), and, in the case of RTP, the RTP payload type numbers
   used to identify those formats.  If multiple formats are listed, it
   means that the offerer is capable of making use of any of those
   formats during the session.  In other words, the answerer MAY change
   formats in the middle of the session, making use of any of the
   formats listed, without sending a new offer.  For a sendonly stream,
   the offer SHOULD indicate those formats the offerer is willing to
   send for this stream.  For a recvonly stream, the offer SHOULD
   indicate those formats the offerer is willing to receive for this
   stream.  For a sendrecv stream, the offer SHOULD indicate those
   codecs that the offerer is willing to send and receive with.

   For recvonly RTP streams, the payload type numbers indicate the value
   of the payload type field in RTP packets the offerer is expecting to
   receive for that codec.  For sendonly RTP streams, the payload type
   numbers indicate the value of the payload type field in RTP packets
   the offerer is planning to send for that codec.  For sendrecv RTP
   streams, the payload type numbers indicate the value of the payload
   type field the offerer expects to receive, and would prefer to send.
   However, for sendonly and sendrecv streams, the answer might indicate
   different payload type numbers for the same codecs, in which case,
   the offerer MUST send with the payload type numbers from the answer."
Specifying the receive payload type is necessary<> for receiving early media
with dynamic payload types.  It's also important for media stream
reconfigurations in Offer/Answer (see section 8.3.2 of RFC 3264).
The  multicast stream is treated differently: the parameters are set by
the offer in O/A it seems - certainly a convenience for the multicaster.

With respect to the level of redundancy, a similar rule makes sense:
the SDP describes the level (and content) its sender is willing/able
to receive, but the media sender is able to send a lower level of
redundancy and/or specify receipt of a lower level of redundancy.  In
any case, the receiver of the media will be able to recognize the content.
If, in the example below, Alice offered
a=fmtp:100 98/98/98
and Bob answered with
a=fmtp:100 98/98
then I'd suggest that should mean:
1. Alice should not send packets with two levels of reduncancy to Bob.
2. Bob could send packets with zero, one or two levels of redundancy to
   Alice (but odds are Bob will send one level of redundancy.)
Does this make sense?
-Bob-------------------------------------------------------------

Bob Gilman         [email-masked]        303 898 9780

---

From: "Frank Shearar" <[email-masked]>
Date: Sun, 20 Jan 2008 19:52:09 +0200

Colin wrote:

> > The receiver should be able

An implementation of RFC 4103 should, from my reading of it (and of RFC
2198), support arbitrary and changing amounts of redundancy.

Gunnar, are you just talking about signalling what number of generations you
want to use? I don't think it's necessary: what should happen, surely, is
that the parts of the UAs monitoring RTCP should notice increasing levels of
packet loss (or whatever) and adjust the amount of redundancy accordingly?
Then when the packet loss rate returns to normal, the UAs can stop or reduce
the amount of redundancy required.

frank

frank

RFC 2198 says:
"However

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Saturday, January 19, 2008 12:53 PM
To: Gunnar Hellström
Cc: avt IETF
Subject: Re: [AVT] Negotiation of redundancy level for RFC 2198 and RFC 4102

Gunnar,

--
Colin Perkins
http://csperkins.org/

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 21 Jan 2008 08:39:25 +0100

Frank,
Yes, this discussion is about how the declaration in fmtp of levels of
redundancy relates to what you send and expect in a session.

I agree with Colin's statement that:
> > redundancy).

In received packets you just chain through the received redundancy header
and pick up the data you need at the moment.

Once that is clear, the discussion gets a bit theoretical. The declarations
could just guide you to a good initial setting of your transmitted level.
And you rarely know the conditions end-to-end, so you are usually not in any
good position to give good guidance to the other party, and also not rely on
the guidance the other party gives you. 

In RFC 4103 for real-time text, it is said that the default is to transmit
the primary and two redundant generations. The overhead cost of always
sticking to this level is minor, a moment of increased packet loss may come
after a long period of good conditions, so you should never go below this
level anyway, and the need to increase over it should be extremely minimal.
With this level you can have 12% packet loss and still get good quality text
through.

Bob claims that the received fmtp in sdp should guide you to set your
redundancy level for transmission. I can see a reason to obey that for
increasing the level over what you initially intended, but not for
decreasing. I might know better the conditions on the connection that I sit
on, so I see a reason to transmit the higher level I decide and propose in
my transmitted fmtp. 
 
For RFC 4103 we can simply say: Declare and transmit original plus two
redundant. Expect any.

Gunnar 

-----Original Message-----
From: Frank Shearar [mailto:[email-masked]] 
Sent: Sunday, January 20, 2008 6:52 PM
To: Gunnar Hellström; 'Colin Perkins'
Cc: 'avt IETF'
Subject: Re: [AVT] Negotiation of redundancy level for RFC 2198 and RFC 4102

frank

frank

RFC 2198 says:
"However

Gunnar

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Saturday, January 19, 2008 12:53 PM
To: Gunnar Hellström
Cc: avt IETF
Subject: Re: [AVT] Negotiation of redundancy level for RFC 2198 and RFC 4102

Gunnar,

--
Colin Perkins
http://csperkins.org/

__________ NOD32 2807 (20080119) Information __________

---

From: "Frank Shearar" <[email-masked]>
Date: Mon, 21 Jan 2008 10:58:06 +0200

> the guidance the other party gives you.

Sure, SDP tells the other party about YOUR conditions.

> With this level you can have 12% packet loss and still get good quality
text

Basic insurance against packet loss, basically. I meant by my comment on
dropping the number of generations once the packet loss rate dropped that
one uses a number of generations appropriate to the current conditions,
really. In line with RFC 4103, then, a decent line (or a noisy line that's
just settled down) would fall back from using, say, 5 generations (this
number is just for illustrative purposes), back to just using the minimum
recommended two generations.

> For RFC 4103 we can simply say: Declare and transmit original plus two

Ah, OK. I was thinking that you'd meant you were declaring both what you
were sending and what you were expecting. This quote

> The declaration for recvonly leads to a kind of negotiation. If I indicate
what I am prepared to receive, then
> I would expect the transmitting part to follow that declaration or
possibly send fewer generations but according
> to the declared codecs.

made me think you were suggesting something like dropping packets that
didn't have the correct number of generations because they were somehow
ill-formed. I see that that's not what you meant.

frank