Hi Scott, 

Thanks for the review. 

The model described in the draft is declarative and it is expected that the 
receiver will choose to adapt in the event that shared clocks are not 
available, or reject the offer. The SDP is expected to be used SIP offer/answer 
and also with protocols similar to SAP. The sender declares the set of 
reference and/or media clocks is using and the receiver signals back if there 
is an acceptable match. The receiver may choose to receive the stream even if 
some or all the clocks are not in fact shared (e.g. by receiving media without 
time synchronisation (section 6) or by using rate conversation for the media). 

If the senders' offer is rejected, that would mean that either the clocks are 
not shared, or the receiver is not prepared to adapt. In this case there is 
little prospect that the sender could usefully start over with a different set 
of reference and/or media clocks. 

I trust the above comments are clarifying. We kicked the offer/answer text 
around the WG a few times and I believe the text is comprehensible to those 
familiar with SDP. 

regards 
aidan 
____ 
:wq! 

----- Original Message -----

> From: "Scott Brim" <[email protected]>
> To: "draft-ietf-avtcore-clksrc all"
> <[email protected]>, "gen-art"
> <[email protected]>
> Sent: Tuesday, 14 January, 2014 5:20:23 AM
> Subject: GEN-ART LC review of draft-ietf-avtcore-clksrc-09

> I am the assigned Gen-ART reviewer for this draft. For background on
> Gen-ART, please see the FAQ at

> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

> Please resolve these comments along with any other Last Call comments
> you may receive.

> Document: draft-ietf-avtcore-clksrc-09
> Reviewer: Scott Brim
> Review Date: 2014-01-13
> IETF LC End Date: 2014-01-16
> IESG Telechat date: (if known)

> Summary: Ready with a minor issue

> Major issues:

> Minor issues:

> In 6.1.2 and 6.1.3: "If the answerer rejects the offer because the
> available reference clocks are incompatible, the rejection MUST
> contain at least one timestamp reference clock specification usable
> by
> the answerer." If the answerer suggests a clock that is not among
> those offered, what happens next? The offerer could abort, but could
> it start over and use what the answerer suggested? That's not
> documented -- is it obvious to those more familiar with SDP?

> Scott
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to