Subject: [AVT] RTP Packet Type Numbers

From: "Joe Kelsey" <[email-masked]>
Date: Thu, 21 Apr 2005 09:13:10 -0700

We are currently working on digital audio transport for airplane flight-deck audio.  Our plans include using a form of RTP to transmit the audio data between various interested parties in two different formats: 8kHz, 8-bit and 16KHz, 16-bit formats, modified for the flight-deck scenarios.

Our basic problem is that we want to simply have the various sources simply constantly transmit audio streams over the network without any session protocol.  As soon as power gets applied to the unit, it needs to transmit its assigned streams so that listeners can simply receive it.

This means that we want to use hardcoded packet type numbers in our RTP streams.  Currently we plan to use 77 for 8-bit, 8kHz audio and 78 for 16-bit, 16kHz audio streams.  RFC3551 says that we cannot do this but must rather use some sort of dynamic assignment protocol instead.  However, we need to operate in a very restricted network environment where we need to have strict controls over latencies and uncertainity, so we want to use fixed packet types.

Can we do this without violating any major rules?  What suggestions do you have about this general scheme?

Thanks.
/Joe

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: [email-masked]
Date: Fri, 22 Apr 2005 09:45:53 +0200

Joe,
your considered network domain is closed, thus, your RTP domain too from
perspective of RTP PT signaling codepoints.

A dynamic assignment (e.g., via any control/signaling/negotiation
protocols) is indeed here not necessary.

"Hardcoded" means a permanent assignment, - with the known disadvantages
with regard to network engineering.

An interim step, or more flexible approach is "provisioning". There are two
levels:

a) provisioning: meaning a configuration management action via a remote
element management system (EMS), or

b) pre-provisioning: meaning that the default settings are contained in a
local configuration file  (or data objects), i.e., configuration takes
place at system startup.

My recommendation would be to go with (b), which may be called
"quasi-static" and is very close to hardcoded, but seems to be fullfilling
your requirements and has the advantages:
- compliant to RFC 3551 (if you select the PTs from the dynamic PT range),
- more flexible, and
- future safe.

regards
Albrecht

                      "Joe Kelsey"                                                        
                      <KELSEY@avtcorp.         To:      <[email-masked]>                    
                      com>                     cc:                                        
                      Sent by:                 Subject: [AVT] RTP Packet Type Numbers     
                      avt-bounces@ietf                                                    
                      .org                                                                

                      21.04.2005 18:13                                                    

We are currently working on digital audio transport for airplane
flight-deck audio.  Our plans include using a form of RTP to transmit the
audio data between various interested parties in two different formats:
8kHz, 8-bit and 16KHz, 16-bit formats, modified for the flight-deck
scenarios.

Our basic problem is that we want to simply have the various sources simply
constantly transmit audio streams over the network without any session
protocol.  As soon as power gets applied to the unit, it needs to transmit
its assigned streams so that listeners can simply receive it.

This means that we want to use hardcoded packet type numbers in our RTP
streams.  Currently we plan to use 77 for 8-bit, 8kHz audio and 78 for
16-bit, 16kHz audio streams.  RFC3551 says that we cannot do this but must
rather use some sort of dynamic assignment protocol instead.  However, we
need to operate in a very restricted network environment where we need to
have strict controls over latencies and uncertainity, so we want to use
fixed packet types.

Can we do this without violating any major rules?  What suggestions do you
have about this general scheme?

Thanks.
/Joe