Subject: RE: [MMUSIC] video media control draft

From: Orit Levin <[email-masked]>
Date: Fri, 19 Jul 2002 22:40:12 -0400

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.

I would like to reinforce the following points:

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. 

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.

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

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
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!!!

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"?

Orit Levin
Chief Architect
RADVISION Inc.
Tel:  +1.201.689.6330 

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 21 Jul 2002 14:02:56 +0900

> in the IETF!) operation on both sides of the video stream. 

I don't think there is really dispute on that point.

> application and the RTP/RTCP modules.

Well, it seems that it has already been done, since apparently an 
existing RFC uses RTCP for picture update. Its just codec specific at 
this point. While I don't think RTCP is ideal here, I don't find it 
architecturally incorrect.

> How about renaming the "Picture Update Request" into "Reset (Picture)

That changes nothing. In the offer/answer model, the SDP attributes are 
the current descriptions of the state of the stream - its encodings, its 
packetizations, etc. Furthermore, the attributes describe the local view 
of the streams. For example, if A sends an offer to B, the SDP in the 
offer describes A's view of the streams. What has been proposed is to 
add an SDP attribute that diverges from both assumptions. A "picture 
update request" attribute does not represent the state of the stream, 
since its not state - its a request. Furthermore, it does not describe 
the local view of the stream - it rather is an instruction for the 
recipient.

This kind of inconsistency can be troublesome in many ways. One way is 
in third party call control. Many 3pcc applications have the controller 
reusing the last SDP from a participant to generate an offer to a new 
participant that is to be brought in. If that last SDP was the result of 
a re-invite with this "picture update request", the controller will end 
up asking the new participant to generate a picture update, even though 
that is not what is intended. I fear that there are other complications 
that will arise. The SDP attribute proposal breaks several very 
fundamental assumptions in the O/A model.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Joerg Ott <[email-masked]>
Date: Mon, 22 Jul 2002 19:12:36 +0200

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.

> 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.

> 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.

> 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.

> (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.)

> has never been disputed. It takes time to define a new protocol. We are

We are all in violent agreement on this.

> 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).

> How about renaming the "Picture Update Request" into "Reset (Picture) State

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.