Subject: RE: [MMUSIC] video media control draft

From: "Even, Roni" <[email-masked]>
Date: Thu, 25 Jul 2002 09:59:35 +0300

> -----Original Message-----
> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, July 24, 2002 11:46 PM
> To: Even, Roni
> Cc: 'Joerg Ott'; Orit Levin; [email-masked]
> Subject: Re: [MMUSIC] video media control draft 
> 
> 
> --> "Even, Roni" writes:
> >Joerg,
> >
> >The freeze tells the decoder to continue to decode but to 
> not present until
> >the freeze is released. The release is caused by asking from 
> the encoder a
> >new full frame, so maybe this is the state change since it 
> releases the
> >decoder from the released state.
> >The reasons for the freeze.
> >1. A mixer can just switch the video without handling of the 
> RTP format, so
> >the mixer is not looking for the new picture in the RTP 
> payload and may
> >start sending from the new source before the full picture. 
> This will cause
> >the decoder to use delta pictures on a previous source information.
> 
> In this case, the mixer is broken. It should change the SSRC on the
> outgoing packets (or change the CSRC, depending if it is 
> implemented as an
> RTP translator or mixer) which will inform the decoder that a 
> new source is
> active, and prevent it using the delta pictures on data from 
> a previous
> source.
The RTP mixer may be broken but not the MCU. H.225 states that

RTP translators and mixers are not elements of the H.323 system, and any
information about them in Annexes A and B shall be regarded as informative.
Note that both gateways and MCUs have some aspects of both mixers and
translators, and the information in Annexes A and B may be helpful in the
implementation of gateways and MCUs. However, MCUs are not mixers, and
mixers are not MCUs. Note that gateways, for example, on a packet-based
network-to-packet-based network call via the gateway may act as translators.

We have to interoperate with H.323 based systems even through signalling GW
who do not look at RTCP/RTP information
> 
> >2. A mixer that looks at the information and start to send 
> the new source
> >information only after detecting a full picture may still 
> want to use freeze
> >in order to let the decoder know that a source switch has 
> occurred, this is
> >important if the mixer do not change the RTP sequence 
> numbers in order to
> >keep the sequence numbers from the source. The decoder may 
> think that he
> >lost packets due to jump in sequence number if he does not 
> know that a
> >switch has occurred.
> 
> The source switch should always be accompanied by a change in 
> either SSRC
> or CSRC, so the receiver will always know it has occured. This is the
> reason RTP mixers include CSRC information, and why RTP translators
> preserve SSRC information.

Again like before, more about using CSRC H.225 says

CSRC Count (CC): Use of the CSRC count in this Recommendation is optional.
When not in use, the value of CC shall be zero (0). The CSRC may be used by
MCUs to provide information on contributors to the audio sum when
distributed audio processing is occurring. Note that there are no
capabilities associated with the ability to understand the CSRC count so the
MCU/MC has no way of knowing whether and how the terminal in the conference
makes use of the information.

> 
> >3. This is a more advanced one. If we are doing continuous 
> presence based on
> >taking 4 QCIF images from different source and building a 
> composite CIF
> >picture, using freeze gives us an option to let the decoder 
> start decoding
> >after all 4 pictures are available when building the initial 
> picture, the
> >decoder will get the other full pictures and since he 
> continues to decode
> >then when the last full QCIF is available, the mixer will 
> release the freeze
> >and the display will be OK. The same goes for changing one 
> of the QCIF
> >sources during the conference.
> 
> Again, since the pictures will be identified by CSRC in the mixed RTP
> packet, the decoder can perform all these functions without 
> the use of 
> freeze requests.

See above
> 
> >As for your design comment, I do not think that we have a 
> design problem in
> >H.323. In H.320 the signalling and media are synchronized 
> like in IP. They
> >run in the same pipe but may have different latencies due to 
> fixed channels
> >BW, furthermore the fast update and streams are in reverse 
> directions. Also
> >for fast update the issue is not to have it synchronized 
> with the switch on
> >the mixer but to have it delivered to the encoder so it will 
> happen sometime
> >after the switch and free the receiver from the freeze state 
> so it will
> >start presenting.
> >
> >As for reliability we are OK with H.245 reliability and I 
> assume will try to
> >use TCP for videoconferencing due to all reasons mentioned in the SIP
> >session.
> >
> >AS for no go in SDP, I do not understand how you reached a 
> consensus, I
> >think that we are still arguing the issue and will keep our 
> draft alive.
> >
> >Again, I can give you a rough consensus from the video 
> conferencing people
> >that RTCP is not a solution for us and since the requirement 
> is coming from
> >people that are doing video conferencing and have the 
> knowledge you cannot
> >come and say that you should have the solution on RTCP even 
> if it does not
> >work. I think that the AVT guys did not agree on a must 
> anyhow since RTCP is
> >for indication and not for commands. 
> 
> I cannot agree on MUST if the command is passed by the 
> signalling channel
> either: an encoder running over IP has to be aware of 
> congestion control.
> 
> Colin
> 

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Colin Perkins <[email-masked]>
Date: Thu, 25 Jul 2002 15:44:00 -0400

My point was that RTP has the facilities needed to handle freeze. It may 
be appropriate to change implementations to use those facilities, rather 
than defining a new mechanism, and changing implementations to use that.

Colin