Subject: [siprec] Comments on draft-ietf-siprec-architecture-05

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 16:53:10 -0400

One small comment on this:

Section 3.2.4:

    When recording this media the two streams may be
    mixed at the SRC before being transmitted to the SRS or it may be a
    requirement of the recording server that the media streams are not
    mixed and are sent to the SRS as two separate streams.

Do we really want to say that the SRS can decide that it must have 
unmixed media???

I don't think so. IMO this should be solely at the discretion of the SRC.

If it was up to the SRS, how would it indicate this to the SRC?

---

From: Leon Portman <[email-masked]>
Date: Thu, 26 Jul 2012 23:59:07 +0300

Paul Hi

Generic comment: current implementations of SRS support to be configured either store unmixed media separately or  mixed them on SRS side in order to save storage.
On protocol side: we can define a negotiation of mixing like this: If SRC supports sending both mixed and unmixed medias, it can offer both in SDP as multiple m-lines and SRS can accept the preferred option.
Of if it is specific policy on SRC side, SRS still can have option to mix if SRC always sends unmixed.

What do you think?

Leon

On Jul 26, 2012, at 11:53 PM, Paul Kyzivat <[email-masked]> wrote:

> Do we really want to say that the SRS can decide that it must have unmixed media???
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Michael Smith <[email-masked]>
Date: Thu, 26 Jul 2012 21:11:24 +0000

I would think you'd want the SRS, as the recipient of the media, to decide whether it wants mixed or unmixed media. And that the SRC must support both, and must comply with the SRS's request. And that implies that you must have a mechanism for the SRC to tell the SRC whether it wants mixed or unmixed media.

An SRS may receive from many SRCs. What I suggest above allows policy to be implemented in one place (the SRS), and forces all SRCs to comply with it. 

Michael Smith
Chief Technologist
Ph: 606.877.2788 | Mobile: 606.231.0243 

DSS Corporation / Equature
18311   W. Ten Mile Road, Suite 200
Southfield, MI - 48075
Tel: 1-888.305.3428
Fax: 1-248.569.6567
www.dss-corp.com
www.dispatchimprovement.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Leon Portman
Sent: Thursday, July 26, 2012 4:59 PM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Paul Hi

What do you think?

Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 17:11:56 -0400

> Of if it is specific policy on SRC side, SRS still can have option to mix if SRC always sends unmixed.

I think its impossible to tell from the presence of m-lines whether the 
intent is to use them for independent streams in a session or 
independent sessions, or ???.

*If* its necessary to negotiate mixing by the SRC, then I think we need 
to add some explicit mechanism to do it. But I'm not sure its necessary. 
Isn't it sufficient to leave the choice of which to do to local policy 
on the SRC? (And to require that an SRS be able to accept it either way.)

	Thanks,
	Paul

> Leon
>
> On Jul 26, 2012, at 11:53 PM, Paul Kyzivat<[email-masked]>  wrote:
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Thu, 26 Jul 2012 21:52:02 +0000

I ran into this when adding the "RTP Session Usage by SRC" section to the protocol draft. Here an example of how I handled it:

   When using multiple m-lines, an SRC includes each m-line in an SDP
   offer to the SRS.  The SDP answer from the SRS MUST include all
   m-lines, with any rejected m-lines indicated with a zero port, per
   [RFC3264].  Having received the answer, the SRC starts sending media
   to the SRS as indicated in the answer.  Alternatively, if the SRC
   deems the level of support indicated in the answer to be
   unacceptable, it may initiate another SDP offer/answer exchange in
   which an alternative RTP session usage is negotiated.

If we think we need something more explicit, or something that works with a single offer/answer exchange, we need to add a new mechanism to the protocol.

Cheers,
Charles

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Thursday, July 26, 2012 2:12 PM
> To: Leon Portman
> Cc: [email-masked]
> > Generic comment: current implementations of SRS support to be
> configured either store unmixed media separately or  mixed them on SRS
> side in order to save storage.
> > On protocol side: we can define a negotiation of mixing like this: If SRC
> supports sending both mixed and unmixed medias, it can offer both in SDP
> as multiple m-lines and SRS can accept the preferred option.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 18:15:00 -0400

> I would think you'd want the SRS, as the recipient of the media, to decide whether it wants mixed or unmixed media. And that the SRC must support both, and must comply with the SRS's request. And t…

You are going to *require* that the SRC be able to do mixing???

> An SRS may receive from many SRCs. What I suggest above allows policy to be implemented in one place (the SRS), and forces all SRCs to comply with it.

On the contrary, ISTM that the SRS is a *utility*, and one that probably 
has considerable resources. It is providing a service to a wide range of 
clients that may vary widely in their capabilities.
It makes much or sense to me that life is made as simple and flexible as 
possible for the SRC.

Leon indicated that some preliminary implementations prefer to receive 
the streams unmixed. That is also perhaps easier for the SRC, at the 
expense of requiring more bandwidth. Certainly its easier for a "phone" 
that might have no mixing capability at all. OTOH there may be devices 
that are very bandwidth limited that would prefer to mix first to 
conserve the bandwidth. And there may be some devices, such as a 
conference focus, for which mixing may be the most convenient way. And 
of course there could be an SRC that is a *participant* in a conference, 
that has no choice but to accept mixed media from the focus, and so must 
pass it along unmixed to the SRS.

	Thanks,
	Paul

---

From: Michael Smith <[email-masked]>
Date: Thu, 26 Jul 2012 23:08:28 +0000

Hmmm... What's important is that the SRC supports unmixed streams. If it does, the server could mix them, and policy is enforced at that point. The drawback to that is that you consume twice the bandwidth per CS, even if your policy is to store mixed streams. 

Good point about a phone, but they do already mix the two parties voices. Mixing is simple, and not processing-intensive, so levying that requirement on an SRC isn't onerous, IMHO.

I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. But I think it's a problem if an SRC mixes media and policy dictates that unmixed media be stored - there's no way to un-mix it. 

I think requirements might be crafted that an SRS MUST support receiving both mixed and unmixed media, and an SRC MUST support sending unmixed media, and MAY support sending mixed media. You'd still need some mechanism for negotiating mixed/unmixed.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Thursday, July 26, 2012 6:15 PM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

> An SRS may receive from many SRCs. What I suggest above allows policy to be implemented in one place (the SRS), and forces all SRCs to comply with it.

On the contrary, ISTM that the SRS is a *utility*, and one that probably has considerable resources. It is providing a service to a wide range of clients that may vary widely in their capabilities.
It makes much or sense to me that life is made as simple and flexible as possible for the SRC.

Leon indicated that some preliminary implementations prefer to receive the streams unmixed. That is also perhaps easier for the SRC, at the expense of requiring more bandwidth. Certainly its easier for a "phone" 
that might have no mixing capability at all. OTOH there may be devices that are very bandwidth limited that would prefer to mix first to conserve the bandwidth. And there may be some devices, such as a conference focus, for which mixing may be the most convenient way. And of course there could be an SRC that is a *participant* in a conference, that has no choice but to accept mixed media from the focus, and so must pass it along unmixed to the SRS.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 20:34:23 -0400

> If we think we need something more explicit, or something that works with a single offer/answer exchange, we need to add a new mechanism to the protocol.

Well, this only touches on the issue.

I guess it is true that the SRS could refuse all but one m-line (or one 
audio and one video). And then the SRC would be forced to cope with that.

But that would force it to mix or multiplex on the one. But it could do 
that for one CS and establish a separate RS for every CS. But that is an 
extreme. Other possibilities are to multiplex/mix all the all of one CS 
on one m-line, but have multiple m-lines, one for each CS. Or it could 
multiplex many CS on a single m-line.

If the SRS gets to have an opinion on this it will get complicated.

ISTM that its better to just say this is up to the SRC to decide. The 
SRS can still limit the total number of m-lines, but not how they are used.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Jul 2012 20:46:37 -0400

> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it. But I think it's a problem if an SRC mixes media and policy dictates that unmixed media be stored - there's no way to un-mix i…

So what about an SRC connected to a focus of a conference with many 
participants. The SRC is only receiving a mixed stream from the focus, 
which includes all participants except itself. It can know who all the 
participants are (from the conference event package), but it can't pass 
them on unmixed.

> I think requirements might be crafted that an SRS MUST support receiving both mixed and unmixed media, and an SRC MUST support sending unmixed media, and MAY support sending mixed media. You'd stil…

I'm going to stand by my prior opinion for now.

As a customer I think you can *prefer* that things work this way. If you 
have buying control over the SRC you can specify that. But I don't think 
it makes sense to exclude SRCs that work otherwise.

	Thanks,
	Paul

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 27 Jul 2012 04:44:47 +0000

> On 27/07/12 6:16 AM, "Paul Kyzivat" <[email-masked]> wrote:

>> Hmmm... What's important is that the SRC supports unmixed streams. If
>>it does, the server could mix them, and policy is enforced at that
>>point. The drawback to that is that you consume twice the bandwidth per
>>CS, even if your policy is to store mixed streams.
>>
>> Good point about a phone, but they do already mix the two parties
>>voices. Mixing is simple, and not processing-intensive, so levying that
>>requirement on an SRC isn't onerous, IMHO.
>>
>> I'd be ok if an SRC didn't support mixing media, and the SRS mixed it.
>>But I think it's a problem if an SRC mixes media and policy dictates
>>that unmixed media be stored - there's no way to un-mix it.
>
>> I think requirements might be crafted that an SRS MUST support
>>receiving both mixed and unmixed media, and an SRC MUST support sending
>>unmixed media, and MAY support sending mixed media. You'd still need
>>some mechanism for negotiating mixed/unmixed.
>

I also agree with Paul. We can have an SRC that does one or more of the
following:
1)An SRC MAY support sending unmixed media only
2) An SRC supports sending mixed media only (the case of conference where
SRC is a participant)
3) An SRC supports sending mixed or unmixed media or both

So its better not to restrict and there by exclude some SRCs.

Ram

>>> I would think you'd want the SRS, as the recipient of the media, to
>>>decide whether it wants mixed or unmixed media. And that the SRC must
>>>support both, and must comply with the SRS's request. And that implies
>>>that you must have a mechanism for the SRC to tell the SRC whether it
>>>wants mixed or unmixed media.
>>
>>> An SRS may receive from many SRCs. What I suggest above allows policy
>>>to be implemented in one place (the SRS), and forces all SRCs to comply
>>>with it.
>>
>> On the contrary, ISTM that the SRS is a *utility*, and one that
>>probably has considerable resources. It is providing a service to a wide
>>range of clients that may vary widely in their capabilities.
>>> On protocol side: we can define a negotiation of mixing like this: If
>>>SRC supports sending both mixed and unmixed medias, it can offer both
>>>in SDP as multiple m-lines and SRS can accept the preferred option.

---

From: Michael Smith <[email-masked]>
Date: Fri, 27 Jul 2012 13:28:17 +0000

So Ram proposes:
    We can have an SRC that does one or more of the following:
    1)An SRC MAY support sending unmixed media only
    2) An SRC supports sending mixed media only (the case of conference where SRC is a participant)
    3) An SRC supports sending mixed or unmixed media or both

I'm curious - do others agree with that position?

IMHO, the SRC conference participant case is a non-issue. If an SRC is a participant in a Bridge, the "mixed" media coming from the Bridge is a single stream from its point of view, and an SRS that wanted unmixed media would only get whatever streams the SRC had. 

Now, I would like to see the possibility of the SRS dictating (or at least indicating a desire for) mixed or unmixed media, but if the majority disagree, I can live with that.

I do want to bring this up with the NENA NG9-1-1 recording test committee I chair. Nine recording companies participate, and I'd like to see if that group thinks we should impose additional requirements for an SRC/SRS used in an NG9-1-1 environment. I don't personally think that Public Safety needs are different than private sector needs on this issue, but it's a good discussion to have now. If there were no mechanism for the SRS to make its mixed/unmixed desire known, we'd have a problem to solve. Perhaps this group could define such a mechanism without requiring that it be used?

Thanks,

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Friday, July 27, 2012 12:45 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

>>point. The drawback to that is that you consume twice the bandwidth 
>>per CS, even if your policy is to store mixed streams.
>>
>>voices. Mixing is simple, and not processing-intensive, so levying 
>>that requirement on an SRC isn't onerous, IMHO.
>>
>>receiving both mixed and unmixed media, and an SRC MUST support 
>>sending unmixed media, and MAY support sending mixed media. You'd 
>>still need some mechanism for negotiating mixed/unmixed.
>
>As a customer I think you can *prefer* that things work this way. If 
>you have buying control over the SRC you can specify that. But I don't 
>think it makes sense to exclude SRCs that work otherwise.

I also agree with Paul. We can have an SRC that does one or more of the
following:
1)An SRC MAY support sending unmixed media only
2) An SRC supports sending mixed media only (the case of conference where SRC is a participant)
3) An SRC supports sending mixed or unmixed media or both

Ram

>>>support both, and must comply with the SRS's request. And that 
>>>implies that you must have a mechanism for the SRC to tell the SRC 
>>>whether it wants mixed or unmixed media.
>>
>>> An SRS may receive from many SRCs. What I suggest above allows 
>>>policy to be implemented in one place (the SRS), and forces all SRCs 
>>>to comply with it.
>>
>>probably has considerable resources. It is providing a service to a 
>>wide range of clients that may vary widely in their capabilities.
>> Leon indicated that some preliminary implementations prefer to 
>>receive the streams unmixed. That is also perhaps easier for the SRC, 
>>at the expense of requiring more bandwidth. Certainly its easier for a "phone"
>> that might have no mixing capability at all. OTOH there may be 
>>devices that are very bandwidth limited that would prefer to mix first 
>>to conserve the bandwidth. And there may be some devices, such as a 
>>of course there could be an SRC that is a *participant* in a 
>>conference, that has no choice but to accept mixed media from the 
>>focus, and so must pass it along unmixed to the SRS.
>>
>> 	Thanks,
>> 	Paul
>>
>>> Michael Smith
>>> Chief Technologist
>>>configured either store unmixed media separately or  mixed them on 
>>>SRS side in order to save storage.
>>> On protocol side: we can define a negotiation of mixing like this: 
>>>If SRC supports sending both mixed and unmixed medias, it can offer 
>>>both in SDP as multiple m-lines and SRS can accept the preferred option.

---

From: Dave Higton <[email-masked]>
Date: Fri, 27 Jul 2012 15:15:35 +0100

I am accustomed to thinking that the choice to record mixed or unmixed media is made at time of placing a contract to purchase recording equipment.  That places no requirement to specify at recording time.

Is there, therefore, a case for saying that SIPREC does not need to support such a choice?

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Smith
Sent: 27 July 2012 14:28
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

So Ram proposes:

Thanks,

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Friday, July 27, 2012 12:45 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Ram

---

From: Michael Smith <[email-masked]>
Date: Fri, 27 Jul 2012 14:26:47 +0000

Yeah, I think Paul made the case that a customer can buy an SRC that supports sending mixed, unmixed or both. But without some requirement, we don't know what vendors will produce, and you can only buy what's available.

I'm ok with the proposal Paul and Ram made, as long as we're all ok with the possibility that SRC vendors might offer only mixed, or conversely, only unmixed. Either could happen, but I suspect the "mixed only" option would be what we'd end up with - and that's the problem. The server doesn't even have a choice if that's all the SRC offers. It can only record mixed media.

BTW, I looked at the current NENA 08-003 draft. It looks like we dropped the sentence we initially had about recording unmixed media, perhaps for the same reasons Paul and Ram have presented.

I still would like to have some mechanism for the SRS to make its desire for mixed or unmixed known, and then say that it MAY be used, and the SRC MAY comply with the request. I think that's better than nothing.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Higton
Sent: Friday, July 27, 2012 10:16 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Smith
Sent: 27 July 2012 14:28
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

So Ram proposes:

Thanks,

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
Sent: Friday, July 27, 2012 12:45 AM
To: Paul Kyzivat; [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Ram

---

From: Leon Portman <[email-masked]>
Date: Fri, 27 Jul 2012 17:32:01 +0300

I agree with Michael. It is will be useful for SRS to indicate when unmixed audio is preferable. One of the use cases is if some specific calls are analyzed in real time for fraud, and only these calls should be unmixed for better accuracy

Leon

Leon

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jul 2012 10:44:13 -0400

> I still would like to have some mechanism for the SRS to make its desire for mixed or unmixed known, and then say that it MAY be used, and the SRC MAY comply with the request. I think that's better…

I am agreeable with having some discussion of how the SRS can express 
some preferences to the SRC. It doesn't seem to fit well within the 
communication framework we have defined so far, so it might require some 
significant changes.

One problem is that currently its possible for the SRC to send an INVITE 
to initiate an RS, with an SDP offer and metadata describing what it 
wants recorded initially. The construction of that offer and the 
metadata already embodies a policy decision about how to do the 
recording - whether mixed or unmixed. And at that time there has been 
*no* opportunity for the SRS to indicate its preferences. And I've been 
led to believe its important that things work this way so that a 
recording can be established rapidly.

	Thanks,
	Paul

>> On 27/07/12 6:16 AM, "Paul Kyzivat"<[email-masked]>  wrote:
>

---

From: Michael Smith <[email-masked]>
Date: Fri, 27 Jul 2012 14:54:38 +0000

Hmmm... perhaps this discussion should be future work? I'm not sure the group would want to get into something new that is potentially complex at this point.

I was thinking a mechanism would be fairly straightforward. Perhaps it's not.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, July 27, 2012 10:44 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

> I still would like to have some mechanism for the SRS to make its desire for mixed or unmixed known, and then say that it MAY be used, and the SRC MAY comply with the request. I think that's better…

I am agreeable with having some discussion of how the SRS can express some preferences to the SRC. It doesn't seem to fit well within the communication framework we have defined so far, so it might require some significant changes.

One problem is that currently its possible for the SRC to send an INVITE to initiate an RS, with an SDP offer and metadata describing what it wants recorded initially. The construction of that offer and the metadata already embodies a policy decision about how to do the recording - whether mixed or unmixed. And at that time there has been
*no* opportunity for the SRS to indicate its preferences. And I've been led to believe its important that things work this way so that a recording can be established rapidly.

	Thanks,
	Paul

>>> Hmmm... What's important is that the SRC supports unmixed streams. 
>>> If it does, the server could mix them, and policy is enforced at 
>>> that point. The drawback to that is that you consume twice the 
>>> bandwidth per CS, even if your policy is to store mixed streams.
>>>
>> participants. The SRC is only receiving a mixed stream from the 
>> focus, which includes all participants except itself. It can know who 
>> all the participants are (from the conference event package), but it 
>> can't pass them on unmixed.
>>
>> you have buying control over the SRC you can specify that. But I 
>> don't think it makes sense to exclude SRCs that work otherwise.
>
>
>>>> decide whether it wants mixed or unmixed media. And that the SRC 
>>>> must support both, and must comply with the SRS's request. And that 
>>>> policy to be implemented in one place (the SRS), and forces all 
>>>> SRCs to comply with it.
>>>
>>> receive the streams unmixed. That is also perhaps easier for the 
>>> SRC, at the expense of requiring more bandwidth. Certainly its easier for a "phone"
>>> devices that are very bandwidth limited that would prefer to mix 
>>> first to conserve the bandwidth. And there may be some devices, such 
>>> as a conference focus, for which mixing may be the most convenient 
>>> way. And of course there could be an SRC that is a *participant* in 
>>> a conference, that has no choice but to accept mixed media from the

---

From: Michael Smith <[email-masked]>
Date: Fri, 27 Jul 2012 14:59:09 +0000

And when the discussion does occur at some point, I think the Options method might provide the framework for an SRC to discover what the desire of an SRS is.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Smith
Sent: Friday, July 27, 2012 10:55 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, July 27, 2012 10:44 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

        Thanks,
        Paul

---

From: Dave Higton <[email-masked]>
Date: Fri, 27 Jul 2012 16:00:56 +0100

That seems to me to make a good deal of sense.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Smith
Sent: 27 July 2012 15:59
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Smith
Sent: Friday, July 27, 2012 10:55 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, July 27, 2012 10:44 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 27 Jul 2012 11:14:34 -0400

> I was thinking a mechanism would be fairly straightforward. Perhaps it's not.

Maybe we will have some time to discuss this as part of the architecture 
or protocol discussion. But maybe not - there isn't a lot of time.

Do the chairs have an opinion on this?

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 27 Jul 2012 18:16:28 +0000

There is already a discussion of the RTP session usage by the SRC planned as part of the changes to the protocol draft. I have some slides prepared for this, and section 8.3 of draft-ietf-siprec-protocol-06 (http://tools.ietf.org/html/draft-ietf-siprec-protocol-06#section-8.3) contains the corresponding text.
What I proposed there was the SRC has options as to whether to send mixed, unmixed, or multiplexed streams, and it uses the offer/answer to allow the SRS in the answer to accept, reject, or indicate support for some subset of what is offered.
I left the need for anything specific in terms of SRS preferences as an open question, partially because my hunch was that SRC and SRS vendors would want to support as many options as possible, and when it came to actual deployments the SRC and SRS would be configured to function as required within the given deployment. In some cases, a specific SRC or SRS implementation may not be appropriate for a given deployment's requirements, and that is okay.
I agree with the statements that an SRC may not being able to un-mix a previously mixed stream, so a preference/configuration for unmixed streams would mean that the SRC should keep the streams as separate as possible.

Cheers,
Charles

> Sent: Friday, July 27, 2012 8:15 AM
> To: [email-masked]
> > Hmmm... perhaps this discussion should be future work? I'm not sure the
> group would want to get into something new that is potentially complex at
> this point.
> >
> >> Yeah, I think Paul made the case that a customer can buy an SRC that
> supports sending mixed, unmixed or both. But without some requirement,
> we don't know what vendors will produce, and you can only buy what's
> available.
> >>
> >> I'm ok with the proposal Paul and Ram made, as long as we're all ok with
> the possibility that SRC vendors might offer only mixed, or conversely, only
> unmixed. Either could happen, but I suspect the "mixed only" option would
> be what we'd end up with - and that's the problem. The server doesn't even
> have a choice if that's all the SRC offers. It can only record mixed media.
> >>
> >> BTW, I looked at the current NENA 08-003 draft. It looks like we dropped
> the sentence we initially had about recording unmixed media, perhaps for
> the same reasons Paul and Ram have presented.
> >>
> >> I still would like to have some mechanism for the SRS to make its desire
> for mixed or unmixed known, and then say that it MAY be used, and the SRC
> MAY comply with the request. I think that's better than nothing.
> >
> > One problem is that currently its possible for the SRC to send an INVITE to
> initiate an RS, with an SDP offer and metadata describing what it wants
> recorded initially. The construction of that offer and the metadata already
> embodies a policy decision about how to do the recording - whether mixed
> or unmixed. And at that time there has been
> > *no* opportunity for the SRS to indicate its preferences. And I've been led
> to believe its important that things work this way so that a recording can be
> established rapidly.
> >
> > 	Thanks,
> > 	Paul
> >
> >> Michael Smith
> >> Chief Technologist
> >> I am accustomed to thinking that the choice to record mixed or unmixed
> media is made at time of placing a contract to purchase recording
> equipment.  That places no requirement to specify at recording time.
> >>
> >> IMHO, the SRC conference participant case is a non-issue. If an SRC is a
> participant in a Bridge, the "mixed" media coming from the Bridge is a single
> stream from its point of view, and an SRS that wanted unmixed media
> would only get whatever streams the SRC had.
> >>
> >> Now, I would like to see the possibility of the SRS dictating (or at least
> indicating a desire for) mixed or unmixed media, but if the majority
> disagree, I can live with that.
> >>
> >> I do want to bring this up with the NENA NG9-1-1 recording test
> committee I chair. Nine recording companies participate, and I'd like to see
> if that group thinks we should impose additional requirements for an
> SRC/SRS used in an NG9-1-1 environment. I don't personally think that
> Public Safety needs are different than private sector needs on this issue,
> but it's a good discussion to have now. If there were no mechanism for the
> SRS to make its mixed/unmixed desire known, we'd have a problem to
> solve. Perhaps this group could define such a mechanism without requiring
> that it be used?
> >>
> >>
> >> Thanks,
> >>
> >> Michael Smith
> >> Chief Technologist

---

From: Michael Smith <[email-masked]>
Date: Fri, 27 Jul 2012 20:04:48 +0000

Paul, Ram and siprec group members:

We discussed this on that NENA recording test committee call I mentioned. The consensus there was that this issue is complex enough that it would slow the siprec group's work down substantially. That group would rather see the existing protocol finalized, and see this mixed/unmixed media issue dealt with in a future version.

Your call, but I think we all see the point Paul and Ram were making - that this will take some thought.

Michael Smith
Chief Technologist

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Friday, July 27, 2012 11:15 AM
To: [email-masked]
Subject: Re: [siprec] Comments on draft-ietf-siprec-architecture-05

> I was thinking a mechanism would be fairly straightforward. Perhaps it's not.

Maybe we will have some time to discuss this as part of the architecture or protocol discussion. But maybe not - there isn't a lot of time.

        Thanks,
        Paul

> One problem is that currently its possible for the SRC to send an
> INVITE to initiate an RS, with an SDP offer and metadata describing
> what it wants recorded initially. The construction of that offer and
> the metadata already embodies a policy decision about how to do the
>>>> But I think it's a problem if an SRC mixes media and policy
>>>> dictates that unmixed media be stored - there's no way to un-mix it.
>>>
>>> focus, which includes all participants except itself. It can know
>>> who all the participants are (from the conference event package),
>>> but it can't pass them on unmixed.
>>>
>>>>> I would think you'd want the SRS, as the recipient of the media,
>>>>> to decide whether it wants mixed or unmixed media. And that the
>>>>> SRC must support both, and must comply with the SRS's request. And
>>>>> that implies that you must have a mechanism for the SRC to tell
>>>>> the SRC whether it wants mixed or unmixed media.
>>>>
>>>> first to conserve the bandwidth. And there may be some devices,
>>>> such as a conference focus, for which mixing may be the most
>>>> convenient way. And of course there could be an SRC that is a
>>>> *participant* in a conference, that has no choice but to accept
>>>> mixed media from the focus, and so must pass it along unmixed to the SRS.
>>>>
>>>>    Thanks,
>>>>    Paul
>>>>
>>>>> Michael Smith
>>>>> Chief Technologist
>>>>> If SRC supports sending both mixed and unmixed medias, it can
>>>>> offer both in SDP as multiple m-lines and SRS can accept the preferred option.

---

From: "Hutton, Andrew" <[email-masked]>
Date: Sun, 29 Jul 2012 14:24:49 +0000

Hi,

How I see it then is the SIPREC architecture does not prevent some type of capability or preference to be exchanged between the SRS and SRC but we have not so far discussed any such mechanism. I think we don't therefore need to say anything about this in the architecture draft but could initiate work on a mechanism to achieve this when somebody submits such a draft for consideration.

If future work is going to be done in SIPREC then we need to make some decision on what this would be before too long.

Regards
Andy (SIPREC Co-Chair).

> Sent: 27 July 2012 13:05
> We discussed this on that NENA recording test committee call I
> mentioned. The consensus there was that this issue is complex enough
> that it would slow the siprec group's work down substantially. That
> group would rather see the existing protocol finalized, and see this
> mixed/unmixed media issue dealt with in a future version.
> 
> > Hmmm... perhaps this discussion should be future work? I'm not sure
> the group would want to get into something new that is potentially
> complex at this point.
> >
> Maybe we will have some time to discuss this as part of the
> architecture or protocol discussion. But maybe not - there isn't a lot
> of time.
> 
> >> I'm ok with the proposal Paul and Ram made, as long as we're all ok
> with the possibility that SRC vendors might offer only mixed, or
> conversely, only unmixed. Either could happen, but I suspect the "mixed
> only" option would be what we'd end up with - and that's the problem.
> The server doesn't even have a choice if that's all the SRC offers. It
> can only record mixed media.
> >>
> >> BTW, I looked at the current NENA 08-003 draft. It looks like we
> dropped the sentence we initially had about recording unmixed media,
> perhaps for the same reasons Paul and Ram have presented.
> >>
> >> I still would like to have some mechanism for the SRS to make its
> desire for mixed or unmixed known, and then say that it MAY be used,
> and the SRC MAY comply with the request. I think that's better than
> nothing.
> >
> communication framework we have defined so far, so it might require
> some significant changes.
> >
> > *no* opportunity for the SRS to indicate its preferences. And I've
> been led to believe its important that things work this way so that a
> >> I am accustomed to thinking that the choice to record mixed or
> unmixed media is made at time of placing a contract to purchase
> recording equipment.  That places no requirement to specify at
> recording time.
> >>
> >> IMHO, the SRC conference participant case is a non-issue. If an SRC
> is a participant in a Bridge, the "mixed" media coming from the Bridge
> is a single stream from its point of view, and an SRS that wanted
> unmixed media would only get whatever streams the SRC had.
> >>
> >> Now, I would like to see the possibility of the SRS dictating (or at
> least indicating a desire for) mixed or unmixed media, but if the
> majority disagree, I can live with that.
> >>
> committee I chair. Nine recording companies participate, and I'd like
> to see if that group thinks we should impose additional requirements
> for an SRC/SRS used in an NG9-1-1 environment. I don't personally think
> that Public Safety needs are different than private sector needs on
> this issue, but it's a good discussion to have now. If there were no
> mechanism for the SRS to make its mixed/unmixed desire known, we'd have
> a problem to solve. Perhaps this group could define such a mechanism
> without requiring that it be used?
> >>
> >>
> >> Thanks,
> >>
> >> Michael Smith
> >> Chief Technologist
> >>>>> Of if it is specific policy on SRC side, SRS still can have
> option
> >>>>> to mix if SRC always sends unmixed.
> >>>>>
> >>>>> What do you think?
> >>>>>
> >>>>>
> >>>>> Leon
> >>>>>