Subject: Re: [MMUSIC] Signaling FIR/Freeze in SIP

From: Nils Henrik Lorentzen <[email-masked]>
Date: Thu, 1 Aug 2002 08:52:51 +0200

On Wednesday 31 July 2002 12:38, you wrote:

> 1. Sending a freeze a couple of times may cause a problem. The freeze
> requests are sent from the MCU and not from the encoding endpoints while
> the full picture is coming from the endpoint. So what happens if a freeze
> arrives after the intra frame with the freeze release code. The decoder
> will freeze, he has no way to know if the freeze was for a switch in the
> past or for a switch in future.

As mentioned in anther post,  this problem could probably be solved
by sending the RTP's timestamp/sequence number at the time of sending
the first freeze. Possible this introduces more problems though.

> 2. The customers of the video conferencing MCUs do not like to have an ugly
> video during the video switch, so we need a solution which will be more
> reliable.

If we can do retransmits of freeze, then in my opinion loss of all freeze
packets would be rare enough to justify best-effort sending.

> So how do you see inter-op between H.323 and SIP or is this not an issue

It sure is an issue.  Making old H.323 endpoints support new RTCP packets
would take time or more likely never happen, so the only possibility would
be to also handle RTCP/RTP in a H.323/SIP GW. I agree this speaks
strongly against an RTCP based solution.

> > If an endpoint sends the exact same SDP to another endpoint
> > several times in
> > sequence, only the first SDP arriving at remote should trigger any
> > change/sideeffects.
>
> OK, so let us call the two messages freeze and freeze release. Sending
> freeze a couple of times will keep the receive in a freeze state. Sending
> freeze release will keep the receiver in a freeze release state. The two
> requests cause a change of state.

OK, I have reread you posts even more thoroughly, but I'm still
not sure I understand your proposal fully. You want to put decoder in freeze 
state using SDP. The freeze will be released, not by a new SDP, but by a full 
intra or a timeout at the decoder.

Although it seems a bit odd to me to change the state back using non-SDP
means, I  cannot see any problem with this. Both encoder and conf controller
should eventually end up having the correct view of the others' state even if 
timeout occurs or full intra is lost. Nitpick: I would name the attribute
"paused" or similar, to reflect the local view of the state at the conf
controller. SDPs are not for sending requests, but rather snapshots of the
local state.

You also have to send a FIR to the encoder. AFAI understand you
want to do this using a "new-stream" attribute. This will cause
a full-intra to be sent.

This does not pass the test mentioned above, as sending several
such SDPs would trigger the sideeffect of sending a full intra
each time. 
I think classifying "new-stream" as a state-change is
a bit far-fetched, but not  wrong; You would then have a
possibly infinite number of states," receiving-stream-1",
"receiving-stream-2"  etc. You somewhere compared this to
asking for a new orientation. A  difference here is that in the latter case
you have a finite number of  well-defined states, "portrait" and
"landscape". Using an a=receiving-stream-x attribute would
pass the test, as it would only cause a full intra when "x "
was increased.
In fact I think you could signal almost any kind of
request as a local state change, for example you could signal
DTMFs as a=cur-dtmf # 4, where "#" is digit and 4 is a
sequence-number. While possible,  I don't think SDP was meant
for signaling in such a manner.

You still would have to send FIRs when synchronization issues occur.
You could argue this is a statechange between receiving
deltas and receiving full intras (ie. a=recving-delta, a=recving-intra, 
a=recving-gob). This could also replace the above "new-stream" 
attribute.
Is this a somewhat correct understanding of your proposal ?

There has not been any discussion yet of the third
alternative, using a new protocol in INFO (or similar). AFAI have
understood, everyone has acknowledged the need for such a protocol
(to signal many of the commands sent in H.245, like confernce control), and
one should probably define  one to accompany SDPng.
However, we could define a simple more short-term one to accompany SDP.
This protocol would fade away alongside SDP as we move to
SDPng and the new command protocol.

Something like:

"version" ":" version        ; protocol version
command [  media-line-number ] [ " :" parameters  ]

Example:
version : 0
fir 0         ; full intra for stream corresponding to 1st SDP m-line
freeze 1  ; send freeze for stream corresponding 2nd SDP m-line

Is something like this a possible solution or is it completely out of the 
question ? Has it  already been discussed and rejected ? It would not
have the SIP/H323 GW issue and would not require changes in existing
implementations.
 
Nils Henrik Lorentzen

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

---

From: Orit Levin <[email-masked]>
Date: Tue, 6 Aug 2002 17:42:29 -0400

Joerg and all!
These are my thoughts:
1. The XML scheme is defined as a general Media Control Protocol. Video
specific commands are arranged under a separate branch.
2. I think that developing this initial work into a complete standard
protocol is doable and would be very beneficial.
3. The transport of this protocol is (almost) a separate topic. We can spend
more time on this in SIP/SIPPING in parallel to the protocol definition
itself in MMUSIC.
4. In regards to using the Events mechanism:
a. I wouldn't like to ignite a debate about the applicability of the
Subscribe/Event approach to a CONTROL protocol in general. I would just say
that, in my opinion, it is a real twist to the whole EVENTs' purpose. 
b. Additionally, it carries all the cons of SIP being used for Media Control
with only a "slight improvement" (from a standardization point of view) by
using the Packages' concept.
c. A Media Control protocol doesn't have to be SIP.
d. My main opposition to the EVENTs mechanism is because its Data Model
would be completely different from a straight-forward CONTROL protocol. If,
as a multimedia vendor, I need in parallel to support both, I would "prefer"
to implement two similar (or very close) data models that differ in their
transport only.

Hope it makes sense,
Orit .

 -----Original Message-----
From: 	Joerg Ott [mailto:[email-masked]] 
Sent:	Tuesday, August 06, 2002 11:45 AM
To:	Orit Levin
Cc:	'Nils Henrik Lorentzen'; [email-masked]
Subject:	Re: [MMUSIC] Signaling FIR/Freeze in SIP

Orit and all,

I have gone through a number of scenarios and, apparently, one particular
case of H.323-SIP interworking (namely if an H.323 endpoint is connected
via a piece of SIP in the middle to a SIP- or H.323-based MCU) is not
workable at all with just RTCP.  So, what we are doing right now is
solely for the purpose of interworking.

Your proposal to provide a description of the actual event information
to be conveyed has merit -- particularly as it can be discussed 
independently of the transport used later on to carry it.  In addition,
we obviously need to define a MIME type for this data format.

I would like to encourage you to think a bit beyond the pure video
conferencing applications as it would be perfect if we could keep
whatever we come up with right now and build on this for the future
rather than having two or more mechanisms to deal with eventually.

As for the transport: you know that I am very much opposed to tunneling
in SIP INFO, so I'd still like to research other ways -- even within
SIP -- to carry this contents.  Basically, what you want to do is
have the MCU provide an endpoint with an indication/command that a
new intra frame is needed.  Can this information be derived from a
(slightly extended) conference event package or modeled as a different
application-specific event package?  After all, the intra frame is
triggered by a change in the "viewer status" (who sees the video of
the endpoint) which should be watchable in some way.

From what Roni and myself have discussed, the conference package is
insufficient insofar as the send-status types defined so far
("received-by-all", "muted", "unknown") do not allow to reflect the
transition you are interested in.  Adding "received-by-one" would
solve only part of the problem.  But a meaningful addition may make
sense to be explored here (and obtain all you need from a mechanism
already under development).  A SIP MCU is likely to support the
conference package anyway.

Of course, any SIP-H.323 gateway would need to be aware that the
user is connected to a conference and subscribe to the respective
state.  But, on the other hand, it would need to translate SIP INFO
into some H.323 stuff, too.  So while being potentially cleaner,
using SUBSCRIBE/NOTIFY is not worse from the backwards compatibility
point of view.

Thoughts?

Joerg

> Since, there is no agreement to standardize the required primitives within
> the old SDP and taking into account all the drawbacks of such a solution,
> there is no point pursuing this direction.
> 
> Instead, we need two things:
> 1. Working on a new point-to-point media control protocol
> 2. Agree on a doable way (such as INFO) to convey the required primitives
in
> the call signaling path. It doesn't have to be a standard.
> 
> For all the practical reasons, multimedia vendors will need to support
both.
> 
> We (as RADVISION together with its partners) already have a simple
> extensible XML scheme to be conveyed in the INFO messages for exactly this
> purpose. I plan to publish it as an IETF draft shortly.
> 
> BR,
> Orit Levin
> Chief Architect
> RADVISION Inc.
> Tel:  +1.201.689.6330
> 
>  -----Original Message-----
> From:   Nils Henrik Lorentzen [mailto:[email-masked]]
> Sent:   Wednesday, July 31, 2002 6:04 AM
> To:     [email-masked]
> Subject:        [MMUSIC] Signaling FIR/Freeze in SIP
> 
> Hi,
> 
> We at TANDBERG would like to voice our opinion on the full intra/freeze
> request issue, as the decision made may affect us in the future.
> 
> There are as far as we can see three proposed solutions to the problem of
> signaling these requests within the SIP framework:
> 
> 1. Use RTCP
> 2. Use SDP
> 3. Some kind of new protocol tunneled in INFO or a similar SIP method.
> 
> Our opinion so far:
> 
> 1. This is in our opinion the best solution from a design perspective. We
> see
> it this way: Keeping a good quality video stream and output is an issue
> between the encoder and decoder, thus information for that purpose should
be
> 
> sent directly between them. Ideally it should not be sent along the
> signaling
> path, but along the media path.
> 
> There seems to be two main arguments against the RTCP solution:
> 
> - RTCP is not reliable.
> We agree with Colin, in that this is a non-issue. The FIR message could be
> retransmitted until a full intra is received. As for freeze requests,
these
> could be retransmitted a predefined number of times with a predefined
> interval. If any of them arrive at the decoder all is fine. In the rare
case
> 
> where none do, the user will see some ugly video output for a relatively
> small amount of time, until it receives a full intra, but it will not
> otherwise affect the call.
> There may be issues here we have not thought of, though.
> 
> - H.323 EPs do not support these new RTCP packets. We think this is more
of
> an issue. As Roni pointed out, a SIP/H.323 signaling GW would not be able
to
> 
> gather the FIR requests from the SIP side and pass it on to the H.323
side,
> unless it is also acts as GW for the RTP/RTCP traffic. The latter is of
> course not ideal, but could do as a temporary solution. One would probably
> need to add a new option flag to H.323 call setup messages telling whether
> the endpoint supports FIR/freeze in RTCP.
> 
> 2. Using a media attribute in SDP for signaling a FIR is wrong in our
> opinion. SDPs are for telling what kind of streams you want from the time
> you
> send it until the next time you send an SDP.  A full intra is a request
that
> 
> is executed only once when received.
> 
> We believe the following can be used as a "litmus test" for determining
what
> 
> information is OK to send in SDP and what is not:
> 
> If an endpoint sends the exact same SDP to another endpoint several times
in
> This holds true in for example hold/resume but not for full intra req.
> 
> 3. This is in our opinion not the ideal solution from a design POV, but it
> will interoperate better with existing H.323 EPs when SIP/H323 GWs are
> implemented. It would require a new protocol to be defined., but could be
a
> very simple and limited protocol though, as it would just be a temporary
> solution.
> We would possibly need a new such protocol when SDPng arrives, since we
have
> 
> to refer to a SDPng media channel in a different manner than refering to
an
> SDP channel.
> 
> To conclude, we support solutions 1 and 3, while 2 is definitely the worst
> alternative. While using RTCP (or similar protocol directly between
> encoder/decoder) is in our opinion the cleanest solution, 3 might be used
if
> 
> the SIP/H.323 switching problem is deemed important enough and no other
> problems with using RTCP are found.
> 
> Nils Henrik Lorentzen
> 
> Software Developer
> TANDBERG
> http://www.tandberg.net
>

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 7 Aug 2002 09:11:46 +0300

Joerg,
I think you did not look at the case where we have an H.323 MCU connected
through a signalling GW to a SIP client or an H.320 MCU connected through a
GW to the SIP client. In that case the GW function will need to include the
support for the control package, so it is not only for MCU to implement this
package.
Roni Even

> Sent: Tuesday, August 06, 2002 6:45 PM
> To: Orit Levin
> > 2. Agree on a doable way (such as INFO) to convey the 
> required primitives in
> > For all the practical reasons, multimedia vendors will need 
> to support both.
> > 
> > between the encoder and decoder, thus information for that 
> purpose should be
> > 
> > retransmitted until a full intra is received. As for freeze 
> requests, these
> > interval. If any of them arrive at the decoder all is fine. 
> In the rare case
> > 
> > - H.323 EPs do not support these new RTCP packets. We think 
> this is more of
> > an issue. As Roni pointed out, a SIP/H.323 signaling GW 
> would not be able to
> > 
> > gather the FIR requests from the SIP side and pass it on to 
> the H.323 side,
> > send it until the next time you send an SDP.  A full intra 
> is a request that
> > 
> > We believe the following can be used as a "litmus test" for 
> determining what
> > 
> > implemented. It would require a new protocol to be 
> defined., but could be a
> > We would possibly need a new such protocol when SDPng 
> arrives, since we have
> > 
> > to refer to a SDPng media channel in a different manner 
> than refering to an
> > SDP channel.
> > 
> > encoder/decoder) is in our opinion the cleanest solution, 3 
> might be used if
> >