Twinning does not work with Intermedia SIP Trunks

[superikey]

thread940-1636875

Having the ver same problem described in this thread above.
Twinned calls ring the mobile device, and then dead air upon pickup.
manually twinning the call by hitting the twin button works and so does call forwarding.

System is running R9.1, and using Intermedia SIP Trunks.

Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[superikey]

Anyone on this?

Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[stownsend]

We have Dead Air Issues when Calls Come and go though the SIP provider and they had off the Media to the end points vs host the media portion of the call themselves.

Our System can receive/place a Call, though when the call then references a number that is also outside of the firewall, though ultimately is a device behind it. The Internal Device loops and cannot make a Connection to the Public IP on the firewall. This is Most noticeable when use the SIP trunk to call the full 10 Digit number of another user on the same IPO. Call goes out to SIP Provider, Makes the Connection back in, then tells the two of us to call on between ourselves, then the Audio Drops.

This can also happen with our Speaker Phones that Don't go though IP Office, but Directly to the SIP Provider and then back into a IP Phone on the Avaya behind the same Firewall.

You can see the IPs in the System Status of call you are on to see if this might be your issue.

Scott<-

 

[hairlessupportmonkey]

You should enable RTP Keep Alive on your LAN (depending which LAN you are using for your SIP signalling.) In the below example, LAN1.

From the help file:

· Keepalives: These settings can be used with SIP trunks associated with the LAN through their Use Network Topology Info setting (Line | Transport). For some scenarios, with frequent call forwarding on the same SIP trunk, speech path may be lost during the connection. The use of periodic keepalive packets may prevent the issue.

· Scope: Default = Disabled
Select whether the sending of keepalive packets should be disabled or sent for RTP or for both RTP and RTCP.

· Periodic timeout: Default = 0 (Off). Range = 0 to 180 seconds.
Sets how long the system will wait before sending a keepalive if no other packets of the select SCOPE are seen.

· Initial keepalives: Default = Disabled.
If enabled, keepalives can also been sent during the initial connection setup.

ACSS - SME
General Geek

 

[superikey]

Hi
We tried to enable RTP keep alive buy that did not help. Any other suggestions?

Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[Ragnorak]

Just a shot in the dark-- Are these IP phones? Do you have Allow Direct Media enabled?

Can't remember if Intermedia SIP allows for sending Outbound Caller ID that is not on the account or not. Have you tried turning off sending the original Caller ID?

 

[superikey]

Yes they are ip phones. But the twinned endpoint is a cell phone. Would direct media path have any affect on this ?

Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[Ragnorak]

Allow Direct Media Path ought not have any impact, but the setting is related to the handling of RTP packets. If the call goes through with dead air that means the Port 5060 SIP (or 6060 with Intermedia if memory serves) packets are being handled properly but the RTP packets carrying the actual audio are not. It is a stab in dark, but if the call is somehow flagged as eligible for a direct media path with the IP phone and then when the twinned mobile answers and somehow the attempt to establish a direct media path is never aborted that would result in the symptoms you are experiencing.

You might also try twinning with a digital phone to see if you get a different result to determine if the RTP issue is related to some kind of negotiation or communication only with the IP phones. I wouldn't order a new digital phone just to test this, but if you have one sitting on a shelf it is worth a shot. If you have remote access, the Allow Direct Media Path setting shouldn't take more than 5 minutes to test.

You could also try and call forward an extension to a mobile phone to verify that the issue is specifically with twinning and not with any call that is rerouted back out over the SIP trunks.

This might be worth looking at too even though it isn't exactly your issue:

http://www.tek-tips.com/viewthread.cfm?qid=1732634

 

[tlpeter]

What about turning the RTP keepalive off?

BAZINGA!

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

 

[Justplainjo]

Ok. So we tried all this, and still no dice.

Any other ideas?

Jo

Jo Levi
ACSS

 

[amriddle01]

You need to wireshark it to see if audio leaves the system or not

 

[superikey]

Has anyone else experienced this issue?
I was still not able to get this to work, even tried opening all inbound ports in my firewall to rule out firewall blocking ports.


Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[superikey]

Anyone?

Isaac Braca
Avaya ACA - IP Office
CTO / ICCS & Co., LLC.


ICCS, Your Premier IT & Telecom Partner, is a New York City Based Avaya SMB Expert Business Partner and IT Consulting Firm.

Visit and Post on my Blog:

http://ipofficeexpert.blogspot.com/

 

[amriddle01]

Why not do what I suggested

 

[alaniccs]

Hello,

I work with Ikey and have been testing this further. I was able to further narrow the issue.

The issue we are seeing only happens when calling into a Direct Dial to a user extension. The twinning dials the cell but there is dead air.
Any calls routed through the Voice Mail Pro service does not experience this issue. Same hold true with embedded Voice Mail, works fine when dialing through an attendant.
If I call through the auto-attendant and hit the user's extension twinning works fine.

I tested further by created a simple Voice Mail flow module which just transfers to an extension, if i set the incoming call route through that voice mail module the twinning works just fine, if i set the incoming call route to ring the extension directly twinning stops working.
I have tested this on three independent systems, same results across the board. All 9.0 releases.

Any ideas out there?

Alan

 

[alaniccs]

Anyone?

 

[liquidshokk]

Having exactly the same issue. Calls transferred to twinned users are fine, but anything that comes in on a twinned DDI and answered on the mobile gets dead air. When running a stun check the firewall type comes back as Full Cone NAT and when left like this the outside caller hears ringing even when answered on the mobile and the mobile user hears dead air. Manually setting any other firewall type results in dead air both ends. V9.0.8 IP500 V2