Subject: Re: [MMUSIC] video media control draft

From: Joerg Ott <[email-masked]>
Date: Tue, 06 Aug 2002 14:27:33 +0200

Roni,

thanks for the reply.  Comments inline.

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

You should have other information at hand: the SSRC (in case of a
translator)
or the CSRC (in case of a mixer) will be different.

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

Again, shouldn't a source change result in a different SSRC/CSRC?

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

Ok.  That's a good one.  Thanks for elaborating on this.

> 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

Still, I don't think they are in IP as they take different paths with
unknown
latency properties.

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

SDP does not make sense for the FIR command.  I think enough people have
argued this and I would like to close this part of the debate and focus
on alternatives.

The rest of the SDP extensions you are proposing (picture size, etc.) are
fine.  We surely had consensus on this.

> 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 believe have seen statements from videoconferencing folks that did
not favor the SDP approach.  We are just trying to find a solution
that fits the spirit of the protocols we are using.

> As for SIP, are you stirring us to a INFO based solution , I am not aware of
> other existing solution

I hope that I did not convey this impression.  I would like to keep you
away
from INFO as far as possible.  In my opinion, INFO should be treated as if
it
were non-existent.

Joerg

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

---

From: Nils Henrik Lorentzen <[email-masked]>
Date: Wed, 7 Aug 2002 09:36:05 +0200

Hi Joerg

> > As for SIP, are you stirring us to a INFO based solution , I am not aware
> > of other existing solution
>

Out of curiosity, what do you think is wrong with INFO ? Is it too much of a 
generic "contain anything that does not fit elsewhere" message ? 

Nils Henrik Lorentzen

---

From: "Eric Burger" <[email-masked]>
Date: Fri, 9 Aug 2002 12:29:05 -0400

I am at a bit of a loss here.

With a partner, we do a H.323 <-> SIP gateway for voice.  One thing we have
to do is take things in the H.323 signaling realm (like H.245 tones) and put
them into the RTP realm (like RFC2833 tones).

For some things, H.323 and SIP have fundamentally different architectures.
I would propose that trying to force H.323 into SIP or SIP into H.323 is not
a useful exercise.  For example, if you have things like full-frame refresh
in the signaling channel on the H.323 side, you can easily insert a media
server in the media stream to insert the appropriate RTCP packet on the SIP
side, and vice-versa.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Even, Roni
Sent: Tuesday, July 23, 2002 8:33 AM
To: 'Joerg Ott'; Orit Levin
Cc: [email-masked]
Subject: RE: [MMUSIC] video media control draft

[snip]

[snip]

---

From: Joerg Ott <[email-masked]>
Date: Mon, 19 Aug 2002 08:41:57 +0200

> generic "contain anything that does not fit elsewhere" message ?

This is essentially the point.  It is ill-defined.  SIP is a signaling
protocol intended to create, modify, and delete session state.  SIP INFO
has been invented to transparently carry ISUP data end-to-end in case of
SS7 trunking via SIP.  Other uses have been envisioned but have been
abandoned one by one.  As INFO does not specify semantics, handling of
forking is not defined; congestion control is not applied (not even
warned about in the spec), for example.

This essentially turns SIP into a transport protocol which is
probably one of the most inefficient uses one can imagine.
SIP INFO has no defined semantics besides "carry this byte bucket
to the other side".

In ISUP, the intend is to simply forward the data (unprocessed) to
the PSTN (INFO explicitly states that call state MUST NOT be altered
based upon the contained message body).  It has been repeatedly
discussed, however, that entities may actually look at the payload and
take some actions according to the contents (which would be bad by
itself  because it contradicts the idea of transparent end-to-end
carriage).  Either you specify syntax and semantics in SIP -- then
your endpoints and intermediaries may use it -- or you don't --
then they better don't touch it at all.  So far for the potential
flaws of INFO in the ISUP context.

In other cases, SIP INFO is just semantics-free by itself and invites
(mis)use by and for evertything.  But, at least arrive at a common
understanding and thus achieve interoperability, protocol elements
must have a well-defined meaning by themselves rather than requiring
this to be implied from the message body (or a header).

Joerg