Setup using SP1 to regular VoIP service provider and SP4 as a proxy for a local SIP client. SP1 using ITSP profile A and SP4 using profile D. Preferred codec PCMA (higher priority).
When using an analog FXS port the call to/from the service provider is symetric (PCMA). Ok!
When called from SP1, proposing PCMA and G729, OBi202 sends INVITE to SP4, negotiates PCMA on the two sessions, but starts its RTP sessions using PCMU (80). Now both bridged sessions are using asymetric codecs, being receiving PCMA and xmitting PCMU as shown in the call status (and in the syslog).
Is this a feature, configuration error or a bug?
Firmware: 3.1.1 (Build: 5679EX)
I believe that this is a bug, which only applies to bridged calls. Here is an extract of a posting by me in 2014. It was in a "Beta Test" forum which is not available for all, so I can't simply post you to the original thread:
I have returned to this problem to try and give the simplest possible illustration of what goes wrong. Entirely within my own local router NAT I have set up as follows:
CSipSimple >>>> OBi1032 >>>> Phonerlite
The Local CSipSimple account and Phonerlite both have only CODEC G711A enabled. Any call from CSipSimple to Phonerlite using the OBi1032 as a bridge results in the caller not be able to hear the called party. See attached jpeg.
The call sets up correctly for a very short period using G711A for all four RTP paths, then for no reason that I can see the OBi1032 changes the RTP path to the calling party to G711U resulting in no transmission for that path. Analysis of the Wireshark log shows that in all of the "INVITE" messages and all of the "200 OK" messages G711A is the only CODEC that is offered, which is how it should be.
If the Local CSipSimple account and Phonerlite both have only CODEC G711U enabled, then the call is successful and the OBi1032 does not attempt to change any RTP path.
I have observed the same bug using OBi110s, but I don't have an OBi202 to test with.
Be careful with your testing. During a bridged call the codec negotiation takes place between the callee device and the called device, so the OBi in the middle may not be controlling the codecs used.
Thanks ianobi, That's what I thought so too.
But since you are referring that the problem might already exist almost 3 years, do you think there's a change that OBIHAI is going to fix this?
The problem might be even worse, because as you stated, the OBi202 is only bridging the sessions, not terminating, so the OBi should only suggest the codec(s) offered from the calling party to the callee. The strange part is that it also offers, albeit at the lowest priority, its preferred PCMU. Even disabling the PCMU codec on the OBi altogether it still starts its RTP sessions in PCMU.
I will inform their technical support and hope this might be an easy fix.
I can confirm that this issue was logged as a bug in 2014. It does not seem to have been addressed. I guess it's low priority as PCMU is often the preferred codec in North America where most OBi business is done. Also, the majority of calls are not bridged. However, bridging is one of the core functions of an OBi device so this needs to be fixed.
I happen to be in the UK, so like to use PCMA. Also, I use bridging on many calls, so I have an interest in this issue. It may move up the agenda as more North American people start to use other codecs such as G722. This issue will force at least one direction of speech to revert to PCMU on bridged calls.