BARIX Instreamer Manual do Utilizador descarregar pdf (Página 35)

Technical Documentation “Instreamer “ - V4.03 - 24th October 2013

RTP encoding RTP Header Extension Protocol

The contact closure information is included in an RTP Header extension and transmitted with the audio data.

A general syntax is used which is a very simplified form of ASN.1. Objects transferred have: Type, length and data.

For this implementation only the contact closure object is supported and this has Type=1 and fixed length 4.

The data comprises a 16bit Mask followed by a16bit contact closure value.

It is best illustrated by an example of the data transferred in the RTP header:

• 00 01 --------- Defined by profile (ignored)

• 00 03 --------- RTP Extension length 3 (4 byte words)

• FF 00 -------- Sub Header. This defines a type (in this case FF) and sub header length (in this case 0)

• 01 04 00 ------ Signal payload type (in this case 1 for GP) and length(4 bytes)

• 1E 00 0C 00 -- The payload: mask(001E) value(000C).

• 00 00 00 ------ Filler for 3rd 4byte word

This protocol is general purpose where the contact closures could refer to either GPIs at the sending device or GPOs at the receiver.

For the Instreamer the contact closures are inputs so the example shows GPIs 1-4 being monitored and Inputs 2 and 3 currently active.

3.4 RTP Audio types

The following table defines how audio formats are mapped onto RTP payload types

Payload types 0, 8, 10, 11 and 14 are defined by the RTP standard. Barix defines assignment for payload types 96 to 112 (dynamic payload types) in

the above tables. The generic type allows an end to end agreement of types not in the list. This is just provided for completeness since all the

Instreamer audio formats are mapped onto payload types.

35 General Interfaces General Interfaces 35

1 2 ... 30 31 32 33 34 35 36 37 38 39

Sem comentários

BARIX Instreamer Manual do Utilizador Página 35