Subject: [siprec] Persistent RS session with large set of CS info

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 26 Jan 2011 06:32:32 +0530

Leon/Henry,

The proposal of pre-negotiate large of m-lines in case SRC supports
large number of sessions is not a optimal solution for the following
reason:

1) Maintaining such a large number of m-line will be an architecture
challenge in as SRC would have maintained very few m-line till recording
feature is implemented. Let take  200 session supported in SRC then 400
m-lines has to be maintained in case of unmixed recording of audio for
two party call and 800 m-lines in case of recording unmixed audio &
video call for two party call. 

2) As John pointed out in another mail thread, it is not possible to
remove m-line once it is created in persistent RS.

3) SRC wastes its resources when the number of recording session is
lower. In case SRC performs lot more services apart from recording, huge
performance impact will be seen in SRC as the resources are pre-occupied
for persistent RS. 

In the earlier mail, I have proposed to create pre-allocated pool of
persistent RS for SRC which handle large number sessions. Each RS is
associated with one CS group (CSG) whenever CSG is created, RS is freed
from CSG when CSG is terminated and RS is re-used for another CSG later.
Here, persistent RS allocation/de-allocation is implementation-dependent
and the resource optimization is possible based on implementation.  

I agree that pre-negotiated persistent RS works for end-point which acts
as SRC and may work for SRC with few (2-5) sessions.

Please let me know your opinion here.

Thanks
Partha

Topic - Protocol (Henry Lum / Leon Portman)
draft-portman-siprec-protocol-02
================================================
Draft: https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
Slides: http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-
%20virtual%20interim%20Dec%2016%202010.pdf

Slide 4 (Persistent recording): Leon pointed out that the whole idea of
persistent recording is not to spend time negotiating m-lines when a CS
starts - so he prefers the second option on the slide. For SRCs that
support a large number of parallel CSs, the SRC could pre-negotiate a
large number of m-lines (perhaps based on licensing), rather like
provisioning trunks. Paul felt that the other option should be kept open
- a slight delay in negotiating a new m-line could be handled by
transmitting the data slightly delayed, without losing any. Henry also
mentioned the possibility of the offer-answer failing. It was questioned
whether there needs to be something in the protocol to indicate the
delay. This issue should be brought to the list.

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Jan 2011 08:24:37 +0100

I tend to agree with Partha's concerns on scalability. Perhaps separate persistent RSs would be preferable, rather than a single persistent RS with a large/huge number of pre-allocated m-lines. A persistent RS supporting more than 1 parallel CS might be feasible for a very small number of CSs, as might be encountered at a user's device, so it might be worth retaining the concept. Or we could say that an RS must not support more than one parallel CS, thereby forcing separate RSs for parallel CSs.

I am not sure I understand the need to bring CS-Group into the solution. Different CSs from the same CS-Group could use the same RS or different RSs - it shouldn't matter.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Parthasarathi R (partr)
> Sent: 26 January 2011 01:03
> To: [email-masked]; Leon Portman; Henry Lum
> Subject: [siprec] Persistent RS session with large set of CS info
> 
> Leon/Henry,
> 
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 26 Jan 2011 15:04:10 +0530

John,
 
Please read inline.
 
Thanks
Partha

________________________________

From: Elwell, John [mailto:[email-masked]]
Sent: Wed 1/26/2011 12:54 PM
To: Parthasarathi R (partr); [email-masked]; Leon Portman; Henry Lum
Subject: RE: Persistent RS session with large set of CS info

<Partha> we will discuss about this solution approach in detail during today's meeting and try to bring the closure </Partha>

<Partha> Sorry in case I confused. As you mentioned, there is no restriction w.r.t single CSG in single RS or single CSG in multiple RS and it does not matter. I just provided the example wherein each RS may use same CSG. </Partha>  

John (as individual)

---

From: Leon Portman <[email-masked]>
Date: Wed, 26 Jan 2011 14:37:29 +0200

There was no intent to limit number of m-lines per RS. It is more implementation decision to have one giant RS or multiple Rs blocks.

Leon

From: Parthasarathi R (partr) [mailto:[email-masked]]
Sent: Wednesday, January 26, 2011 11:34 AM
To: Elwell, John <[email-masked]>; [email-masked] <[email-masked]>; Leon Portman; Henry Lum <[email-masked]>
Subject: RE: Persistent RS session with large set of CS info

John,

Please read inline.

Thanks
Partha

John (as individual)

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Jan 2011 14:26:33 +0100

That is a decision we need to make - we would just need to consider the implications. For example, as soon as you allow >1 parallel CS on the same RS, you have to decide how to distinguish their metadatas, e.g., multiple body parts, multiple elements in the same XML body part. Not really a problem, just need to figure it out.

John (as individual)

> From: Leon Portman [mailto:[email-masked]] 
> Sent: 26 January 2011 12:37
> To: [email-masked]'; Elwell, John; [email-masked]'; 
> [email-masked]'
> Subject: Re: Persistent RS session with large set of CS info
> 
> There was no intent to limit number of m-lines per RS. It is 
> more implementation decision to have one giant RS or multiple 
> Rs blocks. 
> 
> Leon
>  
> 
> To: Elwell, John <[email-masked]>; 
> [email-masked] <[email-masked]>; Leon Portman; Henry Lum 
> <[email-masked]> 
> I tend to agree with Partha's concerns on scalability. 
> Perhaps separate persistent RSs would be preferable, rather 
> than a single persistent RS with a large/huge number of 
> pre-allocated m-lines. A persistent RS supporting more than 1 
> parallel CS might be feasible for a very small number of CSs, 
> as might be encountered at a user's device, so it might be 
> worth retaining the concept. Or we could say that an RS must 
> not support more than one parallel CS, thereby forcing 
> separate RSs for parallel CSs.
> 
> <Partha> we will discuss about this solution approach in 
> detail during today's meeting and try to bring the closure </Partha>
> 
> I am not sure I understand the need to bring CS-Group into 
> the solution. Different CSs from the same CS-Group could use 
> the same RS or different RSs - it shouldn't matter.
> 
> 
> <Partha> Sorry in case I confused. As you mentioned, there is 
> no restriction w.r.t single CSG in single RS or single CSG in 
> multiple RS and it does not matter. I just provided the 
> example wherein each RS may use same CSG. </Partha>  
> 
> John (as individual)
> 
> > Draft: 
> https://datatracker.ietf.org/doc/draft-portman-siprec-protocol/
> > Slides: 
> http://kenrehor.com/ietf/siprec/IETF79.1/SIPREC%20Protocol%20-

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 26 Jan 2011 19:22:25 +0530

My thoughts on this:

The metadata model and the format allows multiple CS [ any number of
them] within a single RS. The proposed XML schema of metadata can
accommodate multiple sessions(each with its XML part) and has the
mechanism to distinguish them.

I do agree that in case we have several CSs [ hundreds on them] the XML
would be huge and we will have to look for ways to compress the XML body
( which in my opinion should be outside the scope). IMO that is purely
implementation specific[ depending on how much each SRC can scale to
and also depends on the MTU of that network].

As such we should not restrict the number of CSs per RS. Probably we
should have some guidelines.

Ram

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Wednesday, January 26, 2011 6:57 PM
> To: Leon Portman; Parthasarathi R (partr); [email-masked]';
> Subject: Re: [siprec] Persistent RS session with large set of CS info
> 
> That is a decision we need to make - we would just need to consider
the
> implications. For example, as soon as you allow >1 parallel CS on the
> same RS, you have to decide how to distinguish their metadatas, e.g.,
> multiple body parts, multiple elements in the same XML body part. Not
> really a problem, just need to figure it out.
> 
> John (as individual)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 10:08:14 -0500

On 1/26/2011 8:26 AM, Elwell, John wrote:
> That is a decision we need to make - we would just need to consider the implications. For example, as soon as you allow>1 parallel CS on the same RS, you have to decide how to distinguish their metadatas, e.g., multiple body parts, multiple elements in the same XML body part. Not really a problem, just need to figure it out.

The metadata model currently reflects an assumption that you can have 
multiple CS and CS-Groups per RS. If there is some question about that, 
then please bring it up as an issue against the metadata model.

	Thanks,
	Paul

>> To: Elwell, John<[email-masked]>;
>> [email-masked]<[email-masked]>; Leon Portman; Henry Lum
>> detail during today's meeting and try to bring the closure</Partha>
>>
>> example wherein each RS may use same CSG.</Partha>
>>
>> John (as individual)
>>
>>> two party call and 800 m-lines in case of recording unmixed audio&

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 26 Jan 2011 17:00:38 +0100

Ram,

Yes, I tend to agree about not restricting the number of CSs per RS on the basis of metadata size, particularly in the light of discussions on the call about sending partial metadata. I think other considerations will deter the use of a single RS for a huge number of parallel CSs - I am thinking of the number of m-lines in the SDP and the fact that this is only allowed to increase and can never decrease.

John (as individual) 

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 26 January 2011 13:52
> To: Elwell, John; Leon Portman; Parthasarathi R (partr); 
> [email-masked]; [email-masked]
> Subject: RE: [siprec] Persistent RS session with large set of CS info
> 
> My thoughts on this:
> 
> > > > two party call and 800 m-lines in case of recording 
> unmixed audio
> &
> > > > 2) As John pointed out in another mail thread, it is 
> not possible
> > to
> > > > In the earlier mail, I have proposed to create 
> pre-allocated pool
> > of
> > > > persistent RS for SRC which handle large number 
> sessions. Each RS
> > is

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Wed, 26 Jan 2011 21:37:08 +0530

John/Ram,

As we discussed in the call, there is no need to restrict based on the
number of CS per RS. But there is an need for feedback mechanism (or
response code) from SRS to indicate that the maximum limit for number of
m-line or size of metadata is reached. 

Thanks
Partha

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Wednesday, January 26, 2011 9:31 PM
To: Ram Mohan R (rmohanr); Leon Portman; Parthasarathi R (partr);

Ram,

Yes, I tend to agree about not restricting the number of CSs per RS on
the basis of metadata size, particularly in the light of discussions on
the call about sending partial metadata. I think other considerations
will deter the use of a single RS for a huge number of parallel CSs - I
am thinking of the number of m-lines in the SDP and the fact that this
is only allowed to increase and can never decrease.

John (as individual) 

> I do agree that in case we have several CSs [ hundreds on them] the 
> XML would be huge and we will have to look for ways to compress the 
> XML body ( which in my opinion should be outside the scope). IMO that 
> is purely implementation specific[ depending on how much each SRC can 
> scale to and also depends on the MTU of that network].
> 
> > > There was no intent to limit number of m-lines per RS. It is more 
> > > implementation decision to have one giant RS or multiple Rs 
> > > blocks.
> > >
> > > Leon
> > >
> > >
> > > Perhaps separate persistent RSs would be preferable, rather than a

> > > single persistent RS with a large/huge number of pre-allocated 
> > > m-lines. A persistent RS supporting more than 1 parallel CS might 
> > > be feasible for a very small number of CSs, as might be 
> > > encountered at a user's device, so it might be worth retaining the

> > > concept. Or we could say that an RS must not support more than one

> > > parallel CS, thereby forcing separate RSs for parallel CSs.
> > >
> > > <Partha> we will discuss about this solution approach in detail 
> > > during today's meeting and try to bring the
> closure </Partha>
> > >
> > > I am not sure I understand the need to bring CS-Group into the 
> > > solution. Different CSs from the same CS-Group could use the same 
> > > RS or different RSs - it shouldn't matter.
> > >
> > >
> > > <Partha> Sorry in case I confused. As you mentioned, there is no 
> > > restriction w.r.t single CSG in single RS or single CSG in 
> > > multiple RS and it does not matter. I just provided the example 
> > > wherein each RS may use same CSG. </Partha>
> > >
> > > John (as individual)
> > >
> > > > challenge in as SRC would have maintained very few m-line till 
> > > > recording feature is implemented. Let take  200 session 
> > > > supported in SRC then 400 m-lines has to be maintained in case 
> > > > of unmixed recording
> > > of audio for
> > > > lower. In case SRC performs lot more services apart from 
> > > > recording, huge performance impact will be seen in SRC as the 
> > > > resources are pre-occupied for persistent RS.
> > > >
> > > > associated with one CS group (CSG) whenever CSG is created, RS 
> > > > is freed from CSG when CSG is terminated and RS is re-used for 
> > > > another CSG later.
> > > > Here, persistent RS allocation/de-allocation is 
> > > > implementation-dependent and the resource optimization is 
> > > > possible based on
> implementation.
> > > >
> > > > I agree that pre-negotiated persistent RS works for end-point 
> > > > which acts as SRC and may work for SRC with few (2-5) sessions.
> > > >
> > > > Slide 4 (Persistent recording): Leon pointed out that the whole 
> > > > idea of persistent recording is not to spend time negotiating 
> > > > m-lines when a CS starts - so he prefers the second option on 
> > > > the slide. For SRCs
> > that

> > > > mentioned the possibility of the offer-answer failing. It was 
> > > > questioned whether there needs to be something in the protocol 
> > > > to indicate
> the

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 26 Jan 2011 21:48:18 +0530

Feedback(new response code) from SRS could be one way to do this, but I
don't see a need to extend SIP error code for this purpose.
The other approach is the SRC itself determines the size of the message
has reached the threshold [ say based on the MTU of the network it is
in] and decide to spawn another RS to SRS. We could leave it to the
implementers and probably just have some guidelines.

Regards,
Ram

> From: Parthasarathi R (partr)
> Sent: Wednesday, January 26, 2011 9:37 PM
> To: Elwell, John; Ram Mohan R (rmohanr); Leon Portman;
[email-masked];
> [email-masked]
> response code) from SRS to indicate that the maximum limit for number
> of m-line or size of metadata is reached.
> 
> Thanks
> Partha
> 
more
> > > > To: Parthasarathi R (partr); [email-masked]; Leon Portman;
Henry
> > Lum
> > > > > 3) SRC wastes its resources when the number of recording
> session
> > is

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 11:41:46 -0500

> implementers and probably just have some guidelines.

Too many m-lines could be dealt with by a 488 response. (We might need a 
new Warn code.) This error would not be specific to siprec.

But it would be wise to avoid getting the error.

	Thanks,
	Paul

>>>> implications. For example, as soon as you allow>1 parallel
>>> CS on the
>>> closure</Partha>
>>>>> wherein each RS may use same CSG.</Partha>
>>>>>
>>>>> John (as individual)
>>>>>

---

From: "Henry Lum" <[email-masked]>
Date: Wed, 26 Jan 2011 13:29:15 -0800

Agreed; I don't think this error should be specific to siprec.

Henry

> Behalf Of Paul Kyzivat
> Sent: Wednesday, January 26, 2011 11:42 AM
> To: [email-masked]
> > Feedback(new response code) from SRS could be one way to do this,
but
> I
> >> the basis of metadata size, particularly in the light of
discussions
> > on
> >> will deter the use of a single RS for a huge number of parallel CSs
> -
> > I
no
> >>>>>> delay. This issue should be brought to the list.

-------------------------------------------------------------------------------------------------------------------
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: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 27 Jan 2011 05:57:53 +0530

Paul,
 
I agree with you that 488 with new warning code in the range of 308-329 will meet the requirement of rejecting too many m-line received in SDP and warning code has to be generic enough. This warning code *MAY* be used by other WG like CLUE(telepresence) as multiple m-line handling is a common issue.
 
413 response shall be used in case size of the metadata is too large. Please let me know your opinon here.
 
Thanks
Partha

From: [email-masked] on behalf of Henry Lum
Sent: Thu 1/27/2011 2:59 AM
To: Paul Kyzivat (pkyzivat); [email-masked]
Subject: Re: [siprec] Persistent RS session with large set of CS info

Henry

but
discussions
no

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 Jan 2011 23:06:34 -0500

I'm not certain about the 413 - I just haven't thought about it. Might 
be fine, or maybe something else is better.

On 1/26/2011 7:27 PM, Parthasarathi R (partr) wrote:
> Paul,
> I agree with you that 488 with new warning code in the range of 308-329
> will meet the requirement of rejecting too many m-line received in SDP
> and warning code has to be generic enough. This warning code *MAY* be
> used by other WG like CLUE(telepresence) as multiple m-line handling is
> a common issue.
> ------------------------------------------------------------------------
> *From:* [email-masked] on behalf of Henry Lum
> *Sent:* Thu 1/27/2011 2:59 AM
> *To:* Paul Kyzivat (pkyzivat); [email-masked]
> *Subject:* Re: [siprec] Persistent RS session with large set of CS info
>
> 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.
>