630 - Add media type payload unassigned number 35 in format

[JTejedor]

Media type payload unassigned number 35 is being evaluated as media type payload dynamic range (96-127). Added some tests to verify these new changes on format_test

Currently, the video surveillance cameras of the bosch security branch offer rtsp with some peculiarities over the standard.
Instead of using the convenience media payload, which is usually 96, they use 35. This means that the camera format is not detected correctly.
This happens at least for the model FLEXIDOME IP starlight 8000i - 7.62.0003 (03500762)
There is an initial note on the first page of the document (manual) on how to use RTSP protocol in Bosch VIP cameras where it is specified that they use payload type 35 (https://community.boschsecurity.com/varuj77995/attachments/varuj77995/bt_community-tkb-video/241/1/RTSP%20usage%20with%20Bosch%20Video%20IP%20Devices.pdf).

The two examples of SDP extracted from the camera are:

• SDP Just h264

v=0
o=- 0 0 IN IP4 10.100.14.102
s=LIVE VIEW
c=IN IP4 0.0.0.0
t=0 0
a=control:rtsp://10.100.14.102:554/?inst=2&h26x=4
m=video 0 RTP/AVP 35
a=rtpmap:35 H264/90000
a=control:rtsp://10.100.14.102:554/?inst=2&h26x=4&stream=video
a=recvonly
a=fmtp:35 packetization-mode=1;profile-level-id=4d4029;sprop-parameter-sets=Z01AKY2NYDwBE/LgLcBDQECA,aO44gA==

• SDP for h264 and h265

v=0
o=- 0 0 IN IP4 10.100.14.102
s=LIVE VIEW
c=IN IP4 0.0.0.0
t=0 0
a=control:rtsp://10.100.14.102:554/?inst=1
m=video 0 RTP/AVP 35
a=rtpmap:35 H264/90000
a=rtpmap:102 H265/90000
a=control:rtsp://10.100.14.102:554/?inst=1&stream=video
a=recvonly
a=fmtp:35 packetization-mode=1;profile-level-id=4d4033;sprop-parameter-sets=Z01AM42NYB4AIfYC3AQ0BAg=,aO44gA==

Note: We already have some test on sdp_test.go with these examples but they are not uploaded, you may require them if you like

[aler9]

Hello, this is OK, but can you restrict the payload type to just 35 instead of the interval between 35 and 71? until now there's not reason to consider 36-71. If we find a reason, we will add it (together with a reference, like you did with the Bosh document). Thanks.

[JTejedor]

Hello, the changes have been made as you requested, only the media type 35 has been considered. The tests are still passing. Thank you very much for everything

[aler9]

i restricted payload type 35 to H264 and merged. Thanks.

[JTejedor]

Thanks for merge and sorry we didn't get exactly what you requested

[sirzooro]

Hi, this fix is not fully correct. RFC 3551 in section 3 allows to use other payload types for dynamic assignments too:

   This profile reserves payload type numbers in the range 96-127
   exclusively for dynamic assignment.  Applications SHOULD first use
   values in this range for dynamic payload types.  Those applications
   which need to define more than 32 dynamic payload types MAY bind
   codes below 96, in which case it is RECOMMENDED that unassigned
   payload type numbers be used first.  However, the statically assigned
   payload types are default bindings and MAY be dynamically bound to
   new encodings if needed.  Redefining payload types below 96 may cause
   incorrect operation if an attempt is made to join a session without
   obtaining session description information that defines the dynamic
   payload types.

My understanding is that application should use a=rtpmap attribute if present to discover dynamic assignment, and fallback to static assignments if a=rtpmap is missing. Bosch cameras send a=rtpmap attribute so fallback is not needed.

[aler9]

@sirzooro we are not using a fallback, if you take a look at the code we are extracting codec, clock and payload type from a=rtpmap. We're not assuming payload 35 to be H264.
Regarding additional payload types, if we find a hardware that forces us to use them, we'll add them.