Subject: [siprec] Question on draft-portman-siprec-protocol-01

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Jan 2011 10:07:43 +0100

In the requirements document we have the following requirement:
"REQ-005 The mechanism MUST support the ability to record a CS
   without an intentional loss of media (for example, clipping media at
   the beginning of the CS) and without impacting the quality or timing
   of the CS (for example, delaying the start of the CS while
   preparation for recording takes place).  See Use Case 4 in Section 5."
Use case 4 is "Persistent Recording".

Notwithstanding the current discussion on the wording of REQ-005, I would be curious to know how the protocol proposal addresses this "persistent recording" requirement. Cases where there are two or more CSs, in series and/or in parallel, for a given RS, do not seem to be covered in the protocol draft. The descriptions seem to assume that the initial INVITE request for the RS occurs at the same time as the initial INVITE request for the CS, and similarly for the BYE request. The only reference I could find was in section 5, which mentions REQ-004 (presumably a typo - should be REQ-005), but only in the context of having SDP with no m-lines when no CS has been started.

Assuming re-INVITEs would be used to signify the start or end of a CS, how are metadata and SDP media associated with particular CSs?

For example, are new m-lines introduced when a new CS starts? This would mean the number of m-lines would be constantly increasing until the SDP size would become unmanageable. This is because the offer-answer model forbids the removal of m-lines. Or would existing m-lines be reused for multiple CSs? Even then, an SRC that records a large number of CSs in parallel (e.g., a B2BUA) would generate very large SDPs. Moreover, the SDP will grow as the number of parallel CSs increases and can never shrink again, so over time the RS will be operating with a very large SDP even at times of low traffic.

Would the metadata for each CS be carried as a separate body part? This too would produce extremely large messages. Or is the assumption that a given SIP request would relate to a change in only a single CS, and therefore would only need to convey metadata for that one CS?

It is important to know what sort of solution we have in mind before we freeze the requirements document. If it is not feasible to meet REQ-005 using the protocol mechanism we have in mind, perhaps we need to reconsider REQ-005.

John (as individual)

---

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

John,

I completely agree with you in case m-line has to be added with each new
CS creation. So, adding m-line for CS is not the solution.

For UA, it is possible to create RS in advance and use it whenever CS is
created. This solution is sub-optimal but discussed during pre-IETF-78
interim meeting. For B2BUA, the pool of RS shall be created, RS will be
allocated to CSG  (CS group)  whenever CSG is created, RS will be freed
to pool whenever CSG is completed. Again it is sub-optimal solution as
lot of RS dialog will be idle.

In case RS is created after CS establishment, the initial media packets
in CS shall be buffered in SRC till RS is established and passed later
with the same delay towards SRS till the end of the session. Here, there
is a delay in recording and also more memory/CPU required in SRC to
queue the packets and dequeue packets.

Let us see any other better mechanism exists to solve this issue.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Wednesday, January 19, 2011 2:38 PM
To: [email-masked]
Subject: [siprec] Question on draft-portman-siprec-protocol-01

   preparation for recording takes place).  See Use Case 4 in Section
5."

Notwithstanding the current discussion on the wording of REQ-005, I
would be curious to know how the protocol proposal addresses this
"persistent recording" requirement. Cases where there are two or more
CSs, in series and/or in parallel, for a given RS, do not seem to be
covered in the protocol draft. The descriptions seem to assume that the
initial INVITE request for the RS occurs at the same time as the initial
INVITE request for the CS, and similarly for the BYE request. The only
reference I could find was in section 5, which mentions REQ-004
(presumably a typo - should be REQ-005), but only in the context of
having SDP with no m-lines when no CS has been started.

Assuming re-INVITEs would be used to signify the start or end of a CS,
how are metadata and SDP media associated with particular CSs?

For example, are new m-lines introduced when a new CS starts? This would
mean the number of m-lines would be constantly increasing until the SDP
size would become unmanageable. This is because the offer-answer model
forbids the removal of m-lines. Or would existing m-lines be reused for
multiple CSs? Even then, an SRC that records a large number of CSs in
parallel (e.g., a B2BUA) would generate very large SDPs. Moreover, the
SDP will grow as the number of parallel CSs increases and can never
shrink again, so over time the RS will be operating with a very large
SDP even at times of low traffic.

Would the metadata for each CS be carried as a separate body part? This
too would produce extremely large messages. Or is the assumption that a
given SIP request would relate to a change in only a single CS, and
therefore would only need to convey metadata for that one CS?

It is important to know what sort of solution we have in mind before we
freeze the requirements document. If it is not feasible to meet REQ-005
using the protocol mechanism we have in mind, perhaps we need to
reconsider REQ-005.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 19 Jan 2011 09:28:57 -0500

John,

While you aren't allowed to *remove* m-lines, they can be recycled.
I think there are a couple of different ways that persistent RS sessions 
can work, depending on the needs and capabilities of the SRC:

- The SRC could establish an RS *with* m-line(s) for media it expects
   will be used in CS sessions when they occur. When a CS does begin
   it can start sending media from the session on the negotiated ports.
   It can then also send metadata relating the m-lines to a CS. The
   metadata might arrive a bit later than the media. Not sure if that
   is a problem. This of course only accommodates anticipated media.
   If changes to codecs, etc. are required then it will require an o/a.

- The SRC could establish an RS with no m-lines. When the first CS
   begins, it could reinvite to do o/a with m-lines needed for the CS,
   and also with the corresponding metadata. (Not clear if this is any
   faster than establishing a new RS, but maybe.)

   When the CS ends, another reinvite can reject those m-lines (port
   zero) and include metadata indicating the end of the CS.

   When a subsequent CS begins, it can recycle the rejected m-lines,
   putting on new media types, codecs, labels, etc. and coordinating
   with new metadata for the new CS.

   Subsequent and additional CSs can use both strategies, adding new
   m-lines as needed and recycling old ones when possible.

- A combination of the above two approaches is also possible. The SRC
   could pre-negotiate some m-lines for types of media it anticipates
   may be needed for subsequent CSs and then assign them to a CS when
   appropriate, while adding new ones when necessary.

	Thanks,
	Paul

So, I would expect that in a persistent RS session you would start with 
no m-lines. Then when the first CS begins you would reinvite

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 19 Jan 2011 18:48:58 +0100

Yes, those seem to be the choices. I think the draft should cover some of this.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 19 January 2011 14:29
> To: [email-masked]
> Subject: Re: [siprec] Question on draft-portman-siprec-protocol-01
> 
> John,
> 
> > Notwithstanding the current discussion on the wording of 
> REQ-005, I would be curious to know how the protocol proposal 
> addresses this "persistent recording" requirement. Cases 
> where there are two or more CSs, in series and/or in 
> parallel, for a given RS, do not seem to be covered in the 
> protocol draft. The descriptions seem to assume that the 
> initial INVITE request for the RS occurs at the same time as 
> the initial INVITE request for the CS, and similarly for the 
> BYE request. The only reference I could find was in section 
> 5, which mentions REQ-004 (presumably a typo - should be 
> REQ-005), but only in the context of having SDP with no 
> m-lines when no CS has been started.
> >
> > Assuming re-INVITEs would be used to signify the start or 
> end of a CS, how are metadata and SDP media associated with 
> particular CSs?
> >
> > For example, are new m-lines introduced when a new CS 
> starts? This would mean the number of m-lines would be 
> constantly increasing until the SDP size would become 
> unmanageable. This is because the offer-answer model forbids 
> the removal of m-lines. Or would existing m-lines be reused 
> for multiple CSs? Even then, an SRC that records a large 
> number of CSs in parallel (e.g., a B2BUA) would generate very 
> large SDPs. Moreover, the SDP will grow as the number of 
> parallel CSs increases and can never shrink again, so over 
> time the RS will be operating with a very large SDP even at 
> times of low traffic.
> >
> > Would the metadata for each CS be carried as a separate 
> body part? This too would produce extremely large messages. 
> Or is the assumption that a given SIP request would relate to 
> a change in only a single CS, and therefore would only need 
> to convey metadata for that one CS?
> >
> > It is important to know what sort of solution we have in 
> mind before we freeze the requirements document. If it is not 
> feasible to meet REQ-005 using the protocol mechanism we have 
> in mind, perhaps we need to reconsider REQ-005.
> >
> > John (as individual)