Subject: [siprec] proposed changes to draft-ietf-siprec-protocol-11

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Sun, 17 Nov 2013 03:06:28 +0000

While presenting the changes from draft-ietf-siprec-protocol-10 to
draft-ietf-siprec-protocol-11 at IETF 88, we discussed a small set of
additional changes. I promised to summarize and provide suggested text.
Here it is.

Section 7.1.3. Recording Preference In CS
The MUST was dropped in the previous change. The proposal is to add it
back and edit slightly.

OLD (version 10)
Whether or not the SRC honors the recording preference, the SRC MUST
update the a=record attribute to
indicate the current state of the recording (on/off/paused).

CURRENT (version 11)
If the SRC makes a change in recording state, then the SRC reports the
recording state in the a=record attribute in the SDP answer or in a
subsequent SDP offer/answer.

PROPOSED (for version 12)
If the SRC makes a change in recording state, the SRC MUST report the new
recording state in the a=record attribute in the SDP answer or in a
subsequent SDP offer.

7.3.1. Recording indication

CURRENT (version 11)
It is possible that more than one SRC can be in the call path recording
the same CS, but the recording indication attribute does not provide any
hint as to which SRC is actually performing the recording. This means that
an endpoint only knows that the call is being recorded through the
recording indicator. This attribute is also not used as an indication to
negotiate which SRC in the call path will perform recording and is not
used as a request to start/ stop recording if there are multiple SRCs in
the call path.

PROPOSED (for version 12)
It is possible that more than one SRC is in the call path of the same CS,
but the recording indication attribute does not provide any hint as to
which SRC or how many SRCs are recording. An endpoint only knows that the
call is being recorded. Furthermore, this attribute is not used as a
request for a specific SRC to start/ stop recording.

9.2. Procedures at the SRS

CURRENT (version 11)
The SRS MAY explicitly request a full metadata snapshot by sending an
UPDATE request.  This request MUST contain a body with a content
disposition type "recording-session", and MUST NOT contain an SDP body
part.  Note that the SRS MAY generate an INVITE request without an SDP
offer but this MUST NOT include a metadata snapshot request.

PROPOSED (for version 12)
The SRS MAY explicitly request a full metadata snapshot by sending an
UPDATE request.  This request MUST contain a body with a content
disposition type "recording-session", and MUST NOT contain an SDP body
part. The SRS MUST NOT request a full metadata snapshot in an UPDATE
response or in any other SIP transaction.

Comments are welcome. Silence is not :)

Cheers,
Charles

---

From: Henry Lum <[email-masked]>
Date: Mon, 25 Nov 2013 14:30:49 +0000

The updated revisions look good to me.

Thanks
Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Charles Eckel (eckelcu)
Sent: November-16-13 10:06 PM
To: [email-masked]
Subject: [siprec] proposed changes to draft-ietf-siprec-protocol-11

OLD (version 10)

CURRENT (version 11)

CURRENT (version 11)

CURRENT (version 11)

Cheers,
Charles

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