Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03

[Magnus Westerlund <[e-mail]>]

On 2013-04-18 00:41, Kevin Gross wrote:
> Magnus,
> 
> Thanks for looking at this and sorry for the delay responding.
> 
> I agree that mediaclk-ext is too restrictive. Your suggestion is
> very accommodating  Something a bit more structured such as 'token "="
> byte-string' might be more appropriate. I will check with my co authors
> on this.

Sure.

> 
> As there is great precedent for it in SDP, we have implemented a simple
> offer-answer model. I would propose that systems should use the
> mechanisms defined in RFC 5939 if negotiation of clock configurations is
> necessary. Perhaps adding some discussion and a reference to this RFC
> would help.

Yes, there are precedence for simple models. However, I think yours are
over simplified and has unclear goals. Can you please comment on which
of the goals I discuss below that you see needs to be meet? I think a
purely declarative model would be better than what you have now, that
would at least allow the answer to say, I use X when X is different from
what is in the offer.

When it comes to CAPNEG that is clearly a possible road, but likely will
result that almost no one can actually determine your capability for
clock sources. Instead they will be stuck with the your current proposal.

I think even going to the model that the answer picks one for both out
of the offerers capabilities would be better. That would at least enable
the highest likelihood that both would use the same clocks.

> 
> I don't think that independently negotiating reference and media clocks
> as you have suggested will be adequate. Under some implementations,
> while multiple clocks are supported, certain combinations of media and
> reference clocks may not be allowed.

Okay, that is an additional requirement. Which, might not even work well
with CAPNEG. You will have two independent attributes that actually have
dependencies. What you say, you appear to indicate that from each side
you can have restrictions like this: This media-ref clock can only be
used given that your wall clock source is either of these.

Cheers

Magnus

> 
> Kevin Gross
> [phone]
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
> <http://www.X192.org>
> 
> 
> On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund
> <[e-mail] <mailto:[e-mail]>>
> wrote:
> 
>     Hi,
> 
>     I promised doing an review of the O/A section. I also found some other
>     issues to consider.
> 
>     1. Section 5.4:
> 
>     Figure 5 shows the ABNF [5] grammar for the SDP media clock source
>        information.
> 
>               mediaclk-master = "a=ssrc:" integer SP clk-master-id
> 
>               clk-master-id = "mediaclk:master-id=" master-id
> 
>               timestamp-mediaclk = "a=mediaclk:" mediaclock
> 
>               mediaclock = sender / refclk / streamid / mediaclock-ext
> 
>               sender = "sender" sender-ext
> 
>               sender-ext = token
> 
>               refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext]
> 
>               rate = [ SP "rate=" integer "/" integer ]
> 
>               direct-ext = token
> 
>               streamid = "master-id=" master-id
>               streamid =/ "IEEE1722=" avb-stream-id
>               streamid =/ streamid-ext
> 
>               master-id = EUI48
>               avb-stream-id = EUI64
> 
>               EUI48 = 5(2HEXDIG ":") 2HEXDIG
>               EUI64 = 7(2HEXDIG ":") 2HEXDIG
> 
>               streamid-ext = token
> 
>               mediaclock-ext = token
> 
>     I wonder if not the mediaclock-ext construction is to restrictive. As
>     the refclk produces a sting with white-spaces in it, why isn't other
>     mediaclock-ext allowed the same freedom? I think the mediaclock-ext can
>     be basically byte-string, i.e. any character allowed on an SDP line
>     should be possible to use. Likely the only resteriction should be that
>     it starts with a token. Thus using:
> 
>     mediaclock-ext = token [SP byte-string]
> 
>     This would require a token for identifying the method followed by a
>     space and then full freedom for anything that is allowed on an SDP
>     attribute value.
> 
> 
>     2. Section 6:
> 
>     Purpose of signalling?
> 
>     I think this type of signalling can select two levels of goals with
>     signalling:
> 
>     1) Declaring what each SDP O/A uses on its side
> 
>     2) Negotiating to arrive at the best but available mechanism on both
>     sides.
> 
>     The currently proposed solution does neither of these. It enables the
>     offerer to express to declare I intended to use X and for the answer to
>     say I know that, or simply say I can't tell you because we are not
>     having the same clocks.
> 
>     I think we need to be clear what our goals are here. And I will propose
>     some goals with the signalling based on my understanding of how these
>     defined timestamp reference clocks and media stream clocks can be used.
>     And we do need to be aware that different application may have different
>     needs.
> 
>     Goal with signalling:
> 
>     1. Enable each media sender to declare its actually used ts-refclk, i.e.
>     what clock is base for the RTCP SR NTP timestamps
>     2. Enable each media sender to identify what clock reference is used to
>     check/drive the media sampling, i.e. RTP timestamp advancement.
>     3. Enable two media sender using SDP O/A to determine what common clocks
>     they actually have so they can be used in either of ts-refclk or
>     mediaclk.
> 
>     The purpose of doing three (3) is really so that one can do the
>     following.
>     A. has three ts-refclk  it can use. B has two ts-refclk available. They
>     are going to watch social TV. To make it at all possible for the social
>     TV service to play out content at A and B in sync they need to have
>     either of these two things be available.
> 
>     a) Each has a common clock with the TV service
>     b) A and B has a common clock
> 
>     In either of the scenario the TV service will be able to ensure that the
>     media is played out is sync.
> 
> 
>     As a technical solution to these issues there are two main solution
>     tracks:
> 
>     1) Change the respective SDP attributes to provide info on all possible
>     clocks for that it could be using and let the answer select the most
>     preferred that both are supporting
> 
>     2) Leave the current SDP attributes as they are and only use them for
>     declaration that: I use this! Then add new SDP attributes to negotiate
>     the list of commonly supported clocks.
> 
>     At this stage I think 2) is what is simplest and require the least
>     changes to what already exist.
> 
>     I will note that this is likely to require a second round of O/A
>     messages to update used clocks if the arrived common clock(s) are not
>     the default used ones. But, I don't see a way around these. In SIP one
>     could use OPTIONS to provide a SDP which includes the negotiation
>     attribute to enable the other side to select using a clock that is
>     supported by both. But when that isn't done, it will take two rounds or
>     other a'priori knowledge.
> 
>     So my proposal is simply that one create two new SDP attributes one for
>     each type of clock usage (ts-refclk and mediaclk) and include a list of
>     clock type and any ID of the clock in a priority order. The O/A is basic
>     negotiated and the answer removes all clocks it doesn't support and adds
>     all it supports. Hopefully there is someone in the list that is common.
>     The highest priority between the two parties should be used when common
>     clock is required. IF that is not, then these attributes should not be
>     included. This for example allows one to use a common ts-refclk, but not
>     require common mediaclk. We should also discuss if the answerer may
>     change the priority of commonly supported, and if it should or should
>     not add additional clocks it supports that are not common.
> 
>     I really appreciate feedback on these comments and ideas.
> 
>     Cheers
> 
>     Magnus Westerlund
> 
>     ----------------------------------------------------------------------
>     Multimedia Technologies, Ericsson Research EAB/TVM
>     ----------------------------------------------------------------------
>     Ericsson AB                | Phone  [phone]
>     Färögatan 6                | Mobile [phone]
>     SE-164 80 Stockholm, Sweden| mailto: [e-mail]
>     <mailto:[e-mail]>
>     ----------------------------------------------------------------------
> 
>     _______________________________________________
>     Audio/Video Transport Core Maintenance
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/avt
> 
> 


-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------