strange voice packet routing issue 1

[jyang12]

Hi all,

We recently started to have a strange issue which I believe is routing related: when a call got directly forwarded by the DID(either froward no answer or mobile twinning) to an external phone, audio is lost both ways. However if the call is originated from an internal extension, or the call is transferred by an internal extension(to the same extn with that DID to the same external phone), audio is fine. We can re-produce these scenarios after PBX reboot, or on different extn + external phone combinations. Should I be suspecting somewhere along the line the routing is incorrect? I'm pretty sure we have enough licenses to cover these calls as we tried at quiet times too. And I'm still waiting for the call trace result from our SIP provider. Our setup: IPO 500 V2 7.0 on SIP Trunk.

Please share your valuable opinion, thanks!

 

[tlpeter]

Play with the refer option on the sip trunk.

BAZINGA!

I'm not insane, my mother had me tested!

 

[jyang12]

It's set to Auto on both Incoming and Outgoing(REFER is checked on). By looking at the Help and our scenario, which one would be your best choice:

Refer Support: Default = On. Software level = 6.1+
REFER is the method used by many SIP device, including SIP trunks, to transfer calls. These settings can be used to control whether REFER is used as the method to transfer calls on this SIP trunk to another call on the same trunk. If supported, once the transfer has been completed, the system is no longer involved in the call. If not supported, the transfer may still be completed but the call will continue to be routed via the system.

· Incoming: Default = Auto
Select whether REFER can or should be used when an attempt to transfer an incoming call on the trunk results in an outgoing call on another channel on the same trunk. The options are:

· Always
Always use REFER for call transfers that use this trunk for both legs of the transfer. If REFER is not supported, the call transfer attempt is stopped.

· Auto
Request to use REFER if possible for call transfers that use this trunk for both legs of the transfer. If REFER is not supported, transfer the call via the system as for the Never setting below.

· Never
Do not use REFER for call transfers that use this trunk for both legs of the transfer. The transfer can be completed but will use 2 channels on the trunk.

· Outgoing: Default = Auto
Select whether REFER can or should be used when attempt to transfer an outgoing call on the trunk results in an incoming call on another channel on the same trunk. This uses system resources and may incur costs for the duration of the transferred call. The options available are the same as for the Incoming setting.

 

[Bas1234]

Did someone played with the settings in the router itself?
If it was good before and nothing changed in the ipo then i would look somewhere else.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

here is the thing: IPO connects directly to the SIP Trunk from our carrier, there is no router in between. So it's either our PBX or somewhere in the cloud of SIP trunk in my opinion...

 

[Bas1234]

Do you have stun enabled? Ask the provider or use a public one like stunserver.org

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

We don't have STUN enabled. And how STUN is going to affect the behavior, given the fact that if a call get forwarded internally once before it reaches the external phone number then the audio is working fine? Since I'm dealing with live system here so I want to be very careful. Thanks

 

[Bas1234]

Then play with it in the out of office hours

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

out-of-office hours is no question, however I'd like to make sure I understand this correctly: our PBX is not behind any firewall, and secondly if the call travels more hop then it works - does that still sound like a STUN issue? Thanks

 

[amriddle01]

I wouldn't imagine STUN will help if there is no NAT involved

 

[jyang12]

Right, and if it's the NAT or STUN issue then this forward/twinning function should not work at all, instead of this very specific manner. Any other thoughts guys? And it could be always like this, just we weren't noticing it until recently - if that's the case, what else can you think of? Thanks

 

[Bas1234]

Missed the part that it sits on the public ip, i hope that you don't have a public ip striaght on the internet. You will get hacked soon or late, maybe the are trying it and thats why you get one way speech.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

We did enable the built-in firewall policy on IPO and block unnecessary incoming traffic - again, it's very specific so I don't think hacked is the cause. I should look into raising the bar once I figure this out though.

 

[amriddle01]

Look at the keepalive settings for SIP trunks, they can help with audio issues with forwarding

 

[Bas1234]

Drop a trace here, we could have a look.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

did you mean RTP keepalives under System? It's disabled right now, does that make sense?

 

[jyang12]

And the Use Network Topology Info is set to None for the SIP line.

 

[Bas1234]

Drop a trace here, it could be several things, also 7.0 and 8.0 had som bugs on oneway audio.

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[Bas1234]

See for your selve:

http://marketingtools.avaya.com/knowledgebase/businesspartner/caveats/index.php

___________________________________________
It works! Now if only I could remember what I did...

Dain Bramaged (Avaya Search tool

http://tinyurl.com/bas1234

)
______________________________________

 

[jyang12]

problem solved - RTP keepalives does the trick! I enabled it for RTP, 1 second and it works. I'm not sure if I should have other value in the timeout value though. Let me know if you think I should. Thanks all!