Compatibility fixes for PTP traceable in SDP and ST 2022-7 - #11
Conversation
Fixes failing test_02 and test_03 due to interpreting traceable as
gmid when encountering the following SDP attributes:
a=ts-refclk:ptp=IEEE1588-2008:00-20-D2-FF-FE-DC-47-BA:127
a=ts-refclk:ptp=IEEE1588-2008:traceable
A similar example can be found in ST 2110-10:2022, section 8.2.
Signed-off-by: Kenneth Klette Jonassen <kenneth@bridgetech.tv>
…arams
According to IS-05 v1.1.2, requests including transport_params must
have a matching number of legs as that specified in the constraints.
Under ST 2022-7 behaviour for the RTP transport type:
"In all cases, if a client request includes transport_params, it
MUST have the same number of array elements (or ‘legs’) as
specified in the constraints. If no changes are needed to a
specific leg it MUST be included as an empty object ({})."
Signed-off-by: Kenneth Klette Jonassen <kenneth@bridgetech.tv>
knneth
changed the title
|
Fixed in 2129fbe |
|
After rebasing on testing-IPMX locally, found there is a bug in commit 2129fbe: Failing IPMX-Sdp test_02 and test_03 description: SDP text: Note that signalling the traceable attribute is a SHALL in ST 2110-10 Section 8.2, so perhaps we should actually be failing senders that do not signal traceable in their SDP when the node clock is traceable. |
|
ST 2110 indicates Timestamp Reference Clock Signaling And RFC 7273 §4.8 does allow repeating ts-refclk at one level, but with two conditions: all entries at that level are assumed to be equivalent, and traceable time sources MUST NOT be mixed with non-traceable time sources at any given level. So the signaling is either "traceable" or "gmid:domain" not both simultaneously so " gets overriden when parsing the SDP line with traceable attribute" should not be an issue. Am I missing something ? |
|
Waiting for a decision of AIMS and VSF about the possibility to support both a traceable and a GMID declaration in the SDP. |
3 participants
See commit messages for details