Subject: [siprec] Limiting the scope - voice only?

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 08:27:19 +0200

One possible way in which we could limit the scope would be by restricting initial deliverables to voice, whilst trying not to do anything that would prevent the addition of support for other media types later. Is voice the most pressing requirement, and if so, could we restrict initial deliverables to voice, and would this result in a significant reduction in work?

John

---

From: Nathan Kryger <[email-masked]>
Date: Tue, 20 Apr 2010 23:34:21 -0700 (PDT)

I think voice is the most valuable initial deliverable and is probably why most are involved with this project but I am not sure if it significantly reduces the amount of effort.  There are certainly some aspects of this that seem more specific to voice such as questions about media mixing and codec negotiation.  If it appears that delivering the spec for voice first will be less effort than I would support that.  I have been discussing proposals like this with various vendors for a number of years now so I am excited to see some work at creating a standardized method of accomplishing this.  If you want to see increased list activity than clearly state which areas you feel need some more work so we can openly discuss it.

Nathan

________________________________
From: "Elwell, John" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: Tue, April 20, 2010 11:27:19 PM
Subject: [siprec] Limiting the scope - voice only?

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

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Tue, 20 Apr 2010 23:39:47 -0700

There are definitely some simplifications we can make. By restricting to
audio it postpones the decisions about how to handle other media types
(and protocols) such as IM and chat sessions.

We would still need to handle multiple m-lines in the Recording Server
INVITE (one audio stream from each endpoint) though it could simplify
dealing with multiple media types (audio and video). 

The details surrounding end-user notification might be restricted for
the first version. Setting clear, narrow boundaries around these kind of
complex requirements will be necessary to getting a first version out in
a reasonable time -- not only for the spec, but also testing effort for
interop.

Ken

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Tuesday, April 20, 2010 11:27 PM
> To: [email-masked]
> One possible way in which we could limit the scope would be by
> restricting initial deliverables to voice, whilst trying not to do
> anything that would prevent the addition of support for other media
> types later. Is voice the most pressing requirement, and if so, could
> we restrict initial deliverables to voice, and would this result in a
> significant reduction in work?
> 
> John

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 08:56:03 +0200

Nathan,

Thanks for your input. See below.

> From: Nathan Kryger [mailto:[email-masked]] 
> Sent: 21 April 2010 07:34
> To: Elwell, John; [email-masked]
> Subject: Re: [siprec] Limiting the scope - voice only?
> 
> I think voice is the most valuable initial deliverable and is 
> probably why most are involved with this project but I am not 
> sure if it significantly reduces the amount of effort.  There 
> are certainly some aspects of this that seem more specific to 
> voice such as questions about media mixing and codec 
> negotiation.  If it appears that delivering the spec for 
> voice first will be less effort than I would support that.  I 
> have been discussing proposals like this with various vendors 
> for a number of years now so I am excited to see some work at 
> creating a standardized method of accomplishing this.  If you 
> want to see increased list activity than clearly state which 
> areas you feel need some more work so we can openly discuss it.
[JRE] I think I already did that when I entered a number of issues into the issue tracker. Addressing those issues would be an excellent start, and would help the authors revise their drafts.

John (as chair)

> One possible way in which we could limit the scope would be 
> by restricting initial deliverables to voice, whilst trying 
> not to do anything that would prevent the addition of support 
> for other media types later. Is voice the most pressing 
> requirement, and if so, could we restrict initial 
> deliverables to voice, and would this result in a significant 
> reduction in work?
> 
> John

---

From: Leon Portman <[email-masked]>
Date: Wed, 21 Apr 2010 09:57:13 +0300

I agree that restricting to voice will reduce the required work but it will not limit number of the use cases. If we want to reduce it as well, we can consider limiting first phase scope only to dynamic recording mode and also to only Recording Client initiated recording. However it will be very important if we manage to map all modes from the beginning in order to validate all flows.

Leon
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ken Rehor (krehor)
Sent: Wednesday, April 21, 2010 9:40 AM
To: Elwell, John; [email-masked]
Subject: Re: [siprec] Limiting the scope - voice only?

Ken

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 09:21:24 +0200

Ken,

Thanks. It would be good if, in revising the requirements draft, you could give some consideration how to document requirements for first phase deliverables, versus considerations for future phases.

John 

> From: Ken Rehor (krehor) [mailto:[email-masked]] 
> Sent: 21 April 2010 07:40
> Subject: RE: [siprec] Limiting the scope - voice only?
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 22 Apr 2010 09:11:46 -0700

I don't see any advantage to limiting this to voice only. If this works cares if the RTP is voice, or video, it seems like we are probably dong something wrong. For starting mid stream, you get the RTP after the time you started so if was video, you can't play it back to the next iframe - I fine with leaving things about optimization of particular media formats out of scope.

> One possible way in which we could limit the scope would be by restricting initial deliverables to voice, whilst trying not to do anything that would prevent the addition of support for other media…

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: "Ken Rehor (krehor)" <[email-masked]>
Date: Thu, 22 Apr 2010 09:18:03 -0700

We're looking at a variety of ways to phase capabilities in over time in
order to produce something useful in a reasonable timeframe. 

One possible strategy is to specifically focus on RTP-based media.  This
would give us audio, video and text conversations (possibly using
RFC4103 http://tools.ietf.org/html/rfc4103).

Ken Rehor

> Behalf Of Cullen Jennings (fluffy)
> Sent: Thursday, April 22, 2010 9:12 AM
> To: Elwell, John
> Cc: [email-masked]
> I don't see any advantage to limiting this to voice only. If this
works
> cares if the RTP is voice, or video, it seems like we are probably
dong
> something wrong. For starting mid stream, you get the RTP after the
> time you started so if was video, you can't play it back to the next
> iframe - I fine with leaving things about optimization of particular
> media formats out of scope.
> 
>

---

From: Alan Johnston <[email-masked]>
Date: Thu, 22 Apr 2010 12:17:57 -0500

+1

- Alan -

---

From: "Henry Lum" <[email-masked]>
Date: Thu, 22 Apr 2010 10:55:16 -0700

I agree that we should focus on RTP-based media so that the requirements
don't need spell out all the media payloads. 

Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Ken Rehor (krehor)
Sent: Thursday, April 22, 2010 12:18 PM
To: [email-masked]
Subject: Re: [siprec] Limiting the scope - voice only?

Ken Rehor

works
dong

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

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 22 Apr 2010 14:34:23 -0400

n++

Peter Musgrave

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 22 Apr 2010 14:58:42 -0500

+1

James

At 12:17 PM 4/22/2010, Alan Johnston wrote:
> works cares if the RTP is voice, or video, it seems like we are 
> probably dong something wrong. For starting mid stream, you get the 
> RTP after the time you started so if was video, you can't play it 
> back to the next iframe - I fine with leaving things about 
> optimization of particular media formats out of scope.
> >
> >
> types later. Is voice the most pressing requirement, and if so, 
> could we restrict initial deliverables to voice, and would this 
> result in a significant reduction in work?
> >>
> >> John

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Apr 2010 22:52:40 +0200

Cullen,

The discussion has moved on a bit since then, as Ken pointed out. I am trying to limit the scope to something achievable in 1 year, and from the people I have spoken to it seems there might be mileage in limiting to RTP, without precluding RTP-based media other than voice but not necessarily doing all that is necessary to support those other RTP-based media fully, e.g., optimisations.

John 

> From: Cullen Jennings [mailto:[email-masked]] 
> Sent: 22 April 2010 17:12
> To: Elwell, John
> Cc: [email-masked]
> I don't see any advantage to limiting this to voice only. If 
> this works cares if the RTP is voice, or video, it seems like 
> we are probably dong something wrong. For starting mid 
> stream, you get the RTP after the time you started so if was 
> video, you can't play it back to the next iframe - I fine 
> with leaving things about optimization of particular media 
> formats out of scope.
> 
>

---

From: "Jain, Rajnish" <[email-masked]>
Date: Fri, 23 Apr 2010 08:46:26 -0400

+1

The solution should be agnostic to the type of media being carried in RTP.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alan Johnston
> Sent: Thursday, April 22, 2010 1:18 PM
> To: [email-masked]
> > I don't see any advantage to limiting this to voice only. If this works
> cares if the RTP is voice, or video, it seems like we are probably dong
> something wrong. For starting mid stream, you get the RTP after the time you
> started so if was video, you can't play it back to the next iframe - I fine
> with leaving things about optimization of particular media formats out of
> scope.
> >
> >
> restricting initial deliverables to voice, whilst trying not to do anything
> that would prevent the addition of support for other media types later. Is
> voice the most pressing requirement, and if so, could we restrict initial
> deliverables to voice, and would this result in a significant reduction in
> work?
> >>
> >> John

DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 10:04:50 -0400

+1
Audio vs. video vs. Real-time-text shouldn't matter, although limiting it to just RTP seems reasonable.  I think the concern was more on non-RTP stuff, like IM (MSRP) or T.38 fax.

-hadriel

> Of Jain, Rajnish
> Sent: Friday, April 23, 2010 8:46 AM
> To: Alan Johnston; [email-masked]
> Of
> anything
> DISCLAIMER: This e-mail may contain information that is confidential,
> privileged or otherwise protected from disclosure. If you are not an
> intended recipient of this e-mail, do not duplicate or redistribute it by
> any means. Please delete it and any attachments and notify the sender that
> you have received it in error. Unintended recipients are prohibited from
> taking action on the basis of information in this e-mail.E-mail messages
> may contain computer viruses or other defects, may not be accurately
> replicated on other systems, or may be intercepted, deleted or interfered
> with without the knowledge of the sender or the intended recipient. If you
> are not comfortable with the risks associated with e-mail messages, you
> may decide not to use e-mail to communicate with IPC. IPC reserves the
> right, to the extent and under circumstances permitted by applicable law,
> to retain, monitor and intercept e-mail messages to and from its systems.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 23 Apr 2010 11:22:47 -0400

++

Video MUST be considered but should be covered with John's restriction (or reduction in scope) to consider only RTP-based media

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 23 Apr 2010 17:46:27 +0200

Yup, I agree with that

-- 
Victor Pascual Ávila

---

From: zhipeng zhou <[email-masked]>
Date: Sat, 24 Apr 2010 15:12:50 +0800

+ 1
Generally the multimedia capability is required and quality of media may be
not too high.

-----Original Message-----
From: Gonzalo Salgueiro [mailto:[email-masked]] 
Sent: Friday, April 23, 2010 11:23 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [siprec] Limiting the scope - voice only?

++

Video MUST be considered but should be covered with John's restriction (or
reduction in scope) to consider only RTP-based media

On Apr 23, 2010, at 10:04 AM, Hadriel Kaplan wrote:

> 
> +1
> Audio vs. video vs. Real-time-text shouldn't matter, although limiting it
to just RTP seems reasonable.  I think the concern was more on non-RTP
stuff, like IM (MSRP) or T.38 fax.
>> Behalf Of Jain, Rajnish
>>> Behalf
>>> dong something wrong. For starting mid stream, you get the RTP after 
>>> the time
>> you
>>> started so if was video, you can't play it back to the next iframe - 
>>> I
>> fine
>>> with leaving things about optimization of particular media formats 
>>> out
>> of
>>> scope.
>>>> 
>>>> 
>>> reduction
>> in
>> intended recipient of this e-mail, do not duplicate or redistribute 
>> it by any means. Please delete it and any attachments and notify the 
>> sender that you have received it in error. Unintended recipients are 
>> prohibited from taking action on the basis of information in this 
>> e-mail.E-mail messages may contain computer viruses or other defects, 
>> may not be accurately replicated on other systems, or may be 
>> intercepted, deleted or interfered with without the knowledge of the 
>> sender or the intended recipient. If you are not comfortable with the 
>> risks associated with e-mail messages, you may decide not to use 
>> e-mail to communicate with IPC. IPC reserves the right, to the extent 
>> and under circumstances permitted by applicable law, to retain, monitor
and intercept e-mail messages to and from its systems.