Jump to content

One-Way Audio On the ITSP trunk when restricting the codec to G.729


Jean Iles
 Share

Recommended Posts

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Based the traces received, the previous response still holds good :D . It is a codec mismatch issue.

 

I understood what you mentioned after I rechecked the rtp stream. :D

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

Link to comment
Share on other sites

I understood what you mentioned after I rechecked the rtp stream. :D

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.

Link to comment
Share on other sites

  • 2 weeks later...
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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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).

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...