Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 1 Oct 2012 12:49:25 +0000

Hi Raj,

See below.

Regards
Andy (SIPREC Co-Chair)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Jain, Rajnish
> Sent: 27 September 2012 20:24
> To: [email-masked]
> Subject: [siprec] Comments on draft-ietf-siprec-protocol-06
> 
> Pls. find below some of my questions and comments on the draft-ietf-
> siprec-protocol-06 document (I apologize if these have been addressed
> earlier; pls. point me to mailing list discussions if these have been
> already been addressed).
> 
> Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2:
> ---------------------------------------------------------------------
> 

We had a lot of discussion in the working group regarding the mechanism for transporting meta-data and I believe had strong consensus to go with the current model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request a snapshot. The reasons for this was at least partly due to the fact that the SDP in the RS forms part of the metadata and there has to be direct linkage between the RS SDP and metadata so conveying it within the same request and dialog was logical and simplifies the solution.

Unless we have discovered that the mechanism currently specified is broken then I don't think we need to restart the debate on this issue.

> The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE-
> INVITE or UPDATE for conveying metadata from the SRC to the SRS. This
> may have been discussed in SIPREC WG earlier, but the choice of these
> methods for delivering metadata seems counterintuitive. This choice
> certainly misses some use cases.
> 
> IMHO, the metadata information flow seems to better fit a
> SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of
> RS session management (such as adding and removing media streams) from
> metadata event communication. These two protocol communications are
> somewhat independent. For example, the RS session management will tend
> to be real-time with SDP changes back-and-forth to avoid clipping of
> media. The metadata events are less real-time demanding because they
> can be correlated with the recorded media as long as the timestamps
> between the two flows are synchronized. For these reasons, the metadata
> generation/consumption logic may exist in different processing units in
> the SRC/SRC as compared to the RS session management and RTP media
> handling. This is one of the reasons why the SIPREC protocol allows for
> a non-SIP mechanism delivery of metadata even though it is out of scope
> of SIPREC (section 4).
> 
> The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of
> these requirements. In particular, use case 4 in RFC 6341 describes a
> scenario where the RS exists longer than a CS. As a practical
> implementation of this use case, the SRC sends a metadata event to the
> SRS indicating a user logon (note that this means that metadata events
> span a user logon lifespan and not just the CS lifespan) when the user
> initially logs on but hasn't participated in a CS at this point.
> Depending on the capacity available at the SRS, the logon event
> triggers an INVITE from the SRS to the SRS to establish the RS. The
> logon event is delivered through a subscription that the SRS has
> previously established with the SRC. Such a message flow prevents
> clipping of the initial media samples from being recorded, which is the
> case when CS and RS are racing to establish at the same time. There are
> also use cases around push-to-talk where metadata events are required
> but turning RTP on and off thro
>  ugh SDP exchange (sendonly, inactive) is expensive and more prone to
> media clipping.
> 
> In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS
> for the metadata events. The SRC will push metadata events to the SRS
> as the CS undergoes state changes (initiation, teardown, hold/resume
> etc.) or when the user state that is targeted for recording undergoes
> changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in
> bootstrapping of the SRS state where the SRS recovers after a failure
> (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of
> the recording metadata; there may also be historical CS information in
> this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS
> to SRC (as shown in Figure 2) seems counterintuitive to the usage of
> the UPDATE method (why and what is the SRS updating the SRC about the
> RS for?). A SUBSCRIBE will always fetch the current state as per the
> definition.
> 
> 
> Indicating recording preference in SDP (a=record, a=recordpref),
> Section 5.3:
> -----------------------------------------------------------------------
> ------
> 
> The notion that a CS is being recorded or not seems more like a SIP-
> level construct (or maybe a metadata-level construct) as opposed to an
> SDP-level context. 

Since the indication/preference is on a media line basis then I don't know where else we could put it.

> Are these attributes really describing some
> characteristic about the media being carried in the RS RTP (described
> by SDP) or are they describing an RS characteristic itself? When an RS
> carries multiple CSes, I'm assuming that the metadata will uniquely
> identify each media stream in the RS (e.g. the SDP a=label token will
> also be present in the metadata in some form) and so such attributes
> can be placed in the metadata.
> 
> In section 5.3, if the SRC chooses to ignore SRS' request to turn off
> recording, how does the SRS learn about that and what should the SRS do
> if it continues to receive media from the SRC?

These indications apply to the CS not the RS so they don't impact the SRS at all.

> 
> 
> Section 6.1, '+sip.rec' and 'siprec' tags':
> -------------------------------------------
> 
> Section 6.1 states:
> 
>    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.
> 
> The purpose of the Contact URI tags '+sip.src' and '+sip.srs' is not
> very clear from the description. They don't seem to be helping with the
> negotiating aspect of the recording feature and the SRS /SRS
> communication may not be through a proxy server (which has access to a
> registrar's location service).

They are there to help ensure that things run smoothly and that it is clear who is taking which role. An SRS for example will use this to make sure that an INVITE is from an SRC. The use in REGISTER is again only to help identify SRC's and will not be useful in some scenarios.

> The notion of an SRC registering using
> the REGISTER method is also not very clear (e.g. when the SRC is an
> SBC, does it register as a UA with a registrar)?

As usual SBC behavior is not well defined and SIPREC is no different here an SBC could I guess add the SRC indication to a REGISTER requests it forwards if it is going to act as a SRC on behalf of a UA but I don't think we need to say anything on that.

> 
> These Contact URI tags seem to overlap with the 'siprec' tag. Why does
> an SRC or SRS must ensure that either one of these Contact URI tags
> (depending on the direction of the INVITE) AND the 'siprec' tag must be
> present in the RS INVITE?

The "siprec" option tag is carried in the Require header so that if the INVITE finds its way to a non SIPREC aware UA then the INVITE will be rejected.

> 
> 
> Section 7.1, Scope of a=label:
> ------------------------------
> 
> I think the following statement in section 7.1 could be clarified (I
> think this means that the label can be reused after the previous stream
> with that label is no longer active):
> 
>    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.
> 
> 

I agree this could be made a bit clearer it really means that the scope of the label is limited to the SDP and SIPREC Metadata conveyed in the bodies of a single SIP Request/Response.

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

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 1 Oct 2012 08:19:59 -0700

Hi Raj, 

Thanks for the review, please see inline.

Henry

> From: [email-masked] [mailto:[email-masked]] On
Behalf Of
> Hutton, Andrew
> Sent: October-01-12 8:49 AM
> To: Jain, Rajnish; [email-masked]
> Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06
> 
> Hi Raj,
> 
> See below.
> 
> Regards
> Andy (SIPREC Co-Chair)
> 
> 
> >
> 
> We had a lot of discussion in the working group regarding the
mechanism for
> transporting meta-data and I believe had strong consensus to go with
the
> current model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to
request a
> snapshot. The reasons for this was at least partly due to the fact
that the
> SDP in the RS forms part of the metadata and there has to be direct
linkage
> between the RS SDP and metadata so conveying it within the same
request and
> dialog was logical and simplifies the solution.
> 
> Unless we have discovered that the mechanism currently specified is
broken
> then I don't think we need to restart the debate on this issue.
> 
> 
> Since the indication/preference is on a media line basis then I don't
know
> where else we could put it.
> 
[Henry] Yes, we want to indicate whether you are being recorded for each
media line (ie. audio only but not video) so SDP is the best place to
indicate this.

> These indications apply to the CS not the RS so they don't impact the
SRS at
> all.

[Henry] Right, the SRS does not use these SDP attributes so they don't
impact the SRS. If the SRS don't want to be recorded, then it can simply
reject the RS or just terminate the RS.
These attributes apply to a recording-aware participant in a CS. The
participants set the recording preference and the participants will
learn whether the participant is being recorded or not through the
indication. The SRC must send indication to the participant so the
participant will always get the up to date indication, and if the
participant does not like being recorded or the call needs to be
recorded and it's not, then it's up to the participant to abandon the
call or take alternative action.

> They are there to help ensure that things run smoothly and that it is
clear
> who is taking which role. An SRS for example will use this to make
sure that
> an INVITE is from an SRC. The use in REGISTER is again only to help
identify
> SRC's and will not be useful in some scenarios.
> 
> 
> As usual SBC behavior is not well defined and SIPREC is no different
here an
> SBC could I guess add the SRC indication to a REGISTER requests it
forwards if
> it is going to act as a SRC on behalf of a UA but I don't think we
need to say
> anything on that.
> The "siprec" option tag is carried in the Require header so that if
the INVITE
> finds its way to a non SIPREC aware UA then the INVITE will be
rejected.

[Henry] The +sip.src tag can also appear in the CS to indicate to the
participants that an SRC is in the call.

> I agree this could be made a bit clearer it really means that the
scope of the
> label is limited to the SDP and SIPREC Metadata conveyed in the bodies
of a
> single SIP Request/Response.

[Henry] Let's rewrite this as:

The scope of the a=label attribute only applies to the SDP and Metadata
conveyed
in the bodies of the SIP request or response that the label appeared in.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 01 Oct 2012 17:40:35 -0400

I concur with what Andrew and Henry said.
In addition I have one other comment:

On 9/27/12 3:23 PM, Jain, Rajnish wrote:
> Pls. find below some of my questions and comments on the draft-ietf-siprec-protocol-06 document (I apologize if these have been addressed earlier; pls. point me to mailing list discussions if these have been already been addressed).
>
> The SIPREC protocol draft section 5.2 suggests the use of INVITE, RE-INVITE or UPDATE for conveying metadata from the SRC to the SRS. This may have been discussed in SIPREC WG earlier, but the choice of these methods for delivering metadata seems counterintuitive. This choice certainly misses some use cases.
>
> IMHO, the metadata information flow seems to better fit a SUBSCRIBE/NOTIFY mechanism. The protocol should allow for decoupling of RS session management (such as adding and removing media streams) from metadata event communication. These two protocol communications are somewhat independent. For example, the RS session management will tend to be real-time with SDP changes back-and-forth to avoid clipping of media. The metadata events are less real-time demanding because they can be correlated with the recorded media as long as the timestamps between the two flows are synchronized. For these reasons, the metadata generation/consumption logic may exist in different processing units in the SRC/SRC as compared to the RS session management and RTP media handling. This is one of the reasons why the SIPREC protocol allows for a non-SIP mechanism delivery of metadata even though it is out of scope of SIPREC (section 4).
>
> The CS/RS lifecycle diagrams in section 4 in RFC 6341 highlight some of these requirements. In particular, use case 4 in RFC 6341 describes a scenario where the RS exists longer than a CS. As a practical implementation of this use case, the SRC sends a metadata event to the SRS indicating a user logon (note that this means that metadata events span a user logon lifespan and not just the CS lifespan) when the user initially logs on but hasn't participated in a CS at this point. Depending on the capacity available at the SRS, the logon event triggers an INVITE from the SRS to the SRS to establish the RS. The logon event is delivered through a subscription that the SRS has previously established with the SRC. Such a message flow prevents clipping of the initial media samples from being recorded, which is the case when CS and RS are racing to establish at the same time. There are also use cases around push-to-talk where metadata events are required but turning RTP on and off th
 ro
>   ugh SDP exchange (sendonly, inactive) is expensive and more prone to media clipping.
>
> In the SUBSCRIBE/NOTIFY mechanism, the SRC will subscribe to the SRS for the metadata events. The SRC will push metadata events to the SRS as the CS undergoes state changes (initiation, teardown, hold/resume etc.) or when the user state that is targeted for recording undergoes changes. The SUBSCRIBE/NOTIFY mechanism also allows for built in bootstrapping of the SRS state where the SRS recovers after a failure (the first NOTIFY to the SUBSCRIBE will carry the current snapshot of the recording metadata; there may also be historical CS information in this NOTIFY). Sending an UPDATE for a 'media snapshot request' from SRS to SRC (as shown in Figure 2) seems counterintuitive to the usage of the UPDATE method (why and what is the SRS updating the SRC about the RS for?). A SUBSCRIBE will always fetch the current state as per the definition.

One concern was for the speed of establishing an RS and getting going 
with recording. Being able to put metadata into the INVITE means that 
the SRS can have everything it needs to start recording immediately.

Also, comments at this level would have been more practical to consider 
a couple of years ago when we were getting started on this work. At this 
point it is really too late to consider major architectural changes 
unless there is some severe malfunction in what we have.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 3 Oct 2012 05:32:46 +0000

> On 02/10/12 3:10 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> Pls. find below some of my questions and comments on the
>>draft-ietf-siprec-protocol-06 document (I apologize if these have been
>>addressed earlier; pls. point me to mailing list discussions if these
>>have been already been addressed).
>>
>> The SIPREC protocol draft section 5.2 suggests the use of INVITE,
>>RE-INVITE or UPDATE for conveying metadata from the SRC to the SRS. This
>>media. The metadata events are less real-time demanding because they can
>>be correlated with the recorded media as long as the timestamps between
>>the two flows are synchronized. For these reasons, the metadata
>>Depending on the capacity available at the SRS, the logon event triggers
>>an INVITE from the SRS to the SRS to establish the RS. The logon event
>>is delivered through a subscription that the SRS has previously
>>established with the SRC. Such a message flow prevents clipping of the
>>initial media samples from being recorded, which is the case when CS and
>>RS are racing to establish at the same time. There are also use cases
>>around push-to-talk where metadata events are required but turning RTP
>>on and off th
> ro
>>for the metadata events. The SRC will push metadata events to the SRS as
>>the CS undergoes state changes (initiation, teardown, hold/resume etc.)
>>or when the user state that is targeted for recording undergoes changes.
>>The SUBSCRIBE/NOTIFY mechanism also allows for built in bootstrapping of
>>the SRS state where the SRS recovers after a failure (the first NOTIFY
>>to the SUBSCRIBE will carry the current snapshot of the recording
>>metadata; there may also be historical CS information in this NOTIFY).
>>Sending an UPDATE for a 'media snapshot request' from SRS to SRC (as
>>shown in Figure 2) seems counterintuitive to the usage of the UPDATE
>>method (why and what is the SRS updating the SRC about the RS for?). A
>>SUBSCRIBE will always fetch the current state as per the definition.
>

+1. I also agree with Paul and others here. SUB/NOT is some thing that was
discussed 2 years back and after a lot of discussions it was agreed that
INVITE based approach is the best one for SIPREC.

Ram

---

From: "Jain, Rajnish" <[email-masked]>
Date: Wed, 3 Oct 2012 13:13:51 +0000

Hi Andy,

[rj] Understand. Sorry I couldn't participate in the protocol design discussions earlier. I understand that this may be too late to bring up.

[rj] Just as a data point, we've currently in production an SRC system where the metadata is carried by non-SIP means (the RS is established using SIP). The metadata is generated by a non-real-time part of the system (later correlated with the RS in the SRS), whereas, the RS SIP session initiation is done by a real-time part of the system. Many of these design choices were made to alleviate clipping of the recording media (a critical requirement for us). I think this is typical in the industry because call metadata is generally conveyed over the CDR/CTI interfaces (we've extended ECMA CSTA-WS for this). We could have envisioned adopting the SIPREC metadata XML and transporting it in SUB/NOTIFY. 

[rj] Ok. That makes sense.

> Are these attributes really describing some characteristic about the 
> media being carried in the RS RTP (described by SDP) or are they 
> describing an RS characteristic itself? When an RS carries multiple 
> CSes, I'm assuming that the metadata will uniquely identify each media 
> stream in the RS (e.g. the SDP a=label token will also be present in 
> the metadata in some form) and so such attributes can be placed in the 
> metadata.
> 
> recording, how does the SRS learn about that and what should the SRS 
> do if it continues to receive media from the SRC?

[rj] Ok. That makes sense.

> very clear from the description. They don't seem to be helping with 
> the negotiating aspect of the recording feature and the SRS /SRS 

[rj] Ok.

Regards,

Raj Jain

---

From: "Simon Farrow" <[email-masked]>
Date: Wed, 3 Oct 2012 10:42:05 -0700

Will SIPREC support SIP MESSAGE (RFC 3428) and MSRP (RFC 4975). There should
be no impact supporting RFC 4103 payload for Text Conversation, is that a
correct assumption.

Simon Farrow
Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704
http://www.stancilcorp.com
[email-masked]
714-546-2002 ext 4311

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 3 Oct 2012 23:38:54 +0530

Hi Rajnish,

The current SIPREC architecture provides persistent RS recording to avoid
the initial clipping. In fact, there is no mandate to send SIPREC metadata
in the first RS message (INVITE) wherein SIPREC metadata shall be included
in persistent RS once the CS is established in SRC. 

The advantage of current SIPREC mechanism is that 
1) There is no need of external interfaces like CTI for recording. 
2) Extra dialog (SUBSCRIBE/NOTIFY) is not required to be established between
SRC and SRS to pass metadata. Please note that the metadata in SIPREC is
specific to CS related info in real-time and other recording metadata is
considered as outside the scope of SIPREC.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jain, Rajnish
Sent: Wednesday, October 03, 2012 6:44 PM
To: Hutton, Andrew; [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-protocol-06

Hi Andy,

> Carrying Recording Metadata through RE-INVITE or UPDATE, Section 5.2:

We had a lot of discussion in the working group regarding the mechanism for
transporting meta-data and I believe had strong consensus to go with the
current model using INVITE/RE-INVITE/UPDATE and the use of UPDATE to request
a snapshot. The reasons for this was at least partly due to the fact that
the SDP in the RS forms part of the metadata and there has to be direct
linkage between the RS SDP and metadata so conveying it within the same
request and dialog was logical and simplifies the solution.

Unless we have discovered that the mechanism currently specified is broken
then I don't think we need to restart the debate on this issue.

[rj] Understand. Sorry I couldn't participate in the protocol design
discussions earlier. I understand that this may be too late to bring up.

[rj] Just as a data point, we've currently in production an SRC system where
the metadata is carried by non-SIP means (the RS is established using SIP).
The metadata is generated by a non-real-time part of the system (later
correlated with the RS in the SRS), whereas, the RS SIP session initiation
is done by a real-time part of the system. Many of these design choices were
made to alleviate clipping of the recording media (a critical requirement
for us). I think this is typical in the industry because call metadata is
generally conveyed over the CDR/CTI interfaces (we've extended ECMA CSTA-WS
for this). We could have envisioned adopting the SIPREC metadata XML and
transporting it in SUB/NOTIFY. 

> Indicating recording preference in SDP (a=record, a=recordpref), 

Since the indication/preference is on a media line basis then I don't know
where else we could put it.

> do if it continues to receive media from the SRC?

These indications apply to the CS not the RS so they don't impact the SRS at
all.

> Section 6.1, '+sip.rec' and 'siprec' tags':

They are there to help ensure that things run smoothly and that it is clear
who is taking which role. An SRS for example will use this to make sure that
an INVITE is from an SRC. The use in REGISTER is again only to help identify
SRC's and will not be useful in some scenarios.

[rj] Ok.

Regards,

Raj Jain

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Oct 2012 14:52:11 -0400

> be no impact supporting RFC 4103 payload for Text Conversation, is that a

We did not explicitly address any of these. (We were trying to bound the 
scope of the effort.) However:

- everything should be there to support RFC 4103, since it's also RTP.

- implementations could probably support recording of MSRP in the spirit
   of what is there, and maybe successfully interoperate. But to be
   certain there would need to be a followon effort to investigate what
   issues might arise.

- Supporting MESSAGE raises all sorts of potential issues. Do you mean
   individual MESSAGE requests (page-mode, sessionless)?
   Or do you mean dialogs containing multiple MESSAGEs? (That usage is
   not sanctioned.)

	Thanks,
	Paul

---

From: "Simon Farrow" <[email-masked]>
Date: Thu, 4 Oct 2012 12:10:25 -0700

Paul

Thank you for your reply. I understand the points regarding RFC 4103 and
MSRP and agree with your assessments.

To answer your question with regards to MESSAGE. I was only considering
individual messages which has useful associated metadata to them. (e.g.
participants, who typed it, when etc). It would be up to the SRS client on
how to display them for the user.

Thanks,
Simon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Thursday, October 04, 2012 11:52 AM
To: [email-masked]
Subject: Re: [siprec] RFC 3428, RFC 4975 and RFC 4103

On 10/3/12 1:42 PM, Simon Farrow wrote:
>
> Will SIPREC support SIP MESSAGE (RFC 3428) and MSRP (RFC 4975). There 
> should be no impact supporting RFC 4103 payload for Text Conversation, 
> is that a correct assumption.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 04 Oct 2012 15:53:10 -0400

> how to display them for the user.

OK. For single MESSAGEs I think we would need to do extension work.
My thought is that it would be recorded as metadata-only. But the 
details need to be worked out.

If these things are important to you then they should be added to the 
list of desired extension work that we *ought* to be collecting.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 5 Oct 2012 15:39:53 +0000

Hi,

Regarding RFC 4103 then this it is one of our requirements to support the recording of this media type see below the text in RFC 6341 (SIPREC Requirements). I am not aware of any reason why this would not work in the current solution. If anybody see's a problem please let us know.

   o  REQ-007: The mechanism MUST support the recording of the following
      RTP media types: voice, DTMF (as defined by [RFC4733]), video, and
      text (as defined by [RFC4103])

Regarding the recording of MSRP or SIP MESSAGE then as Paul stated this was not covered by our requirements and has not been discussed in the group. I am sure we could build this in as an extension if people have requirements but it would not be covered by the existing drafts.

Regards
Andy

> Behalf Of Paul Kyzivat
> Sent: 04 October 2012 20:53
> To: [email-masked]
> Cc: [email-masked]