Subject: [siprec] Is SIPREC metadata mandatory to implement?

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 9 Feb 2012 18:04:32 +0100

Hi All,

I am not sure we have ever addressed the question of whether a minimum SIPREC implementation could exist without any metadata being passed between the SRC and SRS.  

The way the protocol draft for example is written appears to make at least some metadata mandatory for example section 6.1 states:

"The SRC MUST provide a label attribute (a=label), as per [RFC4574], on each media stream in order to identify the recorded stream with the rest of the metadata".

Making it mandatory for the SRC to at least use the label attribute in SDP.

I this what we want?

Regards
Andy (SIPREC co-chair).

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Feb 2012 15:34:44 -0500

> Making it mandatory for the SRC to at least use the label attribute in SDP.

I think so. Its hard to imagine the utility of siprec without some 
metadata. The recorder can receive some media but has absolutely no 
context regarding what it means, other than perhaps From. The usage 
would be proprietary.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 10 Feb 2012 16:10:25 +0100

In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the SRC then maybe all that is needed is the from header to identify the endpoint and the time which the SRS can get for itself.

In this case the metadata body would not be needed and it would not make sense to include a label in the SDP.

In anything more complex I agree metadata is needed.

The question is whether this simplest case is within scope and I tend to think it is but interested in hearing more opinions.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 09 February 2012 20:35
> To: [email-masked]
> Subject: Re: [siprec] Is SIPREC metadata mandatory to implement?
> 
> > I am not sure we have ever addressed the question of whether a
> minimum SIPREC implementation could exist without any metadata being
> passed between the SRC and SRS.
> >
> > The way the protocol draft for example is written appears to make at
> least some metadata mandatory for example section 6.1 states:
> >
> > "The SRC MUST provide a label attribute (a=label), as per [RFC4574],
> on each media stream in order to identify the recorded stream with the
> rest of the metadata".
> >
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Feb 2012 10:48:37 -0500

> The question is whether this simplest case is within scope and I tend to think it is but interested in hearing more opinions.

I think you are suggesting an SRS that gets a connection from an SRC 
without metadata should infer some default metadata based on other 
information in the message.

If that is what we want, then we should say that, and spell out what 
inferences should be made. If we don't do that, then different SRSs are 
likely to make different inferences (or none), resulting in interop issues.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Sat, 11 Feb 2012 15:05:14 +0000

Hi Andy,

>From header in RS indicates SIP endpoint which acts as SRC but how to represent the remote endpoint in this scenario because TO header indicates SRS. 

Also, your mail indicates the dependency on "Date" header in RS right?

Thanks
Partha

>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Hutton, Andrew
>Sent: Friday, February 10, 2012 8:40 PM
>To: Paul Kyzivat; [email-masked]
>In the simplest case of a SIP endpoint (E.g. SIP Phone) acting as the
>SRC then maybe all that is needed is the from header to identify the
>endpoint and the time which the SRS can get for itself.
>
>The question is whether this simplest case is within scope and I tend to
>think it is but interested in hearing more opinions.
>
>Regards
>Andy
>
>
>

---

From: "Henry Lum" <[email-masked]>
Date: Mon, 13 Feb 2012 07:57:37 -0800

On a similar note, I am wondering if we can allow recording sessions
that carry metadata only. Since it's a SIP dialog, we still need to
negotiate an SDP offer/answer, but with no m= lines in the SDP.

Henry

> Behalf Of Hutton, Andrew
> Sent: February-09-12 12:05 PM
> To: [email-masked]
> Subject: [siprec] Is SIPREC metadata mandatory to implement?
> 
> Hi All,
> 
> I am not sure we have ever addressed the question of whether a minimum
> SIPREC implementation could exist without any metadata being passed
> between the SRC and SRS.
> 
on
> each media stream in order to identify the recorded stream with the
> rest of the metadata".
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Feb 2012 13:01:10 -0500

> negotiate an SDP offer/answer, but with no m= lines in the SDP.

I don't see why not.

I can certainly see that an RS might be *established* with metadata but 
no media, because there is at that time no media to record. But at some 
later time media might be added to it.

The degenerate case is that there is never any media. That seems pretty 
uninteresting, but perhaps not forbidden.

And I guess the flip side of that is an RS with (initially) no metadata. 
That might be sent later, but if it isn't, then I suppose the SRS needs 
to cope. As I mentioned before, we should try to say something about 
what the SRS should infer from other info in the dialog in the absence 
of metadata.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 14 Feb 2012 07:21:53 +0000

Paul,

I agree with you for RS with metadata but no media and also RS without metadata initially.

Hi All,

In case there is no metadata from SRC, Some of the possible inferring details in SRS based on RS dialog are 

1) originating participant (From header).
2) Date & Time (Date header)
3) Call-id  (Unique-id)

Even though the simple "no metadata" approach reduce the complexity in SRC, The issue is that SRS MUST support both SIP headers (RS) based metadata as well as XML based metadata. IMO, it is preferred not to have two ways to represent the same metadata within RS.

Thanks
Partha

>Of Paul Kyzivat
>Sent: Monday, February 13, 2012 11:31 PM
>To: [email-masked]

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Feb 2012 11:10:34 +0100

Hi All,

Ok I can see there are times when we might have metadata but no media but we need to be careful about the use cases for this as long as this supports some recording use cases in which there is an intention to record the media we are probably ok but we must be careful not to start down the path of a general purpose CTI type interface.

Both the case of media without metadata and metadata without media need to be clearly described in the architecture and protocol drafts.

I am not convinced that we need to go down the path of stating what headers in the RS can/should be used if there is no metadata.

Regards
Andy

> Behalf Of Ravindran, Parthasarathi
> Sent: 14 February 2012 07:22
> Even though the simple "no metadata" approach reduce the complexity in
> SRC, The issue is that SRS MUST support both SIP headers (RS) based
> metadata as well as XML based metadata. IMO, it is preferred not to
> have two ways to represent the same metadata within RS.
> 
> Thanks
> Partha
> 
> Behalf

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Feb 2012 11:19:24 +0100

See below.

My thinking is that we don't need to say anything about the use of RS headers as metadata.

Regards
Andy

> From: Ravindran, Parthasarathi [mailto:[email-masked]]
> Sent: 11 February 2012 15:05
> To: Hutton, Andrew; Paul Kyzivat; [email-masked]
> Subject: RE: [siprec] Is SIPREC metadata mandatory to implement?
> 
> Hi Andy,
> 
> From header in RS indicates SIP endpoint which acts as SRC but how to
> represent the remote endpoint in this scenario because TO header
> indicates SRS.

[AndyH] - I assume that if the application needed this then it would need to implement the metadata.

> Also, your mail indicates the dependency on "Date" header in RS right?

[AndyH] Not really but I agree it could be used. 

> >In this case the metadata body would not be needed and it would not
> make
> >sense to include a label in the SDP.
> >
> >> > Making it mandatory for the SRC to at least use the label
> attribute
> >> in SDP.
> >> >
> >> > I this what we want?
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2012 10:11:26 -0500

> Ok I can see there are times when we might have metadata but no media but we need to be careful about the use cases for this as long as this supports some recording use cases in which there is an i…

I agree with not wanting to turn this into CTI.

> I am not convinced that we need to go down the path of stating what headers in the RS can/should be used if there is no metadata.

I guess it isn't *necessary* to specify that. But there are consequences 
to not doing so:

An SRC may have been getting acceptable results not specifying metadata. 
Then the SRS gets replaced with a different one and results are no 
longer acceptable because the new one doesn't infer things the same way.

	Thanks,
	Paul

---

From: Leon Portman <[email-masked]>
Date: Tue, 14 Feb 2012 18:21:06 +0200

Couple of comments.

Today main use cases for CTI interface are two:
1. receive information about calls for reporting/billing/recording etc - I think we cover it very well
2. third party call control  - out of scope of SIPREC

I agree that custom headers in RS is a bad idea.

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, February 14, 2012 5:11 PM
To: Hutton, Andrew
Cc: [email-masked]
Subject: Re: [siprec] Is SIPREC metadata mandatory to implement?

> I am not convinced that we need to go down the path of stating what headers in the RS can/should be used if there is no metadata.

I guess it isn't *necessary* to specify that. But there are consequences to not doing so:

An SRC may have been getting acceptable results not specifying metadata. 
Then the SRS gets replaced with a different one and results are no longer acceptable because the new one doesn't infer things the same way.

	Thanks,
	Paul

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 14 Feb 2012 18:59:33 +0100

> longer acceptable because the new one doesn't infer things the same

I think we can live with this if metadata is really important to a solution then the SRC will need to generate SIPREC metadata.

Regards
Andy

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Feb 2012 14:06:12 -0500

> I think we can live with this if metadata is really important to a solution then the SRC will need to generate SIPREC metadata.

Maybe. But there is a big hurdle between not supplied metadata and 
supplying it. If the metadata is optional, then its quite possible that 
you will have SRCs that just aren't capable of doing so. (Most likely 
for some simple cases like a UA that is its own SRC.)

Then you might get locked in to an SRS that handles that case as you 
like. You will start having proprietary islands if SRCs and SRSs that 
can work together.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 14 Feb 2012 11:49:15 -0800

Exploring this a bit further, I think this would define a new option
tag, e.g. siprec-metadata. An SRC/SRS would include it in a Supported
vs. Required header. In the event metadata is not used between the SRC
and SRS, a well documented set of SIP headers could be used to convey
specific information about the recording.
 
I do see some value in this. If we go this route, the next question is,
do you mandate support for this SIP headers AND avoid any overlap
between them and the XML metadata? Or do we say that the XML metadata,
if present, supersedes anything conveyed via the SIP headers? Seeing as
XML metadata is a key part of SIPREC, I would suspect the latter, but I
am interested to hear what others think.

Cheers,
Charles

> Sent: Tuesday, February 14, 2012 11:06 AM
> To: Hutton, Andrew
> Cc: [email-masked]
> > I think we can live with this if metadata is really important to a
> solution then the SRC will need to generate SIPREC metadata.
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 16 Feb 2012 11:51:45 +0530

I see some issues in going with this way:

1) We will end up in having two different metadata mechanisms - one XML
and one headers based

2) The existing SIP headers may not be sufficient to carry even the
basic metadata ( as partha mentioned in his previous e-mail) and if we
are going to add new headers then it is redundant as XML metadata was
just added for that purpose.

3) SRC/SRS needs to negotiate on whether they want to use XML based
metadata (SIPREC metadata) or Header based metadata and this will lead
to more issues some of which you already outlined in the below e-mail

So, I feel it's better to stick with one metadata (XML SIPREC metadata)
and make it mandatory.

What we can add is some guidelines on how SRS has to behave for the
calls where SRC is unable to send metadata or if SRS encounters an SRC
that is not completely compliant with SIPREC standards(say does not
implement metadata).

Regards,
Ram

> Behalf Of Charles Eckel (eckelcu)
> Sent: Wednesday, February 15, 2012 1:19 AM
> To: Paul Kyzivat; Hutton, Andrew
> Cc: [email-masked]
> > >> longer acceptable because the new one doesn't infer things the
> same
> > >> way.
> > >>
> > >

---

From: "John Elwell" <[email-masked]>
Date: Thu, 16 Feb 2012 09:39:51 -0000

I think that XML-based metadata is the essence of SIPREC - other protocol 
additions are peripheral in comparison. We should say that if you don't 
implement and use XML-based metadata you are not SIPREC-compliant. Trying to 
bend SIP header fields to achieve a poor-man's metadata does not make sense, 
particularly as we know that B2BUAs are all too prone to modifying SIP 
header fields.

John

-----Original Message----- 
From: Ram Mohan R (rmohanr)
Sent: Thursday, February 16, 2012 6:21 AM
To: Charles Eckel (eckelcu) ; Paul Kyzivat ; Hutton, Andrew
Cc: [email-masked]
Subject: Re: [siprec] Is SIPREC metadata mandatory to implement?

Regards,
Ram

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 17 Feb 2012 08:38:01 -0800

Hi John,

Good to hear from you, and thanks for keeping us honest on this one. The
potential benefit I see in have the metadata be optional is with respect
to the migration path from pre-SIPREC solutions to SIPREC solutions. In
such cases, the SRCs and UAs within a deployment might add support for
the SIP/SDP extensions and RTP/RTCP recommendations provided by SIPREC,
but the SRC and/or SRS may support the XML metadata. What if we were to
do the following?

siprec option tag: add to existing definition that it means SIPREC
metadata is supported
sip.src and sip.srs feature tags: clarify that it does not imply support
for SIPREC metadata

In this case, the hybrid SRC that I described could still include the
sip.src feature tag in its REGISTER and INVITE requests. It would not
include the siprec option tag as it does not support SIPREC metadata. If
a SIPREC SRS receives such an INVITE, it has the choice of rejecting the
INVTIE or accepting it for the purpose of recording using whatever logic
it used prior to SIPREC.
If the SRC supports metadata but does not require it, it can include the
siprec option tag in a Supported header rather than in a Require header.
The same is true for the SRS.

Cheers,
Charles

> From: John Elwell [mailto:[email-masked]]
> Sent: Thursday, February 16, 2012 1:40 AM
> To: Ram Mohan R (rmohanr); Charles Eckel (eckelcu); Paul Kyzivat;
> Hutton, Andrew
> Cc: [email-masked]
> > XML metadata is a key part of SIPREC, I would suspect the latter,
but
> I

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Fri, 17 Feb 2012 18:28:07 +0000

Hi Charles,

In case some of the SRS has done your proposed SIPREC migration without metadata in the first phase, it will impact SRC SIPREC implementation as SRC is forced to support SRS proprietary metadata and it is one of the major issue today in SIP recording. I wish that it will be solved by SIPREC.

Also, I'm seeing with your argument that most of the existing SIP based proprietary recording are already compliant with SIPREC in case option tag only is added because the option tag shall be added through SIP message configuration in the device (no development required :-)). The requested flexibility in SIPREC provides the opportunity for vendors to stick with pre-SIPREC solution and also, the benefit of IETF SIPREC compliance. Could you please look this issue from the "sake of compliance vendor" perspective.

Thanks
Partha

>Of Charles Eckel (eckelcu)
>Sent: Friday, February 17, 2012 10:08 PM
>To: John Elwell; Ram Mohan R (rmohanr); Paul Kyzivat; Hutton, Andrew
>Cc: [email-masked]
>metadata is supported sip.src and sip.srs feature tags: clarify that it
>does not imply support for SIPREC metadata
>
>> I think that XML-based metadata is the essence of SIPREC - other
>> protocol additions are peripheral in comparison. We should say that if
>> you
>don't
>> bend SIP header fields to achieve a poor-man's metadata does not make
>> sense, particularly as we know that B2BUAs are all too prone to
>> modifying SIP header fields.
>>
>> John
>>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Mon, 20 Feb 2012 14:44:31 -0800

Hi Partha,

Please see inline.

> Sent: Friday, February 17, 2012 10:28 AM
> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R (rmohanr); Paul
> Kyzivat; Hutton, Andrew
> Cc: [email-masked]
> In case some of the SRS has done your proposed SIPREC migration
without
> metadata in the first phase, it will impact SRC SIPREC implementation
> as SRC is forced to support SRS proprietary metadata and it is one of
> the major issue today in SIP recording. I wish that it will be solved
> by SIPREC.
> 
> Also, I'm seeing with your argument that most of the existing SIP
based
> proprietary recording are already compliant with SIPREC in case option
> tag only is added because the option tag shall be added through SIP
> message configuration in the device (no development required :-)). The
> requested flexibility in SIPREC provides the opportunity for vendors
to
> stick with pre-SIPREC solution and also, the benefit of IETF SIPREC
> compliance. Could you please look this issue from the "sake of
> compliance vendor" perspective.

In my proposal, I included the following:

Therefore, including the "siprec" option tag means that the metadata is
supported. I thought this would address your concern. If not, then
perhaps I do not completely understand the issue you are highlighting.

Cheers,
Charles 

> >> > vs. Required header. In the event metadata is not used between
the
> >> SRC
> >> > I do see some value in this. If we go this route, the next
> question
> >> is,
> >> > if present, supersedes anything conveyed via the SIP headers?
> Seeing
> >> as
> >> > > >> An SRC may have been getting acceptable results not
> specifying
> >> > > >> metadata.
> >> > > >> Then the SRS gets replaced with a different one and results
> are
> >> no
> >> > > > I think we can live with this if metadata is really important
> to
> >> a
> >> > > supplying it. If the metadata is optional, then its quite
> possible
> >> > that
> >> > > Then you might get locked in to an SRS that handles that case
as
> >> you
> >> > > like. You will start having proprietary islands if SRCs and
SRSs
> >> that

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Tue, 21 Feb 2012 03:41:56 +0000

Hi Charles,

In case we end up with sip.src contact parameter is the only mandatory for SIPREC compliance, then I would say that Existing Sonus proprietary recording already met SIPREC compliance because adding contact header parameter is a matter of configuration. I'm confident that smart product manager in other companies push for the same level of compliance ;-) This will result in SIPREC compliance with new proprietary headers/body for interop with each recording vendor. I'm worried that those kind SIPREC compliance will not solve the indented problem which we are working for.

Thanks
Partha

>From: Charles Eckel (eckelcu) [mailto:[email-masked]]
>Sent: Tuesday, February 21, 2012 4:15 AM
>To: Ravindran, Parthasarathi; John Elwell; Ram Mohan R (rmohanr); Paul
>Kyzivat; Hutton, Andrew
>Cc: [email-masked]

---

From: "John Elwell" <[email-masked]>
Date: Tue, 21 Feb 2012 17:01:20 -0000

That is my concern. The proposed option tag would make the bar for SIPREC 
compliance so low that almost any implementation could easily be made to 
comply, and yet the degree of interoperability between such implementations 
would be rather poor. It would be rather like claiming to support SIP 
without supporting SDP.

John

-----Original Message----- 
From: Ravindran, Parthasarathi
Sent: Tuesday, February 21, 2012 3:41 AM
To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr) ; Paul 
Kyzivat ; Hutton, Andrew
Cc: [email-masked]

Hi Charles,

In case we end up with sip.src contact parameter is the only mandatory for 
SIPREC compliance, then I would say that Existing Sonus proprietary 
recording already met SIPREC compliance because adding contact header 
parameter is a matter of configuration. I'm confident that smart product 
manager in other companies push for the same level of compliance ;-) This 
will result in SIPREC compliance with new proprietary headers/body for 
interop with each recording vendor. I'm worried that those kind SIPREC 
compliance will not solve the indented problem which we are working for.

Thanks
Partha

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Feb 2012 12:12:28 -0500

On 2/21/12 12:01 PM, John Elwell wrote:
> That is my concern. The proposed option tag would make the bar for
> SIPREC compliance so low that almost any implementation could easily be
> made to comply, and yet the degree of interoperability between such
> implementations would be rather poor. It would be rather like claiming
> to support SIP without supporting SDP.

I agree.

(But its actually reasonable to support SIP without supporting SDP. You 
only need support SDP if you support INVITE. A proxy, registrar, event 
server, or event client need not support SDP.)

	Thanks,
	Paul

> John
>
>
> -----Original Message----- From: Ravindran, Parthasarathi
> In case we end up with sip.src contact parameter is the only mandatory
> for SIPREC compliance, then I would say that Existing Sonus proprietary
> manager in other companies push for the same level of compliance ;-)
> This will result in SIPREC compliance with new proprietary headers/body
> for interop with each recording vendor. I'm worried that those kind
> SIPREC compliance will not solve the indented problem which we are
> working for.
>
> Thanks
> Partha
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 22 Feb 2012 08:40:01 +0530

+1
Yes. That is my concern too as I mentioned in one of the earlier e-mails
also.
I still prefer to make SIPREC XML metadata as mandatory. The moment we
may it optional we will have all proprietary implementations ( for
conveying metadata) creeping in and will eventually defeat the purpose
of the work we are doing in this Group.

Ram

> Sent: Tuesday, February 21, 2012 10:31 PM
> To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Ram Mohan R
> (rmohanr); Paul Kyzivat; Hutton, Andrew
> Cc: [email-masked]
> SIPREC
> for
> This
> >> >Good to hear from you, and thanks for keeping us honest on this
> one.
> >> The
> >> >to the migration path from pre-SIPREC solutions to SIPREC
> solutions.
> >> In
> >> >but the SRC and/or SRS may support the XML metadata. What if we
> were
> >> to
> >> >do the following?
> >> >
> >> >metadata is supported sip.src and sip.srs feature tags: clarify
> that
> >> it
> >> >include the siprec option tag as it does not support SIPREC
> metadata.
> >> If
> >> >a SIPREC SRS receives such an INVITE, it has the choice of
> rejecting
> >> the
> >> >If the SRC supports metadata but does not require it, it can
> include
> >> the
> >> >> protocol additions are peripheral in comparison. We should say
> that
> >> if
> >> >> you
> >> >don't
> >> >> implement and use XML-based metadata you are not SIPREC-
> compliant.
> >> >> Trying to
> >> >> 1) We will end up in having two different metadata mechanisms -
> one
> >> >XML
> >> >> and one headers based
> >> >>
> >> >> basic metadata ( as partha mentioned in his previous e-mail) and
> if
> >> we
> >> >> are going to add new headers then it is redundant as XML
metadata
> >> was
> >> >> metadata (SIPREC metadata) or Header based metadata and this
will
> >> lead
> >> >> to more issues some of which you already outlined in the below
e-
> >> mail
> >> >> calls where SRC is unable to send metadata or if SRS encounters
> an
> >> SRC
> >> >> > > From: [email-masked] [mailto:siprec-
> [email-masked]]
> >> On
> >> >> > > Behalf Of Paul Kyzivat
> >> >> > > >> I guess it isn't *necessary* to specify that. But there
> are
> >> >> > > >> consequences to not doing so:
> >> >> > > >>
> >> >> > > >> longer acceptable because the new one doesn't infer
things
> >> >> > > Maybe. But there is a big hurdle between not supplied
> metadata
> >> and
> >> >> > > you will have SRCs that just aren't capable of doing so.
> (Most
> >> >> likely

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 22 Feb 2012 12:50:24 -0800

Based on the responses, either my proposal was not clear, or my
understanding of the options and feature tags is incorrect, or both. Let
me try again.
My intention is not to lower the bar for SIPREC compliance. What I
propose is:

1) clarify that the "siprec" option tag, in addition to what is already
stated, indicates that the XML metadata is supposed. You cannot include
the "siprec" option tag in a Supported/Require header unless you support
the XML metadata, as it is the essence of SIPREC.

2) all other SIP/SDP extensions defined in the protocol draft (sip.src,
sip.srs, recording-aware, etc.) are just that, SIP/SDP extensions. There
are not tied directly to the "siprec" option tag and may be used without
the "siprec" option tag.

If an SRC or SRS supports SIPREC XML metadata, it may indicate that by
including "siprec" in a Supported header.
If an SRC or SRS requires SIPREC XML, it may indicate that by including
"siprec" in a Require header.

I do not see this as lowering the bar for SIPREC compliance.
I do see it as providing benefit for implementations that have no
intention of being a SIPREC compliant SRC or SRS.
I also see it helping with interworking between SIPREC compliant and non
SIPREC compliant entities.

Cheers,
Charles

> Sent: Tuesday, February 21, 2012 7:10 PM
> To: John Elwell; Ravindran, Parthasarathi; Charles Eckel (eckelcu);
> Paul Kyzivat; Hutton, Andrew; Leon Portman
> Cc: [email-masked]
> Yes. That is my concern too as I mentioned in one of the earlier e-
> mails also.
> > compliance so low that almost any implementation could easily be
made
> > >> as SRC is forced to support SRS proprietary metadata and it is
one
> > of
> > >> message configuration in the device (no development required
:-)).
> > >Therefore, including the "siprec" option tag means that the
metadata
> > is
> > >> >such cases, the SRCs and UAs within a deployment might add
> support
> > >for
> > >> >In this case, the hybrid SRC that I described could still
include
> > the
> > >> >sip.src feature tag in its REGISTER and INVITE requests. It
would
> > not
> > >> >INVTIE or accepting it for the purpose of recording using
> whatever
> > >> logic
> > >> >it used prior to SIPREC.
> > >> >> bend SIP header fields to achieve a poor-man's metadata does
> not
> > >> make
> > >> >> 2) The existing SIP headers may not be sufficient to carry
even
> > >> >> What we can add is some guidelines on how SRS has to behave
for
> > >> >> that is not completely compliant with SIPREC standards(say
does
> > not
> > >> >> > Exploring this a bit further, I think this would define a
new
> > >> option
> > >> >> > and SRS, a well documented set of SIP headers could be used
> to
> > >> >convey

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2012 15:57:40 -0500

Charles,

Do you see any case where it would be valid to use sip.src or sip.srs 
*without* supporting the siprec option tag?

Below it sounds like you do, but I don't see how that makes sense.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 22 Feb 2012 13:15:03 -0800

Hi Paul,

An SRC could use it when it registers itself with a call control server,
or when it sends/receives a SIP INVITE to/from an UA/MCU to join a call.
This way the UA/MCU knows it has the ability to request specific media
streams within the SIP dialog between it and the SRC be recorded using
the recording-pref attribute. How the SRC accomplishes this is likely
not important to the UA/MCU. The SRC indicates that it is recording
using the record attribute. The record-aware option tag could be
leveraged her as well.

Cheers,
Charles

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, February 22, 2012 12:58 PM
> To: Charles Eckel (eckelcu)
> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, Parthasarathi;
> Hutton, Andrew; Leon Portman; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Feb 2012 16:34:29 -0500

> using the record attribute. The record-aware option tag could be

OK, now I understand, and it does seem to make sense.

	Thanks,
	Paul

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Thu, 23 Feb 2012 01:48:42 +0000

Hi Charles,

Thanks for the clarification. I understand that we are talking about two
different stuff. So, I have changed the subject of the mail as
"Is SIPREC metadata mandatory to implement in Recording Session(RS)". 

Hi all,

Till now, I have not seen anybody has objection for supporting SIRPEC 
metadata in RS. Please correct me in case my understanding is wrong.

Also, I propose to change the following normative statement from "SHOULD"
To "MUST" in recording session:

"An SRC SHOULD include the "siprec" option tag in the Require header when 
initiating a Recording Session so that other types of user agents can 
simply reject the INVITE request with a 420 Bad Extension."

as

"An SRC MUST include the "siprec" option tag in the Require header when 
initiating a Recording Session so that other types of user agents can 
simply reject the INVITE request with a 420 Bad Extension."

Please let me know your opinion on the same.

Thanks
Partha
>Sent: Thursday, February 23, 2012 2:45 AM
>To: Paul Kyzivat

---

From: "John Elwell" <[email-masked]>
Date: Thu, 23 Feb 2012 07:37:49 -0000

Charles,

Thanks for the clarification. I don't see any harm in the option tag. My 
desire is that if you claim to support SIPREC (i.e., support the protocol 
RFC) you MUST also support XML metadata.

John

-----Original Message----- 
From: Charles Eckel (eckelcu)
Sent: Wednesday, February 22, 2012 8:50 PM
To: Ram Mohan R (rmohanr) ; John Elwell ; Ravindran, Parthasarathi ; Paul 
Kyzivat ; Hutton, Andrew ; Leon Portman
Cc: [email-masked]
Subject: RE: [siprec] Is SIPREC metadata mandatory to implement?

Cheers,
Charles

made
one
:-)).
metadata
include
would
even
for
does
new

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 23 Feb 2012 10:38:17 +0100

Hi Charles,

The protocol draft currently states.

"An SRC SHOULD include the "siprec" option tag in the Require header when initiating a Recording Session so that other types of user agents can simply reject the INVITE request with a 420 Bad Extension".

There is a similar statement regarding the SRS.

The purpose of this is to use the "siprec" option tag to identify the session as a recording session and I think we need this. Your proposal would break this so we would need to use a separate option tag to indicate metadata support if we decide metadata is optional.

Regards
Andy

> Sent: 22 February 2012 21:15
> To: Paul Kyzivat
> > > understanding of the options and feature tags is incorrect, or
> both.
> > Let
> > > me try again.
> > > I also see it helping with interworking between SIPREC compliant
> and
> > non

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 23 Feb 2012 12:55:41 -0800

Hi Partha,

If the SRC requires the SRS support SIPREC XML metadata, it can indicate
that by including "siprec" option tag in a Require header.
However, the SRC may not require this, in which case including "siprec"
option tag in Supported header is appropriate.

Cheers,
Charles

> Sent: Wednesday, February 22, 2012 5:49 PM
> To: Charles Eckel (eckelcu); Paul Kyzivat
> Cc: Ram Mohan R (rmohanr); John Elwell; Hutton, Andrew; Leon Portman;
> [email-masked]
> Subject: Is SIPREC metadata mandatory to implement in RS [was RE:
> [siprec] Is SIPREC metadata mandatory to implement?]
> 
> Hi Charles,
> 
> >> > sip.srs, recording-aware, etc.) are just that, SIP/SDP
extensions.
> >> There
> >> > If an SRC or SRS supports SIPREC XML metadata, it may indicate
> that
> >> by

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 23 Feb 2012 12:57:17 -0800

I agree.

Cheers,
Charles

> Sent: Wednesday, February 22, 2012 11:38 PM
> To: Charles Eckel (eckelcu); Ram Mohan R (rmohanr); Ravindran,
> Parthasarathi; Paul Kyzivat; Hutton, Andrew; Leon Portman
> Cc: [email-masked]
> > > To: Charles Eckel (eckelcu) ; John Elwell ; Ram Mohan R (rmohanr)
;
> > > manager in other companies push for the same level of compliance
;-
> )
> > > compliance will not solve the indented problem which we are
working
> > > for.
> > > >> To: Charles Eckel (eckelcu); John Elwell; Ram Mohan R
(rmohanr);
> > > >> >potential benefit I see in have the metadata be optional is
> with
> > > >> respect
> > > >> >the SIP/SDP extensions and RTP/RTCP recommendations provided
by
> > > >> SIPREC,
> > > >> >siprec option tag in a Supported header rather than in a
> Require
> > > >> header.
> > > >> >> 1) We will end up in having two different metadata
mechanisms
> -
> > > >> >> 3) SRC/SRS needs to negotiate on whether they want to use
XML
> > > >> >> So, I feel it's better to stick with one metadata (XML
SIPREC
> > > >> >metadata)
> > > >> >> > tag, e.g. siprec-metadata. An SRC/SRS would include it in
a
> > > >> >Supported
> > > >> >> > between them and the XML metadata? Or do we say that the
> XML
> > > >> >> metadata,

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 24 Feb 2012 17:30:36 +0100

I agree but would add that it also works in the opposite direction in that the SRS can use the option tag in the same way to indicate whether it requires the SRC to support metadata.

Regards
Andy

> Sent: 23 February 2012 20:56
> To: Ravindran, Parthasarathi; Paul Kyzivat
> Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE:

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Feb 2012 12:02:23 -0500

> I agree but would add that it also works in the opposite direction in that the SRS can use the option tag in the same way to indicate whether it requires the SRC to support metadata.

If we agree that metadata support is required of both SRCs and SRSs, 
then signaling that you are an SRC or SRS should be sufficient, without 
separately indicating supprot for metadata.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 24 Feb 2012 14:11:11 -0800

I think SIPREC metadata is applicable to the RS between the SRC and SRS
only, but I have been suggesting that it not be mandatory to support and
use, in that an SRC or SRS could still use the sip.src or sip.srs
feature tags despite not supporting or using the XML metadata within all
RSs. 

Andy raised a very good point, that this breaks the functionality of
using the siprec option tag to indicate that an INVITE is for the
necessary purpose of creating an RS, and should be rejected if the other
side is not willing or capable of creating an RS. Consequently, we have
a few choices:

a) siprec option tag in a Supported/Require header means an RS is
supported/required AND XML metadata is supported/required for this RS
b) siprec option tag in a Supported/Require header means XML metadata is
supported/required and another option tag is used to specify whether an
RS is Supported/Required
c) siprec option tag in a Supported/Require header means an RS is
supported/required and another option tag is used to specify whether an
RS is Supported/Required

I believe Partha was advocating (a).
Options (b) and (c) could be handled by replacing the single siprec
options tag with two tags, siprec-rs for the RS, and siprec-metadata for
the metadata.
I am okay with (a), (b), or (c), so long as it is still possible to use
the sip.src and sip.srs feature tags without necessarily having to
support or use the XML metadata.

Cheers,
Charles

> Sent: Friday, February 24, 2012 9:02 AM
> To: Hutton, Andrew
> Cc: Charles Eckel (eckelcu); Ravindran, Parthasarathi; Ram Mohan R
> (rmohanr); John Elwell; Leon Portman; [email-masked]
> Subject: Re: Is SIPREC metadata mandatory to implement in RS [was RE:
> > I agree but would add that it also works in the opposite direction
in
> that the SRS can use the option tag in the same way to indicate
whether
> it requires the SRC to support metadata.
> 
> >>> Thanks for the clarification. I understand that we are talking
> about
> >>> two
> >>> "An SRC SHOULD include the "siprec" option tag in the Require
> header
> >>> when
> >>>> or when it sends/receives a SIP INVITE to/from an UA/MCU to join
a
> >>> call.
> >>>>>> My intention is not to lower the bar for SIPREC compliance.
What
> >>>>>> the "siprec" option tag in a Supported/Require header unless
you
> >>>>>> are not tied directly to the "siprec" option tag and may be
used

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 06:32:05 +0000

Hi Charles,

Sorry in case my request for "siprec option tag MUST normative requirement" request created some confusion here. IMO, siprec option tag in a Supported/Require header means RS is supported/required. I have proposed "MUST" in siprec option as I didn't any reason for leniency to specify as "SHOULD". 

Hi all,

As far as the metadata is considered, I'm still look for the words to indicate "SRC and SRS MUST implement SIPREC metadata XML". It may be preferred to indicates that SRC MUST implement metadata XML encoding whereas SRS MUST implement metadata XML decoding. Even though John indicated in his mail about metadata mandating, RFC 3261 does not have any explicit requirement to say "application/sdp" MUST be supported in SIP UAC and UAS but instead, there are requirement in INVITE, OPTIONS to send "application/sdp" message body and UAS to assume "application/sdp" in accept header if nothing is mentioned. It will be good to see the exact metadata requirement to convey this.

Thanks
Partha 

>Sent: Saturday, February 25, 2012 3:41 AM
>Cc: Ravindran, Parthasarathi; Ram Mohan R (rmohanr); John Elwell; Leon
>Portman; [email-masked]
>> >> If the SRC requires the SRS support SIPREC XML metadata, it can
>> >> indicate that by including "siprec" option tag in a Require header.
>> >>> different stuff. So, I have changed the subject of the mail as "Is
>> >>> SIPREC metadata mandatory to implement in Recording
>> Session(RS)".
>> >>>
>> >>> Hi all,
>> >>>

---

From: Leon Portman <[email-masked]>
Date: Mon, 27 Feb 2012 14:37:56 +0200

Hello

I am ok as well with all three options, however do we really want to complicate the protocol with different combinations (RS support and metadata support)? If SRC does not have/want to send any metadata, it can send empty XML in the worst case.

Leon 

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 8:32 AM
To: Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew
Cc: Ram Mohan R (rmohanr); John Elwell; Leon Portman; [email-masked]
Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?]

Hi Charles,

Hi all,

Thanks
Partha 

>only, but I have been suggesting that it not be mandatory to support 
>and use, in that an SRC or SRS could still use the sip.src or sip.srs 
>feature tags despite not supporting or using the XML metadata within 
>all RSs.
>
>necessary purpose of creating an RS, and should be rejected if the 
>other side is not willing or capable of creating an RS. Consequently, 
>we have a few choices:
>
>b) siprec option tag in a Supported/Require header means XML metadata 
>is supported/required and another option tag is used to specify whether 
>an RS is Supported/Required
>options tag with two tags, siprec-rs for the RS, and siprec-metadata 
>for the metadata.
>> >>> "An SRC MUST include the "siprec" option tag in the Require 
>> >>> header
>> >> when
>> >>>> Cc: Ram Mohan R (rmohanr); John Elwell; Ravindran, 
>> >>>> Parthasarathi; Hutton, Andrew; Leon Portman; [email-masked]
>> >>>>>> Based on the responses, either my proposal was not clear, or 
>> >>>>>> my understanding of the options and feature tags is incorrect, 
>> >>>>>> or
>> >>> both.
>> >>>>> Let
>> >>>>>> me try again.
>> >>>>>> 1) clarify that the "siprec" option tag, in addition to what 
>> >>>>>> is
>> >>>>> already
>> >>>>>> stated, indicates that the XML metadata is supposed. You 
>> >>>>>> cannot
>> >>>>> include

---

From: "Ravindran, Parthasarathi" <[email-masked]>
Date: Mon, 27 Feb 2012 13:03:07 +0000

Leon,

Even in the case of "Require:siprec", there is no need to mandate for sending metadata. Options tag "siprec" indicates that the dialog is RS. In case of persistent scenario, it is perfectly fine to send the initial RS INVITE with SDP, "Require:siprec" and without metadata. For option tag, there is a need of text similar to below:

        Header field                 where   proxy ACK BYE CAN INV OPT REG
   ------------------------------------------------------------------------
   Supported:siprec                 R                -   o   o  -  o   o
   Require:siprec                   R                -   o   -  m  o   o

The another open item how to mandate Metadata XML message body support in SRC and SRS.

Thanks
Partha

>From: Leon Portman [mailto:[email-masked]]
>Sent: Monday, February 27, 2012 6:08 PM
>To: Ravindran, Parthasarathi; Charles Eckel (eckelcu); Paul Kyzivat;
>Hutton, Andrew
>Cc: Ram Mohan R (rmohanr); John Elwell; [email-masked]
>I am ok as well with all three options, however do we really want to
>complicate the protocol with different combinations (RS support and
>metadata support)? If SRC does not have/want to send any metadata, it
>can send empty XML in the worst case.
>
>Leon
>
>Sorry in case my request for "siprec option tag MUST normative
>requirement" request created some confusion here. IMO, siprec option tag
>in a Supported/Require header means RS is supported/required. I have
>proposed "MUST" in siprec option as I didn't any reason for leniency to
>specify as "SHOULD".
>
>Hi all,
>
>As far as the metadata is considered, I'm still look for the words to
>indicate "SRC and SRS MUST implement SIPREC metadata XML". It may be
>preferred to indicates that SRC MUST implement metadata XML encoding
>whereas SRS MUST implement metadata XML decoding. Even though John
>indicated in his mail about metadata mandating, RFC 3261 does not have
>any explicit requirement to say "application/sdp" MUST be supported in
>SIP UAC and UAS but instead, there are requirement in INVITE, OPTIONS to
>send "application/sdp" message body and UAS to assume "application/sdp"
>in accept header if nothing is mentioned. It will be good to see the
>exact metadata requirement to convey this.
>
>Thanks
>Partha
>
>>Parthasarathi;

---

From: Leon Portman <[email-masked]>
Date: Mon, 27 Feb 2012 17:47:58 +0200

Partha, thanks

It is even more simple this way

Leon

-----Original Message-----
From: Ravindran, Parthasarathi [mailto:[email-masked]] 
Sent: Monday, February 27, 2012 3:03 PM
To: Leon Portman; Charles Eckel (eckelcu); Paul Kyzivat; Hutton, Andrew
Cc: Ram Mohan R (rmohanr); John Elwell; [email-masked]
Subject: RE: Is SIPREC metadata mandatory to implement in RS [was RE: [siprec] Is SIPREC metadata mandatory to implement?]

Leon,

Thanks
Partha

>requirement" request created some confusion here. IMO, siprec option 
>tag in a Supported/Require header means RS is supported/required. I 
>have proposed "MUST" in siprec option as I didn't any reason for 
>leniency to specify as "SHOULD".
>
>Hi all,
>
>SIP UAC and UAS but instead, there are requirement in INVITE, OPTIONS 
>to send "application/sdp" message body and UAS to assume "application/sdp"
>>I think SIPREC metadata is applicable to the RS between the SRC and 
>>SRS only, but I have been suggesting that it not be mandatory to 
>>support and use, in that an SRC or SRS could still use the sip.src or 
>>sip.srs feature tags despite not supporting or using the XML metadata 
>>within all RSs.
>>
>>is supported/required and another option tag is used to specify 
>>whether an RS is Supported/Required
>>supported/required and another option tag is used to specify whether 
>>I am okay with (a), (b), or (c), so long as it is still possible to 
>>use the sip.src and sip.srs feature tags without necessarily having to 
>>> >>> initiating a Recording Session so that other types of user 
>>> >>> agents
>>> can
>>> >>> initiating a Recording Session so that other types of user 
>>> >>> agents
>>> can
>>> >>>> An SRC could use it when it registers itself with a call 
>>> >>>> control
>>> >>> server,
>>> >>>> This way the UA/MCU knows it has the ability to request 
>>> >>>> specific
>>> >> media
>>> >>>> streams within the SIP dialog between it and the SRC be 
>>> >>>> recorded
>>> >> using
>>> >>>> using the record attribute. The record-aware option tag could 
>>> >>>> be leveraged her as well.
>>> >>>>
>>> >>>> Cheers,
>>> >>>> Charles
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>>> my understanding of the options and feature tags is 
>>> >>>>>> incorrect, or
>>> >>> both.
>>> >>>>> Let
>>> >>>>>> me try again.
>>> >>>>>> I do see it as providing benefit for implementations that 
>>> >>>>>> have
>>> >> no

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Feb 2012 15:20:53 -0500

I support (a) below. Frankly ISTM that what siprec is all about is the 
metadata. Without the metadata you don't need siprec at all. While we 
certainly have in mind that the SRS is recording the media it receives, 
I doubt there is any way that we can actually enforce that. So without 
metadata support, siprec simply becomes SIP support.

	Thanks,
	Paul

On 2/24/12 5:11 PM, Charles Eckel (eckelcu) wrote:
>>>> indicate

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 28 Feb 2012 08:49:12 +0530

+1.
Even I support (a) below. 

Ram

> Sent: Tuesday, February 28, 2012 1:51 AM
> Cc: Hutton, Andrew; Ravindran, Parthasarathi; Ram Mohan R (rmohanr);
> John Elwell; Leon Portman; [email-masked]
> SRS
> all
> other
> use
agents
agents
control
specific
recorded
> >>>>>> using the record attribute. The record-aware option tag could
be
> my
have