Subject: [siprec] summary of changes for draft-ietf-siprec-protocol-03

From: "Henry Lum" <[email-masked]>
Date: Thu, 8 Mar 2012 20:02:09 -0800

Here is a summary of changes in protocol draft 03:

1) Email thread "Is siprec metadata mandatory to implement?" 

many agreed on a) siprec option tag in a Supported/Require header means
an RS is supported/required AND XML metadata is supported/required for
this RS

Rewording Section 5.1

"An SRC MUST include the "siprec"

   option tag in the Require header when initiating a Recording Session

   so that UA's which do not support the session recording protocol

   extensions will simply reject the INVITE request with a 420 Bad

   Extension."

and Section 5.2

"An SRS MUST include the "siprec" option tag in the Require header as

   per [RFC3261] when initiating a Recording Session so that UA's which

   do not support the session recording protocol extensions will simply

   reject the INVITE request with a 420 Bad Extension."

2) Explain the reuse of label attribute for media streams that are
removed and later added to the recording session

Section 6.1, added the following sentence in 1st paragraph

"The scope of the label name only applies to the same SIP message as the
SDP, 

 meaning that the label name can be reused by another media stream
within the 

 same recording session."

3) allow the SRS to remove media streams in the recording session

Section 6.2 inserted paragraph after the first one

   "Over the lifetime of a recording session, the SRS can remove
recorded

   streams from the recording session for various reasons.  To remove a

   recorded stream from the recording session, the SRS sends a new SDP

   offer where the port of the media stream to be removed is set to

   zero, according to the procedures in [RFC3264]."

4) snapshot request issue below; that was the main debate since the last
ietf meeting. Andy has a good summary here that I agree with.

                > 1. An explicit snapshot request MUST be in an UPDATE
without SDP.

                > 2. The snaphot MUST be in either an UPDATE or a
reINVITE both of which 

                > MUST have SDP. I would be ok with mandating it be only
in an UPDATE 

                > but I think it is not necessary.

                > 3. The SRS MAY generate a reINVITE without SDP but
this MUST not 

                > include a snapshot request.

Based on the summary, here are the changes:

Section 8.1 paragraph 3

"...When the SRC sends a full metadata snapshot, the SRC MUST

   send an INVITE or an UPDATE request with an SDP offer and the

   "recording-session" disposition."

Section 8.2 paragraph 3

"When the SRS explicitly requests for a full metadata snapshot, the

   SRS MUST send an UPDATE request without an SDP offer.  A metadata

   snapshot request contains a content with the content disposition type

   "recording-session".  Note that the SRS MAY generate an INVITE

   request without an SDP offer but this MUST not include a metadata

   snapshot request."

5) multiplexing of rtp/rtcp; I commented that we should not mention
RFC5761 at all in the protocol draft

6) rename feature tags from src to "+sip.src" and srs to "+sip.srs"

7) extend record and recordpref SDP attribute to session level
(currently only media level)

8) SRC and SRS feature tags in REGISTER

make this MUST when an SRC or SRS registers

Section 5.1, paragraph 2

"...In addition, when an SRC sends a REGISTER request

   to a registrar, the SRC MUST include the '+sip.src' feature tag to

   indicate the that it is a SRC."

Section 5.2, paragraph 2

"...In addition, when

   an SRS sends a REGISTER request to a registrar, the SRS MUST include

   the '+sip.srs' feature tag to indicate that it is a SRS."

9) Address Andy's and Gonzalo's comments

Regards,

Henry