Jump to content

Jean Iles

Members
 View Profile  See their activity

  • Posts

    10

  • Joined

  • Last visited

 Content Type 

Posts posted by Jean Iles

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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

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

    in Trunk Setup

    Posted

    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.

×
×
  • Create New...