Jean Iles

Yes, we have still 1-way audio. Lock-down option doesn't work. PBXNSIP is still switching the codecs to avoid the transcoding during the conversation. JI

I'm saying that PBXNSIP still trying to change the codec during conversation even with the lock down option is selected on the ports and trunk. My trunk is restricted to use G729. My IP phone has G711 and G729 in its codec list. When I make a call, PBXNSIP is strating to send the voice with the G711 to the IP phone then It is switching to G729 to avoid the trascoding when it see the codec restriction on the trunk. I'm expecting that when we select the codec lock down option on the trunk and in the ports, It should continue to use G711 and should make transcoding between two codec instead switching the G729. Otherwise, I don't understand the purpose of this option. Because we have same behaviour without this option as well. JI

Yes, PBXNSIP starts the rtp stream with the G.711 then it changes it to G.729. With the codec lock down, I'm expecting it will continue with the same codec which it uses at the begining. JI

As I told in my previous email, I selected lock option on both side. Also, I tried other combinations Thanks... JI

I replaced the pbxctrl.exe with the new one and I selected required options on the ports and trunk configuration page. Unfortunately, PBXNSIP is still trying to change the codecs during the early media. JI

Hi, I'm using Windows at the moment. Thanks... JI

I understood what you mentioned after I rechecked the rtp stream. As you told, PBXNSIP is switching between the codecs during the early media too. And the user agent cannot accommodate this transition. Is there any way to change this transition behavior on the PBXNSIP? Maybe it can switch to second codec which will avoid the transcoding after the 200 OK by locking down to one codec in the SDP . PS: Could you listen the voice stream which is coming from the PBXNSIP to the user agent with a rtp analyzer, it is looking that my software is not good solution as well to diagnose this type of problems? If yes please indicate the software vendor... Thanks... Regards, JI

I'm not using SRTP in my infrastructure. By the way, there is no problem on the ITSP. I also tried a different one. RTP stream which is coming from the ITSP has no problem, I checked it from the capture with a call analyzer. But the outgoing rtp stream to the user agent from the PBXNSIP, there is only a strange high frequency noise. As I told before, this behavior only happens when I restrict the trunk to G.729 and I select more than one codec on the user agent. If I'm not missing something, I'm almost sure that something is happening in the PBXNSIP with this configuration. In all scenarios, I don't face with any problem on the outgoing voice. Is there any one who try the same configuration? Regards, CI

I'm thinking that I have a different problem. Because I cannot hear the early media too. And early media is coming before the codec transition. So, it shouldn't be related with the user agent. As I told before, I captured the network traffic during my tests. And I listened the rtp stream with a call analyzer. There is only a terrible noise on the rtp stream which is coming from the PBXNSIP to the user agent. Thanks... JI

Hi Guys, I have a strange voice problem on my ITSP trunk. When I selected the G.729 codec to restrict the codec usage on the trunk, I faced with one way audio problem on outgoing calls which were using this trunk. When I don’t specify any codec on the trunk, there is no problem. After I made a lot of test and tried a lot of different configuration, I noticed that I can call from some of my internal clients. Then I detaily investigated the problem again and I saw a very strange behavior in my tests. You can find my test reults below. Trunk Codec | Client Codec | Result Only G.729a | G711.a,G729a | Failure. One-way Audio. Trunk side could hear the internal client.Internal client couldnot hear the trunk side. Only G.729a | G729.a,G711a | Failure. One-way Audio. Trunk side could hear the internal client.Internal client couldnot hear the trunk side. Only G.729a | Only G711a | Success. Two-way Audio. Only G.729a | Only G729a | Success. Two-way Audio. This is a common behavior for the following user agents. • Audiocodes Media Pack • Thomson 2030 When I tested this behavior with Eyebeam, I could successfuly call in all codec configuration. Then I realized that the eyebeam doesn’t send the SDP with the Invite and it is accepting the codec selection according to PBXNSIP. Is it a known problem? Thanks... Regards, Jean I.