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

From: Orit Levin <[email-masked]>
Date: Thu, 1 Aug 2002 09:22:20 -0400

Nils and all the rest!
I am replying to the whole thread being exchanged today so far.
I agree with the bottom line conclusion (although my reasoning may be
slightly different).

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

sequence, only the first SDP arriving at remote should trigger any 
change/sideeffects.

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

_______________________________________________
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: Joerg Ott <[email-masked]>
Date: Tue, 06 Aug 2002 17:45:23 +0200

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