UC320 - No audio with transferred and call-divert calls to external phones

[rakinonz1]

Hi,

We have a UC320 on-site behind a site router.

Internal extensions can make outgoing calls no problem.

External callers can call in no problem.

Internal extensions can transfer live calls internally with no issue, and call divert to an internal extension works fine too.

However, call transfers, or call divert, to *external* numbers does not work. Silence (is golden). The external phone rings, but there is no audio.

Would appreciate some clues as to where I should start looking for a reason why this is happening!

Thanks!

Robin

[telecastle]

Is the calling phone an internal extension or is it an external number? In other words, does the call originate inside your network or are you trying to transfer a call received from the outside back to the outside? If it is the latter, this may be a NAT'ing problem on your router. Try to remove your router and connect UC320 directly to the Internet. Then try this scenario again and see if it works.

[rakinonz1]

Hi telecastle

Thanks for taking the time to reply.

The calling phone can be either an internal extension or an external number: the behaviour is the same i.e. if the call is transferred or call-diverted off-site, the target phone rings, but there is no audio/dead air.

Where I'm at currently is trying to fathom why this is a problem with transferred calls but not with regular calls (incoming/outgoing).

Just trying to see what is different about the transferred/diverted to offsite situation vs. regular incoming/outgoing in terms of the router and NAT.

Regards

Robin

[telecastle]

I don't have access to a UC320, but I think I will be installing one for my client soon. However, I have had a lot of experience with IP telephony (CUCM, CUCME), and some experience with SIP trunks. NAT'ing is always a suspect when something doesn't work with calls, transfers, or forwards to the outside. Supposedly, UC320 has a built-in routing feature. I would recommend connecting the WAN interface of the UC320 directly to the Internet and turning the routing feature on. Then, I would test out the scenarios where the calls are currently failing. If everything starts working fine, you will know that it's your router/firewall that is causing the problem. You can then use a packet analyzer to compare the SIP and RTP packets with the UC320 connected directly to the Internet and having it behind another router/firewall. Hopefully, you will be able to find what's causing the problem.

By the way, what router/firewall are you currently using?

[rakinonz1]

Thanks for your response telecastle.

This issue arose when the ISP switched call provider priority so their failover became their primary, and vice-versa.

When they switched back, the issue disappeared.

They think it may be a hairpinning issue that relates to the UC320 but not the UC520.

Cheers

Robin

[Christopher Edgeworth]

Hi Robin,

What is the PSTN connectivity on this system?  SIP trunks/BRI or FXO?  What kind of transfer are you trying to make? (Consultative or blind)  Have you turned on the logs on for your PSTN trunks?  The Small Business Support Center can help with an interactive debugging session.

Chris

[rakinonz1]

Hi Christopher, thanks for the reply.

SIP trunks, and I'm not sure of the difference between consultative and blind transfers.

As we have established the issue has surfaced following an upstream change, we're trying to establish what's happening there first, then see whether this resolves the issue before trying to fix something that may not be broken, especially as it was working before the upstream change.

I have a new appreciation of the difficulty involved with troubleshooting these issues. Obviously if logs are there and call traces can be made then this helps, as do wireshark taps, etc., where relevant. Still, many factors ...

Thanks again - I may be back with further questions!

Cheers

Robin

[rakinonz1]

OK an update here: the ISP made some changes, including authentication information, and now everything works.

Interestingly - and I don't know if this was significant or not - the UC320 codec was G711 and once the ISP knew this, the configuration change at their end reflected this (not G729), that's when it appeared to start working.

Thanks for the replies to my original post.

Regards

Robin

[icepicknz]

Hi Robin,

I have actually been testing with our UC320 and see that there is only option for G711A and G729 with New Zealand as the region. I've asked in another ticket if anyone knows how to change the regional setting maybe using a PMF file to allow New Zealand region G711U.

Chris, I notice you are from cisco, do you know how we can get a regional PMF for New Zealand to allow G711U to fix this issue as at current we're having to hard set the inbound calls on the IP2IPGW for Robin and other UC320 clients of ours.

Many thanks

Barry

[David Harper]

Hi Barry,

I'd like to better understand what is happening here.  The codec setting in the UC320 really only controlls the preferred codec presented by the UC320 when setting up calls.  If that preferred codec is not available then an alternative codec will be negotiated.  Also, if a common codec cannot be agreed on, the call should fail completely rather than going to one-way audio.

Of course, those are pretty general statements, so I'd like to get more detail as to exactly what you are seeing.  Do you have a case open at all for this that I could look at?  Alternatively, you can email me at dharper@cisco.com with more info.

Cheers,

Dave.

[icepicknz]

Hi David,

I note you are away so for the purpose of the general public understanding our problem and to see if anyone else has had this...

Hi David,

You posted on https://supportforums.cisco.com/message/3483208#3483208 recently hence my email to you.

We are a service provider in New Zealand and have a number of IT partners that resell our service, UC320's have become a common device that we have suggested for smaller installs where UC500 series is also very common.

There are a couple of problems we have uncounted…

The UC320 only allows G711a & G729a to be selected as a preferred codec

1./When g729a codec is selected

-Call from external to the UC320 works fine

-Call from external to the UC320 which then diverts to voice mail, or if user selects an auto attendant menu option to go to voicemail, voicemail works fine.

-Call from external to the UC320 which does a CFWD or auto attendant option to CFWD to external number, call rings external mobile phone, but no audio

2./When g711a codec is selected

-Call from external works fine

-Call to voicemail has one way voice, person calling in can hear the "You have reached the voicemail box of …" however person calling in can't leave a message and UC320 just hears silence so ends the call and sends a 4 second voicemail with no audio

-Call to CFWD or auto attendent CFWD works. Only problem is we get dead air until mobile phone is answered as UC320 doesn't send ring.

3./ When hard setting the codec to G711u from the IP2IPGW which sits before the UC320 and does the call routing to our clients (see below config)

-Call from external to UC320 works fine

-Call from external to voicemail works fine

-Call from external to UC320 with CFWD or auto attendant external number works fine. Only problem is we get dead air until mobile phone is answered as UC320 doesn't send ring.

IP2IPGW1 , config used to hard set codec to G711U which everything works with…

dial-peer voice 92806123 voip

description ###  Vibe Main Number go via axa-isbc1 ###

huntstop

destination-pattern 6492806123

voice-class sip g729 annexb-all

session protocol sipv2

session target sip-server

dtmf-relay rtp-nte

carrier-id source Carrier1

codec g711ulaw

icpif 0

ip qos dscp ef signaling

Another function we would love to see on the UC320 is the ability to hairpin calls which we cannot seem to do with UC320. On UC500 series we would do the following

voip service voip

no supplementary-service sip moved-temporarily

no supplementary-service sip refer

Many thanks for your help in advance, this will all assist with the roll out of around 100 of these units over the next 6 months.

Many thanks

Barry

[watson.daniel]

Hi all,

Just my 2c - UC320W running 2.1.2, SIP trunking  provider in NZ is 2talk, at their end G711 needed to be set as well as  on the UC320W as the default codec. G729 doesnt seem happy at all.

Now my calls transferred from the AA go through and do carry audio both ways rather than dead air. Voicemail message seems to be accepted but need to confirm.