Subject: [siprec] CS hold/resume clarification in protocol draft

From: Henry Lum <[email-masked]>
Date: Thu, 18 Apr 2013 04:15:05 +0000

Following up on the clarification in the protocol draft, I propose to re-word the last paragraph in section 7.1.1.1. I removed mentions on the word mute/unmute:

   The SRC can temporarily discontinue streaming and collection of
   recorded media from the SRC to the SRS for reason such as masking the
   recording.  In this case, the SRC sends a new SDP offer and sets the

   media stream to inactive (a=inactive) for each recorded stream to be
   paused, as per the procedures in [RFC3264<http://tools.ietf.org/html/rfc3264>].  To resume streaming and
   collection of recorded media, the SRC sends a new SDP offer and sets
   the media streams with a=sendonly attribute.

   Note that a CS itself may change the media stream direction by updating

   the SDP, for example, by setting a=inactive for SDP hold. Media stream

   direction changes in CS are conveyed in the metadata by the SRC. The SRC

   SHOULD NOT modify the media stream in the RS to convey media stream

   direction changes in the CS, as media stream direction changes in the RS

   are reserved for pausing and resuming the recorded media.

Thanks

Henry

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 30 Apr 2013 13:19:09 +0000

Hi Henry,

Only question I have is whether the "SHOULD NOT" in the following text could be a "MUST NOT"

"The SRC SHOULD NOT modify the media stream in the RS to convey media stream direction changes in the CS"

What does everybody think?

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Henry Lum
> Sent: 18 April 2013 05:15
> To: [email-masked]
> Subject: [siprec] CS hold/resume clarification in protocol draft
> 
> Following up on the clarification in the protocol draft, I propose to
> re-word the last paragraph in section 7.1.1.1. I removed mentions on
> the word mute/unmute:
> 
> 
> 
>    paused, as per the procedures in
> [RFC3264<http://tools.ietf.org/html/rfc3264>].  To resume streaming and
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Alan Johnston <[email-masked]>
Date: Tue, 30 Apr 2013 10:00:11 -0500

We definitely want to discourage this behavior, but MUSTs relate to interop failures. Is that what we are trying to avoid?

Another thought - If an implementer used 1 RS for each CS, would this hold/resume behavior be wrong?

- Alan -

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Apr 2013 12:51:23 -0400

> Another thought - If an implementer used 1 RS for each CS, would this hold/resume behavior be wrong?

Clearly this won't cause an interop failure between the SRC and the SRS.
But it can result in the SRS misunderstanding the state - believing that 
recording has been stopped when it has not. That could lead to problems 
(maybe legal problems) analyzing recordings.

I prefer MUST.

This still doesn't prevent the SRC from doing it. But it means that the 
SRC is deciding that recording should stop when the CS goes on hold. 
That reflects a different SRC policy.

	Thanks,
	Paul

---

From: Henry Lum <[email-masked]>
Date: Wed, 1 May 2013 04:39:08 +0000

The only interop issue this can cause is an SRS would mistaken a hold as pause/resume. Would there be any harm done in this case? It's undesirable but I dont think it's broken as there should be corresponding metadata to note the media stream change.

Henry

-------- Original message --------
From: Alan Johnston <[email-masked]>
Date: 04-30-2013 11:00 AM (GMT-05:00)
To: "Hutton, Andrew" <[email-masked]>
Cc: Henry Lum <[email-masked]>,[email-masked]
Subject: Re: [siprec] CS hold/resume clarification in protocol draft

- Alan -