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

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

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

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

In general any thing that can learnt from SDP carried between SRC to SRS
is not carried again in metadata.
The SRS is expected to parse the SDP read the parameters, also parse the
XML that it received along with SDP and use both of the information
wherever applicable. For e.g; The metadata XML just carry the label
identifier that references a media stream. It points to a media line (m=
line) in SDP.
The SRS is expected to co-relate the label to its properties carried in
SDP. 

I will add some text for this in the section 4 where the current
text(above you pointed out) is there to give examples of what kind of
information can be derived (like the label to SDP properties).

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

I will leave the text for this as-is for now.

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