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

[Stephen Farrell <[e-mail]>]

Hiya,

(Noting these are non-blocking comments so we don't need
to debate 'em and you should feel free to just proceed...)

On 04/03/16 00:00, Ram Mohan R (rmohanr) wrote:
> 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.

Sure, but my question is more about how an SRC can know
what to not send. The text says the SRC can leave stuff
out "if it can be obtained contextually by the SRS" but
I don't know if the SRC can know what the SRS can "obtain
contextually."

> 
>>
>> - 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.

Hmm. It still seems to me that specifying some goal for
precision would be better, as otherwise it'll not be clear
how reliably one can re-construct the order of events. But
I guess that might be outweighed by inaccurate clocks on
the various devices so maybe it's good enough as-is.

Cheers,
S.


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