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

From: "Even, Roni" <[email-masked]>
Date: Wed, 31 Jul 2002 13:38:38 +0300

Hi,
My comments are inside
Roni Even

> -----Original Message-----
> From: Nils Henrik Lorentzen [mailto:[email-masked]]
> Sent: Wednesday, July 31, 2002 1:04 PM
> 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.

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

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

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

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

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.

> 
> 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: Pekka Pessi <[email-masked]>
Date: 31 Jul 2002 15:21:42 +0300

>freeze, he has no way to know if the freeze was for a switch in the past or

	You can always include sender's timestamp in the request.

					Pekka