Re: [siprec] Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with DISCUSS and COMMENT)

["Ram Mohan R (rmohanr)" <[e-mail]>]

Hi Stephen,

See inline for some responses to your comments.

-----Original Message-----
From: Stephen Farrell <[e-mail]>
Date: Wednesday, 2 March 2016 at 4:38 PM
To: The IESG <[e-mail]>
Cc: "[e-mail]"
<[e-mail]>, Brian Rosen <[e-mail]>,
"[e-mail]" <[e-mail]>, Brian Rosen
<[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Stephen Farrell's Discuss on draft-ietf-siprec-metadata-20: (with
DISCUSS and COMMENT)

>----------------------------------------------------------------------
>COMMENT:
>----------------------------------------------------------------------
>
>
>
>- section 4, last para: How could an SRC know this and hence
>what it's safe to omit?

In this case the metadata that need not be conveyed are those that are
carried/derived from SIP headers/SDP. The SRC is a SIP element and always
sends the metadata in a SIP message (which has a SDP body as well). So the
SRC would know what it has sent in SIP/SDP.

>
>- 6.9: I would have thought that more precision about
>fractional seconds support would be useful here, or else, to
>just say that you're limiting to single-second granularity.
>Wouldn't doing one or the other be better?

We are not limiting to single-second. RFC3339 does allow fractional
seconds but its optional. OTOH, the sip Date header only allows
RFC822 time, which doesn't allow fractional seconds.

In many cases the date/time values going in the recording xml document
will be those
from the Date fields in the CS. So we may not be able to mandate SRC to
send fractional seconds.

Regards,
Ram

> Otherwise you
>might get different s/w ordering events in different orders
>unexpectedly.
>