Transcoding issues - explanation

[edwardforgacs]

Can someone please explain what the following log messages actually mean, and what the problem is caused by?

 

I have seen the packet size mismatch and different codec issues, but not this "cannot pass through" error. The device it is trying to pass through is a Quintum gateway and the codecs and packet sizes do match as indicated by the SIP messages.

 

[7] 2009/09/16 19:13:09: 7ef0d3f3@pbx#624788665: RTP pass-through mode

[7] 2009/09/16 19:13:09: 3c269b549362-jhbdc5ainorw#90c6c3ebc6: RTP pass-through mode

[7] 2009/09/16 19:13:11: Cannot pass through on 7ef0d3f3@pbx#624788665, falling back to transcoding

 

AND

 

[7] 2009/09/16 20:37:08: 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868: RTP pass-through mode

[7] 2009/09/16 20:37:08: 97e9242f@pbx#1291898535: RTP pass-through mode

[7] 2009/09/16 20:37:08: Cannot pass through on 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868, falling back to transcoding

[7] 2009/09/16 20:37:08: Cannot pass through on 97e9242f@pbx#1291898535, falling back to transcoding

[pbx support]

As you mentioned, when the packet size is different and/or negotiated codecs on either side of the call is different, then PBX will do the transcoding.

 

You can control this behaviour by setting the "Lock codec during conversation" under Admin->Settings->Ports page and the trunk page.

If you did not have this set, then the PBX pass the RTP using codec type that is negotiated on the outgoing call leg. Maybe PBX spits out the below log message in this case too, which may be confusing. We are cleaning up the log in the 4.0 version.

 

Can someone please explain what the following log messages actually mean, and what the problem is caused by?

 

I have seen the packet size mismatch and different codec issues, but not this "cannot pass through" error. The device it is trying to pass through is a Quintum gateway and the codecs and packet sizes do match as indicated by the SIP messages.

 

[7] 2009/09/16 19:13:09: 7ef0d3f3@pbx#624788665: RTP pass-through mode

[7] 2009/09/16 19:13:09: 3c269b549362-jhbdc5ainorw#90c6c3ebc6: RTP pass-through mode

[7] 2009/09/16 19:13:11: Cannot pass through on 7ef0d3f3@pbx#624788665, falling back to transcoding

 

AND

 

[7] 2009/09/16 20:37:08: 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868: RTP pass-through mode

[7] 2009/09/16 20:37:08: 97e9242f@pbx#1291898535: RTP pass-through mode

[7] 2009/09/16 20:37:08: Cannot pass through on 8b981f0f-180a-464e-95ea-76835e173d40@192.168.0.2#43bfd52868, falling back to transcoding

[7] 2009/09/16 20:37:08: Cannot pass through on 97e9242f@pbx#1291898535, falling back to transcoding

[edwardforgacs]

As you mentioned, when the packet size is different and/or negotiated codecs on either side of the call is different, then PBX will do the transcoding.

 

You can control this behaviour by setting the "Lock codec during conversation" under Admin->Settings->Ports page and the trunk page.

If you did not have this set, then the PBX pass the RTP using codec type that is negotiated on the outgoing call leg. Maybe PBX spits out the below log message in this case too, which may be confusing. We are cleaning up the log in the 4.0 version.

 

This doesn't make any sense. Are you saying that the log says "falling back to transcoding" when it isn't actually transcoding? If it is transcoding, *why* is it transcoding? We're in agreement that it isn't because of the packet size or codec, so what is the cause?

 

The "lock codec during conversation" wasn't set on this trunk, I have tried setting to see if it makes any difference. My understanding was that that setting influenced whether it would be able to negotiate a codec in the first place which isn't the problem here. The SIP packets clearly show that the same two codecs are accepted by both (PCMA and PCMU in that order), and both are using a packet size of 20ms.

 

I was wondering if the problem could be that PBXnSIP shows the codecs as e.g. a=rtpmap:8 PCMA/8000 whereas the gateway shows them as a=rtpmap:8 PCMA/8000/1 - i.. the extra /1. Is there possibly a bug where it thinks the codecs are different because of the different packet format?

[edwardforgacs]

I can confirm that setting "Lock codec during conversation" to true on the trunk fixed it, no transcoding messages.

 

I would just like to understand why that is necessary to avoid transcoding when the codecs match anyway.

 

A word of warning to others with regards to that setting though, if you force it to a codec which the other end doesn't support, and set "Lock codec during conversation" to yes, I have seen the situation where calls ring but refuse to connect due to incompatible codecs.

[pbx support]

I can confirm that setting "Lock codec during conversation" to true on the trunk fixed it, no transcoding messages.

 

I would just like to understand why that is necessary to avoid transcoding when the codecs match anyway.

 

A word of warning to others with regards to that setting though, if you force it to a codec which the other end doesn't support, and set "Lock codec during conversation" to yes, I have seen the situation where calls ring but refuse to connect due to incompatible codecs.

 

I would like to clarify the last paragraph - if the lock codec is set to 'yes' PBX will transcode the call when there are incompatible codecs on the either leg of the call. Only thing is that you have to select all the codecs on the PBX though (no restrictions on either the trunk level or the system level)