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

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 18 Jul 2011 19:57:26 +0530

Leon et all,

Over all the draft is coming up good. Here are some of my comments..

1)Section 1 says "The Session Recording Protocol uses SIP as the
protocol for session establishment with special attention to reducing
size of the required SIP messages. "

I am not clear on what is the context of this statement w.r.t SIPREC
solution and how it helps in reducing size of messages.  Can you please
clarify ?

2)Section 1 says "In addition, it is designed for future extendibility
and protocol version management to ensure backward compatibility"

Again can you please clarify how this is done ?

3)I would suggest to have only new definitions on Section 2. In case you
still want to retain them please make them consistent.  I see some
mismatch in the definitions of Section 2 to the ones in Requirement
draft. 

4)In Figure 2, the RS may be setup upon receiving INVITE from UA A. It
need not wait always until A and B are connected. IMO this is a policy
decision. You may want to add a note saying the same. The diagram gives
an impression that it may be the only way RS may be setup.

5)Section 4.3 has this text about delivering metadata

<snip>

"In some cases session metadata can be conveyed through non-SIP

   mechanism such as HTTP or JTAPI.  These non-SIP mechanisms are

   considered out of the scope of the Session Recording Protocol,

   however, it is envisoned that a link with a URI can be provided in

   the recording session INVITE message so that the SRS can access the

   session metadata via the URI provided that the SRS supports the type

   of URI."

</snip>

IMO since the current metadata XML schema is not extensible outside SIP
it is better to not mention this text.

6)Section 5.2

<snip>

"To remove a recorded media stream from the recording session, send a

   reINVITE and set the port to zero in the m= line.

   To add a recorded media stream, send a reINVITE and add a new m=

   line."

</snip>

You may want to add a text here that this is applicable only if SRC is
recording each stream independently.

I have a question here. In case the stream sent from SRC to SRS happens
to be a mixed stream (IOW we have only one m-line), addition /deletion
of participants can be known by looking at metadata xml schema and
looking for all participants who <sends> a <stream>. Apart from this do
we need anything else in metadata or in protocol ?

7)Section 5.4

<snip>

"As mentioned in the previous section, the SDP of the recording

   session is the metadata for all recorded media streams."

</snip>

You may want to re-word this sentence to make it more clearer. Something
like this:

As mentioned in the previous section, the SDP of the recording  session
describes the properties of media for all recorded media streams.

8) Section 5.4

<snip>

For all basic metadata information such as communication session,

   participants, call identifiers and direction, they can be included in

   the initial INVITE request sent by the SRC. 

</snip>

Note that we are not sending direction attribute in  basic metadata. It
was agreed earlier that direction value is not possible to be determined
at all times and hence we may send it as extension data.

what is call identifier here ?

9) Sectoin 5.5

IMO this needs some more discussion before acceptance. As John mentioned
in another thread, we have not had much discussion on this either
before. 

10) Section 6.1

Apart from what is mentioned in last para of this section, I think we
can explicitly add a note that this attribute is NOT intended tell an
SRC to start/stop recording.

11) Section 6.3

Any reason why we explicitly need to indicate "nopreference".  Cant the
absence of this SDP attribute itself says that a UA has no preference.

Regards,

Ram

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 18 Jul 2011 17:46:42 +0200

Hi Ram,

Sorry I did not see your response before sending my own comments.

See some responses below.

Reading your comments made me think a more thorough review is needed which I will attempt to do.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ram Mohan R (rmohanr)
> Sent: 18 July 2011 15:27
> To: Leon Portman; [email-masked]
> Subject: [siprec] Comments on draft-portman-siprec-protocol-05
> 
> Leon et all,
> 

I had the same comment I think this statement should be removed.

> Again can you please clarify how this is done ?

I don't think this is relevant to this document probably more applicable to the metadata.

> 3)I would suggest to have only new definitions on Section 2. In case
> you still want to retain them please make them consistent.  I see some

Personally I think the architecture draft should be the master regarding definitions as this defines the architecture and therefore the entities involved.

> it is better to not mention this text.

I agree.

> You may want to re-word this sentence to make it more clearer.
> Something like this:

I agree the text does not seem to make much sense to me your suggestion is better.

> was agreed earlier that direction value is not possible to be
> determined at all times and hence we may send it as extension data.
> IMO this needs some more discussion before acceptance. As John
> mentioned in another thread, we have not had much discussion on this
> either before.
> 
> 10) Section 6.1

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 18 Jul 2011 10:13:22 -0700

Please see inline.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
> Sent: Monday, July 18, 2011 8:47 AM
> To: Ram Mohan R (rmohanr); Leon Portman; [email-masked]
> Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05
> 
> Hi Ram,
> 
> Personally I think the architecture draft should be the master regarding definitions as this defines
> the architecture and therefore the entities involved.

I prefer this approach as well. Note, this is the approach taken by draft-eckel-siprec-rtp-rec as well.

Cheers,
Charles

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

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 19 Jul 2011 12:33:48 +0530

Hi Andy,

Thanks for your responses. A  comment on the below response.

> applicable to the metadata.

Are you suggesting to have something in metadata for version management ?  Why do we need it ?

Regards,
Ram

> From: Hutton, Andrew [mailto:[email-masked]]
> Sent: Monday, July 18, 2011 9:17 PM
> Subject: RE: Comments on draft-portman-siprec-protocol-05
> 
> Hi Ram,
> 
> Personally I think the architecture draft should be the master
> regarding definitions as this defines the architecture and therefore
> the entities involved.
> 
>

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 20 Jul 2011 20:00:45 -0700

Please see inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Monday, July 18, 2011 11:47 AM
To: Ram Mohan R (rmohanr); Leon Portman; [email-masked]
Subject: Re: [siprec] Comments on draft-portman-siprec-protocol-05

Hi Ram,

Regards
Andy

[hlum] I don't think minimizing the size of the SIP message is a design goal anymore. Let's remove this.

[hlum] Agreed - looks like the protocol draft does not contain anything that requires versioning of the protocol at all. Let's remove it. 

[hlum] I haven't updated this section to sync with the definitions in the requirements draft. I am okay with referencing either the requirements document or the architecture document, which one should we use?

> an impression that it may be the only way RS may be setup.

[hlum] Okay I will add a note to clarify. 

I agree.

[hlum] I don't see how the metadata format is currently tied to SIP; the model and the XML has no direct reference to SIP elements. In fact, REQ-014 says that the metadata format must be agnostic to the transport protocol so we are obliged to make the format work for non-SIP transports. However, I would agree to remove this text since this document focuses on SIP extensions.

> recording each stream independently.

[hlum] Each m= line represents a separate stream from the SRC so I am not sure what you mean here.

> we need anything else in metadata or in protocol ?

[hlum] If it is a mixed stream then the metadata needs to provide the changes to participants; there isn't must the protocol needs to specify. On the other hand, if the SRC is not mixing the media but multiplexing media from participants, then I guess the SRS would receive RTP packets from another contributing source; and I don't see a need to send reINVITE to re-negotiate SDP.

[hlum] Thanks for catching this. 

> determined at all times and hence we may send it as extension data.

[hlum] Okay, I will remove direction from the sentence.

> what is call identifier here ?

[hlum] that would be participant AOR according to the latest metadata draft.

> mentioned in another thread, we have not had much discussion on this
[hlum] There is a thread going on now. I think we are agreeing on a simple mechanism which is the intent of this section. Will need to work on the wording a little but to clarify the intent.

> SRC to start/stop recording.

[hlum] Updating the last sentence:

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

> absence of this SDP attribute itself says that a UA has no preference.
[hlum] We did have discussion about this, and it seems like we don't have strong opinions having or not having this value. I can see that it would be useful for a recording aware UA to be explicit about having no preference than no specifying at all.

-------------------------------------------------------------------------------------------------------------------
CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 21 Jul 2011 11:13:45 +0530

Hi Henry,

Thanks for your responses. Please see inline for [Ram]

> From: Henry Lum [mailto:[email-masked]]
> Sent: Thursday, July 21, 2011 8:31 AM
> To: Hutton, Andrew; Ram Mohan R (rmohanr); Leon Portman;
> [email-masked]
> Subject: RE: [siprec] Comments on draft-portman-siprec-protocol-05
> 
> Please see inline.
> 
> Behalf Of Hutton, Andrew
> [hlum] Agreed - looks like the protocol draft does not contain anything
> that requires versioning of the protocol at all. Let's remove it.
> 
> [hlum] I haven't updated this section to sync with the definitions in
> the requirements draft. I am okay with referencing either the
> requirements document or the architecture document, which one should we
> use?

IMO we can use architecture draft. I see even the draft put up by Charles does the same.

> [hlum] I don't see how the metadata format is currently tied to SIP;
> the model and the XML has no direct reference to SIP elements. In fact,
> REQ-014 says that the metadata format must be agnostic to the transport
> protocol so we are obliged to make the format work for non-SIP
> transports. However, I would agree to remove this text since this
> document focuses on SIP extensions.

[Ram] Please note that the current metadata schema has information like <label> which points to SDP label. In that way it is closed tied to SIP/SDP. 

> not sure what you mean here.

[Ram] I get your point now.  Please ignore this comment.

> [hlum] If it is a mixed stream then the metadata needs to provide the
> changes to participants; there isn't must the protocol needs to
> specify. On the other hand, if the SRC is not mixing the media but
> multiplexing media from participants, then I guess the SRS would
> receive RTP packets from another contributing source; and I don't see a
> need to send reINVITE to re-negotiate SDP.

[Ram] Agreed. Metadata currently provides which all participants contributed to a MS by <send> tag. In case multiple participants has <send> tag with the same MS ID it means the MS is a mixed stream (sent from SRC) contributed by all those participants.
Now regarding the case of SRC doing multiplexing ( of RTP and RTCP or SSRC, we can use the CSRC/SSRC in RS SDP to indicate the same.
IMO here we will need to incorporate some of the text from Charles draft for this.

Regards,
Ram

> [hlum] There is a thread going on now. I think we are agreeing on a
> simple mechanism which is the intent of this section. Will need to work
> on the wording a little but to clarify the intent.
> 
> > 10) Section 6.1
>    recording and is not used as a request to start/stop recording if
> there are multiple SRCs in the call path."
> 
> >
> > 11) Section 6.3
> [hlum] We did have discussion about this, and it seems like we don't
> have strong opinions having or not having this value. I can see that it
> would be useful for a recording aware UA to be explicit about having no
> preference than no specifying at all.
> 
> 
> > Regards,
> > Ram
> >
> >
> >
> 
> -----------------------------------------------------------------------
> --------------------------------------------
> CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain
> confidential and proprietary information of Alcatel-Lucent and/or its
> affiliated entities. Access by the intended recipient only is
> authorized. Any liability arising from any party acting, or refraining
> from acting, on any information contained in this e-mail is hereby
> excluded. If you are not the intended recipient, please notify the
> sender immediately, destroy the original transmission and its
> attachments and do not disclose the contents to any other person, use
> it for any purpose, or store or copy the information in any medium.
> Copyright in this e-mail and any attachments belongs to Alcatel-Lucent
> and/or its affiliated entities.
>

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 21 Jul 2011 07:02:43 -0700

> document focuses on SIP extensions.

[Ram] Please note that the current metadata schema has information like
<label> which points to SDP label. In that way it is closed tied to
SIP/SDP. 

[hlum] I don't think it's necessarily a strong tie since the SDP a=label
and the metadata Media Stream Reference is just a pair of matching
string. The metadata document and the protocol document are just
mandating that when metadata is transported over a SIP recording
session, we would only refer to the a=label of a media stream. If the
metadata is transported over other protocol, then the Media Stream
Reference can refer to something else in that protocol.