10 Replies Latest reply on Nov 14, 2014 2:23 PM by gregstahl Branched to a new discussion.

    One-way Audio on Call Transfers

    bsands9 New Member

      I'm running AOS A5.02.00.E on a NV7100 and using Polycom 550's. When I try to transfer an incoming call to another extension, the transfer completes, but the caller who originated the original call can not hear any audio. There is audio going from the the call originator to the transfered extension however. Any ideas on how to fix this?

       

      Thanks,

      Brian

        • Re: One-way Audio on Call Transfers
          vgitechnology New Member

          Have you tried creating a Loop interface?

           

          1) Create interface Loop 1

          2) Assigning an IP address to it

          3) Make the media gateway primary Loop 1 on Vlan 1 and 2

           

          I've used this before to resolve one-way audio issues.

          • Re: One-way Audio on Call Transfers
            merbac New Member

            What kind of lines are you / they using?

            • Re: One-way Audio on Call Transfers
              Employee

              Thanks for jumping in with suggestions vgitechnology and merbac !  This is exactly what we want to see in the community!  Please keep it up.

               

              Brian – I saw that you ended up opening a ticket for this and the result was that a Quintum gateway was changing the codec being used in the middle of the call.  You were going to pursue forcing the G711 codec on the SIP trunk.  Here are the configuration instructions that were supplied:

               

              Configure a G711 only codec-list:

              NV7100#config t

              NV7100(config)#voice codec-list g711_only

              NV7100(config-codec)#codec g711ulaw

               

              After that, you will need to assign that codec list to the SIP trunk:

              NV7100(config)#voice trunk t01

              NV7100(config-T01)#codec-group g711_only

              I went ahead and marked this post as “Assumed Answered”.  If any of the responses on this thread assisted you, please mark them as either Correct or Helpful answers with the applicable buttons.  This will make them visible to help other members of the community find solutions more easily, as well as award points to the people that supplied helpful information. 

               

              Thanks,

              Matt

              • Re: One-way Audio on Call Transfers
                Employee

                I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily. If you don't feel like the answer I marked was correct, feel free to come back to this post and unmark it and select another in its place with the applicable buttons.  If you still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

                 

                Thanks,

                Matt

                  • Re: One-way Audio on Call Transfers
                    gregstahl New Member

                    Matt,

                    Do you know if the unit needs to be restarted after the codec lists are assigned to the trunk?  We're having the same issue and I added the list and assigned them to the trunk, made a test call and still had one-way audio.  I have to wait until the end of the day to restart the unit.

                     

                     

                    Thanks,

                    Greg

                      • Re: One-way Audio on Call Transfers
                        Employee

                        Greg,

                         

                        The changes are live.  You may be having a separate issue if that did not resolve the problem. Depending on what is really going on sometimes a blind transfer will work instead of an assisted transfer. That would be an interesting data point to know.  Also, make sure your IP phones are running the minimum required version of firmware that corresponds to the release notes for the version of chassis firmware being used on the NetVanta 7100.  There is a dedicated section in the release notes that detail this information. Problems like this usually require getting a debug voice verbose, debug sip stack messages, and a debug isdn l2-formatted (if using a PRI) all enabled at the same time while the issue is recreated to track down the problem unless you can have the provider debug a call from their side to identify the issue.  If the provider is unable to help and you can collect the debugs and the current configuration and upload them to the FTP server from the instructions below, I would be happy to take a look.

                         

                        Open Internet Explorer web browser on their PC
                        Type the following URL:  ftp://ftp.adtran.com

                        Press the Alt key, click View, and then click Open FTP Site in Windows Explorer

                        Double-click the "Incoming" folder
                        Drag and drop files from PC into the Internet Explorer window

                        Reply to this post with the exact filenames used so we can retrieve the files

                         

                        Thanks,

                        Matt

                          • Re: One-way Audio on Call Transfers
                            gregstahl New Member

                            Thanks Matt, this is actually on a TA912 (SIP to PRI).  I'm doing a stare and compare with a working config that we have at another site and found the codec list were in the config, just not assigned to the trunks.  I also found on the PRI Interface "role network b-channel-restarts disable" on the problem TA912 and not on the working TA912.  I tried removing it with no, but got command unrecognized.  The AOS is A4.11.00.  Do you know if the "role" command would have an impact on one way audio?

                             

                            I'm going to run some debug Monday.

                             

                            Thanks for your help.

                             

                            Greg