Jean Iles Posted February 19, 2009 Report Share Posted February 19, 2009 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. Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 19, 2009 Report Share Posted February 19, 2009 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. We have seen this behavior in couple of instances. Here, in order to avoid transcoding, PBX uses G729a on both directions (remember, the phone has advertised that it can do G729a). But the phones do not switch to the codec that is seen on the RTP. If the phone can switch after change in the RTP from G711 to G729a, we will not have this problem. I think very few phones can do that now (snom is one of them I believe). So what PBX is doing is complaint to the protocol. Unfortunately, many phones are still behind on this. Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted February 20, 2009 Author Report Share Posted February 20, 2009 We have seen this behavior in couple of instances. Here, in order to avoid transcoding, PBX uses G729a on both directions (remember, the phone has advertised that it can do G729a). But the phones do not switch to the codec that is seen on the RTP. If the phone can switch after change in the RTP from G711 to G729a, we will not have this problem. I think very few phones can do that now (snom is one of them I believe). So what PBX is doing is complaint to the protocol. Unfortunately, many phones are still behind on this. 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 20, 2009 Report Share Posted February 20, 2009 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. Terrible noise is usually a problem with SRTP. There is a flag for the trunk where the PBX can send only 180 without SDP to the carrier. Some carriers cannot deal with early media! Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted February 20, 2009 Author Report Share Posted February 20, 2009 Terrible noise is usually a problem with SRTP. There is a flag for the trunk where the PBX can send only 180 without SDP to the carrier. Some carriers cannot deal with early media! 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 Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 20, 2009 Report Share Posted February 20, 2009 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 Is it possible for you to send the pcap trace file to support@pbxnsip.com? Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 20, 2009 Report Share Posted February 20, 2009 Is it possible for you to send the pcap trace file to support@pbxnsip.com? Based the traces received, the previous response still holds good . It is a codec mismatch issue. Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted February 20, 2009 Author Report Share Posted February 20, 2009 Based the traces received, the previous response still holds good . It is a codec mismatch issue. 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted February 21, 2009 Report Share Posted February 21, 2009 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 . We will introduce a flag that will lock down the codec one it has been determined. Even at the price of later transcoding. Quote Link to comment Share on other sites More sharing options...
pbx support Posted February 21, 2009 Report Share Posted February 21, 2009 We will introduce a flag that will lock down the codec one it has been determined. Even at the price of later transcoding. Jean, Let's know what OS you are using. We can provide a special version for you that fixes this problem Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 5, 2009 Author Report Share Posted March 5, 2009 Jean, Let's know what OS you are using. We can provide a special version for you that fixes this problem Hi, I'm using Windows at the moment. Thanks... JI Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 6, 2009 Report Share Posted March 6, 2009 Hi, I'm using Windows at the moment. Thanks... JI You can download http://www.pbxnsip.com/protect/pbxctrl-3.3.0.3157.exe. There are 2 places that you can set "Lock codec during conversation" One is at Admin->Settings->Ports page and other is at the trunk page. If you set both settings 'on', then the codec problem should go away Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 11, 2009 Author Report Share Posted March 11, 2009 You can download http://www.pbxnsip.com/protect/pbxctrl-3.3.0.3157.exe. There are 2 places that you can set "Lock codec during conversation" One is at Admin->Settings->Ports page and other is at the trunk page. If you set both settings 'on', then the codec problem should go away 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 Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted March 11, 2009 Report Share Posted March 11, 2009 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. Try locking the codec both on the trunk and in the Ports section. Maybe the restriction in the trunk is not enough (maxbe that option is kind of superfluous). Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 11, 2009 Author Report Share Posted March 11, 2009 Try locking the codec both on the trunk and in the Ports section. Maybe the restriction in the trunk is not enough (maxbe that option is kind of superfluous). As I told in my previous email, I selected lock option on both side. Also, I tried other combinations Thanks... JI Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 11, 2009 Report Share Posted March 11, 2009 As I told in my previous email, I selected lock option on both side.Also, I tried other combinations Thanks... JI What do you mean by Unfortunately, PBXNSIP is still trying to change the codecs during the early media?. As long as the UA(phone) and the PBX are using the same codec, you should not have any issue. Wireshark RTP trace will tell you the exact codec that is used on both direction. Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 12, 2009 Author Report Share Posted March 12, 2009 What do you mean by Unfortunately, PBXNSIP is still trying to change the codecs during the early media?. As long as the UA(phone) and the PBX are using the same codec, you should not have any issue. Wireshark RTP trace will tell you the exact codec that is used on both direction. 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 Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 12, 2009 Report Share Posted March 12, 2009 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 There is a possibility that one leg of the call is G711 and the other is G729. But incoming and outgoing of each leg will be of the same codec. Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 13, 2009 Author Report Share Posted March 13, 2009 There is a possibility that one leg of the call is G711 and the other is G729. But incoming and outgoing of each leg will be of the same codec. 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 Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 13, 2009 Report Share Posted March 13, 2009 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 Ok. PBX is not supposed to do that. It is supposed to do G711 to the phone and g729 to the trunk, if the "lock codec.. " is set. If I understand correctly, you still have 1-way audio. Is that right? Quote Link to comment Share on other sites More sharing options...
Jean Iles Posted March 15, 2009 Author Report Share Posted March 15, 2009 Ok. PBX is not supposed to do that. It is supposed to do G711 to the phone and g729 to the trunk, if the "lock codec.. " is set. If I understand correctly, you still have 1-way audio. Is that right? 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 Quote Link to comment Share on other sites More sharing options...
pbx support Posted March 16, 2009 Report Share Posted March 16, 2009 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 While we are looking at this issue in detail (because after the previous software change, we have got the response from other customers that the problem has been fixed), can you send the latet wireshark trace (SIP/RTP) to support@pbxnsip.com? Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.