Subject: RE: [MMUSIC] video media control draft

From: "MONFORT Patrick FTRD/DMI/ISS" <[email-masked]>
Date: Tue, 23 Jul 2002 10:01:18 +0200

All,

We am working on UA with Video (www.econf-communication.com), we totally
agree with the requirements as expressed by the "video media control
draft". 

We already have support for H323 protocol and can't actually release our
product because of the lack of support for video control in SIP/SDP (we
do not want to loose some existing features available for the end-user).
We are very concerned by  the quality of the conference once it has been
initiated.

There is a lack of expressivness in the actual SDP, a UA can not specify
the video format etc...  There is also a lack of control of media in
SIP/SDP(offer/answer model).

Regarding video, these two points have been discussed in the draft
called "draft-koskelainen-sdp263-02.txt". (found in the input queue for
SDPng).

We would like to revive this draft. It effectively allows a UA to
express video capability in a good way.

Regarding the control, RFC 2032 (which describes RTCP packet for
IntraRequest) can't be deployed. The reason is that these RTCP packets
are not sent to the 'standard' RTCP Port.

Here are the text taken from RFC 2032, that explains this issue (section
5.1):

"
The H.261-specific control packets differ from normal RTCP packets in
   that they are not transmitted to the normal RTCP destination
   transport address for the RTP session (which is often a multicast
   address).  Instead, these control packets are sent directly via
   unicast from the decoder to the coder.  The destination port for
   these control packets is the same port that the coder uses as a
   source port for transmitting RTP (data) packets.  Therefore, these
   packets may be considered "reverse" control packets.

   As a consequence, these control packets may only be used when no RTP
   mixers or translators intervene in the path from the coder to the
   decoder.  If such intermediate systems do intervene, the address of
   the coder would no longer be present as the network-level source
   address in packets received by the decoder, and in fact, it might not
   be possible for the decoder to send packets directly to the coder.
"

So what is still needed from our point of view is a standard way to
control media.

We have ideas on this last issue and will be pleased to contribute to
this effort,

Best Regards,

----------------------------------------------------
Patrick Monfort
R&D Engineer
France Telcom R&D DMI/SGV
38-40 Av du Leclerc
92794 Issy Les Moulineaux - France
Tel: +33 1.45.29.43.95
Fax: +33 1.45.29.52.94
---------------------------------------------------

-----Original Message-----
From: Joerg Ott [mailto:[email-masked]]
Sent: lundi 22 juillet 2002 19:13
To: Orit Levin
Cc: [email-masked]
Subject: Re: [MMUSIC] video media control draft

Roni and Orit,

let me make a quick basic points before we turn again to trying to
solve this problem:

A)  I very much and very well understand *what* you want to achieve
    and *why* you want to have this.  There is no point in re-iterating
    the same thing over and over again.

B)  I also very much appreciate your desire and your efforts to create
    a standardized solution (particularly, standardized in the IETF).

C)  That said, however, it does not seem too productive to argue
    "yes, we want a standardized solution" followed by "but only if
    it is the solution we have in mind."

Roni, Stephan, and myself sat together to discuss a number of possible
scenarios that could solve your problem, ruling out our current ideas
one by one with only RTCP remaining as senssible option.  In my
opionion,
this is because

- either there is no other sensisble option using existing signaling
  protocols (and hence a new one would be needed -- which all of us 
  seem to agree is kind of the long-term perspective);

- or we just have not found it yet -- in which case I would like you to
  come up with ideas that fit the respective protocol's spirit rather
  that re-stating that you want it your way.

I also understand your need to implement interworking with H.323 and
H.320.  As we know, H.320 has a control protocol which is synchronized
with the media stream so that Fast-Infra-Request, Picture-Freeze, and
other commands made sense.  This coupling was lost in H.323 when the
media stream was decoupled from the control signaling.  As far as I
know this happened when the H.230/H.242/H.243 commands and indications
were simply copied into the H.245 spec without too much consideration
whether this approach was sufficient or particularly meaningful from
a semantics perspective.  

This was a clear "design" mistake -- why should we repeat this here?
We try to make proper use of the protocols that we have created and
we must not be the ones setting bad precedent here.  So, please let's
do it together, but also do it "right".

Roni pointed out the possible decoupling of focus ("MC") and media
processor in a mixed protocol MCU.  Well, this is surely a valid point
but I suspect those two communicate via something similar to MEGACO.
Why can't they communicate reception of a FIR or indicate that one
shall be send.  As a working group, we cannot accept to make your
system design a starting point for our protocol decisions.

BTW: Once we have enabled "just a single command", more will follow.
     Been there, seen that.

Finally, let we quickly address your points one by one:

> It is unfortunate that we couldn't find time during the MMUSIC meeting
to
> reasonably discuss the "Picture Update" topic face to face. That is in
order
> to be sure that we all understand the requested functionality and the
> consequences of not having its standard definition ASAP.

As WG co-chair I have to reject this: I think we did more than fair
job allocating time to this discussion.  Just because we did not come
to a resolution in twice the time was not because a lack of time but
because of apparent disagreement.  Rather than running around in circles
the next reasonable step was to go back to the list and come up with
further ideas and reasoning -- which we are now doing.  This is good.

> 1. Without diving into scenarios, but based on videoconferencing
EXPERIENCE
> (including over IP), this is the ONLY video command that is absolutely
MUST
> and is WIDELY USED today in any video-related application (including
the
> simplest scenarios). It REQUIRES a coordinated (and desirably
STANDARDIZED
> in the IETF!) operation on both sides of the video stream.

I accept that and, again, I appreciate your coming to the IETF to do
this.

> 2. From an architectural point of view, any RTCP mechanism is not the
right
> answer for application layer commands. While applications use call
signaling
> and application media control for media stream establishment and
> manipulation, RTP/RTCP (with the addition of the "RTCP feedback") are
> dealing with congestion, etc. over IP in PARALLEL to the applications
> running above. This allows for a loosely coupled architecture between
the
> application and the RTP/RTCP modules.

From an architectural point of view, what you want to do is neither
SIP nor RTCP.  Just because SIP fits your system design better does
not make it more applicable.  What we try to do here is a short-term
fix and given what we know right now, RTCP seems more appropriate.

> 3. We also shouldn't forget the lack of the RTCP reliability being
> (potentially) reflected on our applications' behavior.

As I had iterated in an email some time back and someone else stated
at the meeting: there is no such thing like reliability but only
probably of arrivel within a certain time bound.  I accept that this
short-time arrival is more probably with active retransmissions.
But again, we try to find a short-term fix here.

(BTW: You assume that signaling will be fast (and hence lossless to be
 on time but at the same time expect the media to be pretty much
 unreliable -- this does not go together very well.)

> 4. Finally, the need for a real "application layer media control
protocol"
> has never been disputed. It takes time to define a new protocol. We
are

We are all in violent agreement on this.

> looking for a reasonable (i.e. doable and decently working) interim
solution
> for the Picture Update Request. I don't think it is reasonable to
expect
> vendors to TWIST their existing (and, in this case, architecturally
correct
> :-) implementations in order to achieve this required functionality as
an
> interim patch in the RTCP!!!

But you want to patch SIP/SDP in an architecturally incorrect way?
Let's not continue this religious debate here but try a more productive
approach (see further below).

> As a side bar conversation, I cannot prevent myself from not
commenting on
> the "Change of State" topic. Where does the definition of the "state
of
> stream" exist? Is it the same for voice, video, etc.?
> How about renaming the "Picture Update Request" into "Reset (Picture)
State
> Request"?

A quick and simple answer:
State is something you NEGOTIATE with offer/answer.  You DO NOT
NEGOTIATE
a picture update!  Or did you want to define a mechanism for the
answerer
to reject this, fall back to a different state, etc.

Finally, I would like to close this controversy here and ask all of
us to get to a productive approach.

In current thinking -- and I feel that this reflects the rough consensus
in the group -- SDP is just a NO GO!  I am only with you for SIP if we
find a proper use of a signaling protocol.

This leaves us with two alternatives: RTCP and some other mechanism
in SIP (or RTSP but I think this is really too far away).

I would like to you to describe a few pices of the intended
functionality first.  For this, let us assume the following setting:

    A --------- MCU --------- B
                    \_________C

B and C speak alternatingly, A sees the respective speaker.

B speaks, then stops.  C starts speaking.  The voice-activity
detection decides to switch to C.  What is the threshold here?
How frequently may this happen (every second, every 10 seconds, ...?)
This parameter is important as the time scales may have an influence
on the design decisions here.

(Is there, assuming the typical head-and-shoulders image, a 
graph indicating the maximum switch frequency for a given bandwidth?)

You said that you need a picture freeze command.  Please briefly
re-state why -- why will A at all receive rubbish in RTP payloads
instead of meaningful content?  (I am still just curious.)

When we switch from B to C, the MCU sends C an FIR.  What are the
"perceived" delay contraints between the voice activity detection
and the FIR sent to C?  How is, particularly in a distributed MCU,
the process between switching the media stream and sending out
the FIR synchronized.  What comes first?  What kind of media is
sent to A in the interim?

I think I'll have more questions for you but I'd like to start
with these to kind of scope the design space a bit to come up with
a quick and efficient solution for you?

Joerg

PS: Please note that, in principle, I am on vacation and have only
    infrequent Internet connectivity at most.  So replies may take
    a while.

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

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

---

From: Colin Perkins <[email-masked]>
Date: Wed, 24 Jul 2002 16:38:14 -0400

--> "MONFORT Patrick FTRD/DMI/ISS" writes:
...deleted...
>   be possible for the decoder to send packets directly to the coder.

The proposal is to use the same FIR packet format as in RFC 2032, but to
send the request to the standard RTCP port, using the mechanisms from
draft-ietf-avt-rtcp-feedback-03.txt to ensure timely feedback. Would 
that help?

Colin