Subject: [siprec] Comments on draft-portman-siprec-protocol-03

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 9 Mar 2011 19:06:10 +0530

Hi Leon et all,

Good work in putting up this draft. Here are some of my general
comments:

The title says "The SIP-based Media Recording Protocol (SIPREC)" where
as abstract says "SIPREC Session Recording Protocol". I think it's
better to have a consistent naming convention. I suggest using "Session
Recording Protocol" which the charter has. The same(Using of SIPREC
protocol and Session Recording Protocol alternatively) is seen at
several places across the document . It would be better to have one
naming convention across the document.

The introduction section says

"In order to allow access to such recordings, information about the
communication session (metadata) is also shared between SRC and SRS."

This sentence is little confusing as it sounds like metadata needs to be
shared between SRC and SRS to allow access to recording. Irrespective of
whether we send metadata or not SRS can still access the data. So I
suggest we reword it as

"The metadata about a CS SHALL be sent from SRC to SRS"

There may not be need to re-define the terms in Section 2 as
ietf-siprec-req already has them. IMO reference to ietf-siprec-req is
sufficient.

I am not sure if scope section is needed, SIPREC requirements document
clearly lists what are the requirements that needs to be addressed.
Anything not mentioned there is outside the scope. Do we need to
explicitly call out the list here ?

Section 4.1, Figure 2

I see that RS invite is sent after CS is connected. I don't think we
need to restrict the call flow to this. There MAY be implementations
where RS may be setup right after SRC receives INVITE even before CS is
connected. Also for persistent recording cases the call flow will be
different.

We will have to see if there is a real need to have the metadata
snapshot request provided as an INFO  package.  I have not seen a strong
use case for that as of now.  IMO ( and raised by others too) it's
better to use UPDATE/RE-INVITE.

Section 5 has this text

"The SRC must be able to accept re-INVITE from SRS with the updated SDP
as part of the session timer mechanism." why do we need this text here ?
Is Session refresh handling different for RS from what is mentioned in
RFC 4028 ? If not I don't see a need to mention here. 

Section 5.3.1 we need to discuss more on how re-sync between SRS and SRC
can happen. I will give my comments on the mail thread that Andy has
started for this.

Please also add reference to metadata format draft that has XML schema
(draft-ram-siprec-metadata-format-01)

Regards,

Ram

---

From: Leon Portman <[email-masked]>
Date: Thu, 10 Mar 2011 15:59:20 +0200

Ram Hi

Thank you very much for the comments

Please see below

Leon

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Wednesday, March 09, 2011 3:36 PM
To: [email-masked]; Leon Portman
Subject: [siprec] Comments on draft-portman-siprec-protocol-03

Hi Leon et all,

Good work in putting up this draft. Here are some of my general comments:

The title says "The SIP-based Media Recording Protocol (SIPREC)" where as abstract says "SIPREC Session Recording Protocol". I think it's better to have a consistent naming convention. I suggest using "Session Recording Protocol" which the charter has. The same(Using of SIPREC protocol and Session Recording Protocol alternatively) is seen at several places across the document . It would be better to have one naming convention across the document.

[Leon] yes, good comment. SIPREC was used as a friendly protocol name.

The introduction section says
"In order to allow access to such recordings, information about the communication session (metadata) is also shared between SRC and SRS."
This sentence is little confusing as it sounds like metadata needs to be shared between SRC and SRS to allow access to recording. Irrespective of whether we send metadata or not SRS can still access the data. So I suggest we reword it as
"The metadata about a CS SHALL be sent from SRC to SRS"
[Leon] Agree

There may not be need to re-define the terms in Section 2 as ietf-siprec-req already has them. IMO reference to ietf-siprec-req is sufficient.
[Leon] We wanted to have the protocol document self-contained for reading and understating as possible

I am not sure if scope section is needed, SIPREC requirements document clearly lists what are the requirements that needs to be addressed. Anything not mentioned there is outside the scope. Do we need to explicitly call out the list here ?
[Leon] We were just using template from other protocol drafts (like XCON). Usually they have scope inside

Section 4.1, Figure 2
I see that RS invite is sent after CS is connected. I don't think we need to restrict the call flow to this. There MAY be implementations where RS may be setup right after SRC receives INVITE even before CS is connected. Also for persistent recording cases the call flow will be different.
[Leon] Agree, it is just an example

We will have to see if there is a real need to have the metadata snapshot request provided as an INFO  package.  I have not seen a strong use case for that as of now.  IMO ( and raised by others too) it's better to use UPDATE/RE-INVITE.
[Leon] Lets discuss it in Prague. It is important point

Section 5 has this text
"The SRC must be able to accept re-INVITE from SRS with the updated SDP as part of the session timer mechanism." why do we need this text here ? Is Session refresh handling different for RS from what is mentioned in RFC 4028 ? If not I don't see a need to mention here.
[Leon] We should finalize this as well.

Section 5.3.1 we need to discuss more on how re-sync between SRS and SRC can happen. I will give my comments on the mail thread that Andy has started for this.
[Leon] Ok

Please also add reference to metadata format draft that has XML schema (draft-ram-siprec-metadata-format-01)
[Leon] We should check if it will not create some circular references

Regards,
Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2011 09:11:15 -0500

> [Leon] We should check if it will not create some circular references

Circular references are not forbidden.
The consequence is that they must make the transition to RFC 
concurrently. That may be ok. But if things can be arranged to avoid 
circular references it is probably better.

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 10 Mar 2011 22:01:35 +0530

Leon,
 
Adding to Paul's point, currently Sec  8 of draft-ram-siprec-metadata-format-01 refers draft-portman-siprec-protocol-03, Sec 7 & 8 of draft-ram-siprec-metadata-format-01  is written for providing more information to understand usage of XML with SIP & SDP and there is no normative statements involved related to metadata. when everybody comes to have some common understanding, these example shall be removed or modified with just XML body in the later stage . So, circular reference shall be avoided easily then.
 
Apart from this, there was a comment not to include SIP stuff in draft-ram-siprec-metadata-format-01 and it is mentioned as an one open item in Sec 7:

   "Open item: Whether it is allowed to have SIP specific table in this
   draft?" 
 
Please let me know your opinion here. 
 
Thanks
Partha
________________________________

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Thu 3/10/2011 7:41 PM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-03

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

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 10 Mar 2011 17:38:19 +0100

</snip> 
> ietf-siprec-req already has them. IMO reference to 
> ietf-siprec-req is sufficient.
> 
[JRE] That is fine while it is an individual draft, but when these drafts are adopted as WG documents, I would want to avoid too much duplication.

> I am not sure if scope section is needed, SIPREC requirements 
> document clearly lists what are the requirements that needs 
> to be addressed. Anything not mentioned there is outside the 
> scope. Do we need to explicitly call out the list here ?
> 
> [Leon] We were just using template from other protocol drafts 
> (like XCON). Usually they have scope inside
[JRE] There is no set rule. If it makes sense to have a scope section, rather than putting such statements into the introduction section or relying on a reference to the requirements document, say, then fine. But there certainly is no necessity for a scope section.

John (as chair)