Subject: [siprec] #21: consider the features of real time

From: "siprec issue tracker" <[email-masked]>
Date: Wed, 26 May 2010 06:54:39 -0000

#21: consider the features of real time
-------------------------------+--------------------------------------------
 Reporter:  zhouzp@…           |       Owner:  krehor@…        
     Type:  defect             |      Status:  new             
 Priority:  major              |   Milestone:                  
Component:  Requirements       |     Version:                  
 Severity:  -                  |    Keywords:                  
-------------------------------+--------------------------------------------
 We'd consider the features of real time since it is closely related to the
 quality.
 For example, if the big delay happens, the session should be dynamically
 negotiated and adjusted in time.
 Another, for the case of multiple participants,  it may need the mix of
 multiple media streams. Each particiapating client may support different
 media format and the media format that is used for the realtime
 communication may be different to the format to be recorded by server
 given the cost and efficiency for servers.
 Suggest to add two new requirements as following:
 "The mechanism MUST support dynamic adjustment on formats and bandwidths
 for transporting media."
 "The mechanism MUST support media transform in the media recording
 session."

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/siprec/trac/ticket/21>
siprec <http://tools.ietf.org/siprec/>

---

From: Peter Musgrave <[email-masked]>
Date: Wed, 26 May 2010 06:30:49 -0400

Hi,

I would have viewed the media format as something which is explicit in
the SDP negotiation. If the recording server advertises a number of
CODECs the sender is free to renegotiate on the fly. Also different
streams could elect to use different CODECs.

Since RTP is used I would not have though an explicit real time
requirement was needed. I view it as implicit in the use of RTP.

I also don't understand the statement about transforming media. From
what to what? My expectation is the recording server will be
supporting multiple CODECs and recording in some common internal
format - but that this 'back end' transformation is out of scope.

So while I agree with the ideas in this issue, I do not see them
requiring any new specific requirements in the draft.

Peter Musgrave

On Wed, May 26, 2010 at 2:54 AM, siprec issue tracker
<[email-masked]> wrote:
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 26 May 2010 09:04:58 -0400

> requirement was needed. I view it as implicit in the use of RTP.

+1

> format - but that this 'back end' transformation is out of scope.

There is no particular reason why it must be transformed into a common 
format. It could be recorded "raw" (though encrypted media should most 
likely be decrypted with the session keys before recording, even if 
re-encrypted for storage). In fact, recording "raw" may be expedient for 
recording that are made for legal reasons and often are not played back.

> requiring any new specific requirements in the draft.

+1

	Thanks,
	Paul