Re: [AVT] RTP Packet Type Numbers

[Albrecht.Schwarz at alcatel.de]

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 at avtcorp.         To:      <avt at ietf.org>                    
                      com>                     cc:                                        
                      Sent by:                 Subject: [AVT] RTP Packet Type Numbers     
                      avt-bounces at 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



_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt





_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt