Subject: [siprec] Comments on draft-ietf-siprec-protocol-02

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 28 Feb 2012 14:54:44 +0200

Hi,

some comments on the protocol draft:
http://tools.ietf.org/html/draft-ietf-siprec-protocol-02

Section 4.1:
  s/the SRC wants record/the SRC wants to record/
  That section talks about using a single recording session to record
several communication sessions. Can a single recording session be used
to record several communication sessions that take place at the same
time (i.e., in parallel), or the communication sessions need to happen
one after another (i.e., sequentially)?

Section 5.1, 1st paragraph:
That paragraph includes two MUSTs. However, the important advice in the
paragraph seems to be the last sentence. Do we need those two MUSTs or
specifying what the last sentence says would be enough?

Section 5.2, 2nd paragraph:
The text talks about an SRS registering. Is it expected that SRSes
register in general?

Section 6.1, 2nd paragraph:
  s/a recorded stream is different than a CS stream/a recorded stream
can be different than a CS stream/

Section 6.2
What happens if the server becomes "not ready" while the stream is
inactive (because the client set it as inactive before)? The sever will
not be able to set the stream as inactive because it already is
inactive. Then, the client will not know about the server not being
ready and, consequently, will not look for alternative servers, which
would be ready.

Section 8.1.
When the draft is ready, remember that the definition of new media types
need to be reviewed by [email-masked].

Section 8.2
Fix this sentence:
   The metadata snapshot request is
   contained the content with the disposition type "recording-session".

Section 10.2.2
OLD:
   When the SRC receives the a=recordpref SDP in an SDP offer or answer,
   the SRC MAY choose to honor such request to record the request based
   on local policy on the SRC.

NEW:
   When the SRC receives the a=recordpref SDP in an SDP offer or answer,
   the SRC chooses to honor such request to record based on local
   policy on the SRC.

Cheers,

Gonzalo

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Feb 2012 09:04:54 -0500

Hi Gonzalo. Thanks for the review. I've commented inline of a few points.

	Paul

> one after another (i.e., sequentially)?

Yes. (to both)

> The text talks about an SRS registering. Is it expected that SRSes

AFAIK we take no position on that.
But its certainly possible that they could, to facilitate SRCs accessing 
them.

> can be different than a CS stream/

I guess you must understand this differently than I do.
As I conceive it, this statement is true as written.
Perhaps it could be changed as: s/different/distinct/

> ready and, consequently, will not look for alternative servers, which

I don't understand your point.

You are concerned with the SRS crashing - no longer able to handle sip 
signaling?

And you are worried about an inability to detect a crashed server while 
not recording anything? How is this different from any sip call on hold?

If the stream is inactive, then there will still be a need to exchange 
RTCP from time to time, and if that fails it would be a hint.

If that isn't sufficient, the SRC and/or the SRS can exchange some 
signaling from time to time just to test the otherwise idle connection. 
Session Timer can be used to drive this, though I usually state that UAs 
don't need Session Timer because they can do signaling whenever they 
wish. In any case this is basic UA behavior - nothing that needs to be 
specified as special for siprec.

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