I have a couple of questions concerning codec selection as it relates to LMR gateways and on the RMS.
* If a customer has set specific codec parameters on their LMR gateways (codec sampling rate / payload size, ect, LMR example config below); how do we configure the RMS to match these channel parameters? When creating and defining a channel within IPICS, there is only a selection for g.711 or g.729, however no other granularity is available to select specific codec parameters.
* When creating a VTG there is no codec selection available for the actual VTG multicast group. So if a fire multicast group is g.711 and a police multicast group if g.729; what will be the preferred selected codec for the new VTG ?
I know in H.323 there is a H.245 capabilities exchange between the endpoints to negotiate a preferred codec however since IPICS uses multicast; how is the codec selection being handled on the RMS and within VTG's.
I believe I have an understanding of the VTG codec selection process (2nd question - above) as its my understand that each channel (fire, police) as part of a VTG will have its own unique and associated voip dial peer participating in the VTG multicast group and its VTG voip dial peer will be defined with the same codec as the original channel codec.
Regarding my 1st question above; still not sure how a customer handles codec granularity (adjusting payload / sampling rate / header compress on the LMR) as the RMS would need to have the same codec specifics matching the LMR codec parameters for each channel (unless of course you define these manually on the RMS and disable the RMS comparator)
Page 67 in the IPICS 2.0 SRND mentions that you can use LMR rtp header compression (cRTP) and adjust the byte size for voice payloads; however how is this handled on the RMS ??
IPICS supports g711ulaw and g729a codecs.
The IPICS supported RMS configuration is set with: voice class codec 1 codec preference 1 g729r8 codec preference 2 g711ulaw
This is used as a baseline for codec cnfg in the RMS. Here is some detail regarding the configuration that IPICS does on the RMS to facilitate VTG configuration. If the Police channel is defined as 711 and Fire is defined as g729, when they are put in a VTG, you will see the following dial-peer cnfg:
ASSUME the following: Police: 188.8.131.52 Fire: 184.108.40.206 VTG Multicast Address Pool includes: 220.127.116.11
dial-peer voice 909290915 voip description #0/2/0:15#1176742575333# INUSE 16109 destination-pattern 199909290915 voice-class permanent 1 session protocol multicast session target ipv4:18.104.22.168:21000 codec g711ulaw no vad ! dial-peer voice 909291915 voip description #0/2/1:15#1176742575333# INUSE 16109 destination-pattern 199909291915 voice-class permanent 1 session protocol multicast session target ipv4:22.214.171.124:21000 codec g711ulaw no vad ! dial-peer voice 909290921 voip description #0/2/0:21#1176742575432# INUSE 16115 destination-pattern 199909290921 voice-class permanent 1 session protocol multicast session target ipv4:126.96.36.199:21000 codec g711ulaw no vad ! dial-peer voice 909291921 voip description #0/2/1:21#1176742575432# INUSE 16115 destination-pattern 199909291921 voice-class permanent 1 session protocol multicast session target ipv4:188.8.131.52:21000 no vad
As you can see, the multicast legs for Police as well as the VTG pool addresses are explicitly set to g711.
NOTE: The VTG Multicast call legs are always G711. Fire is NOT, therefore it will use the default g729r8 codec.
Regarding their current LMR config: The following command doesn't appear to be valid: g729br8 bytes 20ms 20 bytes
If it is in fact g729br8 bytes 20 then it looks to be the default config which doesn't need to be explicitly configured. This aligns with the IPICS g729 configuration as explained above.
The g711ulaw bytes 80 configuration they are using does not align with the IPICS g711 configuration. The default payload size is 160 bytes and that is what is used and tested with IPICS.
Regarding the latest question related to page 67 in the SRND, this discussion of bandwidth conservation is in the context of deployments involving WAN or other limiting factors where bandwidth becomes an issue. The sample cited is intended to describe how one would set up a dial peer that would be used to carry IPICS voice traffic across a WAN. It is not intended to imply that the standard codec configuration for IPICS server configured voice resources on an RMS can be changed.