No voice in twinned cellular answered calls . 5

[AlfonsoSF]

Hi

I have an IPO 500 V2 with a sip trunk working fine.
A group of Ip extensions (sip protocol)
I set up twinnig because they are working at home.

If the call is answered at the office phone it is ok.
If a call to a mobile phone is made, it is ok

But when an incoming call rings in the paired cellular , the call is answered but it have no voice.

The carrier told me that there is no voice traffic outgoing from the Avaya. Only signaling.

Both, line and extension are working with the same codec (the same as the carrier): G29(a).
The extension have the "direct media path" selected . I tested without, but it seems it is not the problem.

Where should I must to seek ?

Thanks in advanced

 

[Okkie26]

Disable direct media path at the sip trunk.

 

[Ekster]

You might want to check that RTP Keepalives are enabled on the LAN the SIP trunk is connected to.

In the <system/LANx/VoIP> tab set RTP Keepalives scope etc:

“Some humans would do anything to see if it was possible to do it.
If you put a large switch in some cave somewhere, with a sign on it saying 'End-of-the-World Switch. PLEASE DO NOT TOUCH'.
The paint wouldn't even have time to dry.”

Terry Pratchet

 

[critchey]

It is likely the keep alives that Ekster mentioned. If that is not the fix you can try REEFER support for the SIP line either off or on (starts on Auto). I have seen that cause issues forwarding/twinning on SIP lines when set to auto.

The truth is just an excuse for lack of imagination.

 

[AlfonsoSF]

Ok
Direct media path al the sip line and the extension for test were disabled
Keep alive for the VoIP Lan2 (where the sip trunk is configures) is set to RTP / enabled / 5

But no success.

The carrier suppor said that they see no outogoing audio traffic from the avaya to the cellular.

 

[derfloh]

Sounds like a SIP ALG on the edge firewall

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[AlfonsoSF]

Consistent nat is enabled
sip transformations are disabled
UDP connetion inactivity timeout is in 120 secconds

But still with no success

 

[critchey]

Did you try with REEFER enabled and REEFER disabled?

The truth is just an excuse for lack of imagination.

 

[AlfonsoSF]

No I didn't

In that place I see :
REFER incoming (never, always, auto) actually "auto"
REFER Outgoing (never, always, auto) actually "auto"
Send 302 temporaly moved (yes or not) actually NO
blind outgoing REFER (yes or not) actually NO

I have this concept not very clear

 

[critchey]

By default it sets REFER incoming and outgoing to auto which I have found in the past to cause issues with some carriers. Try setting incoming and outgoing to never and test. If that doesn't work try setting both to always and test.

The truth is just an excuse for lack of imagination.

 

[AlfonsoSF]

Tried Both "never" and both "always"

And I amb in the same situation. With no audio.

 

[critchey]

You have already exhausted the typical solutions (SIP_ALG, keep alives, refer, direct media on SIP line and extension). The only other time I ran into something similar was with ATT PRI and the equipment was sending a "CONNECT after Early Media" which caused the deskphone to tell the system it answered the call and stop even ringing the twinned caller. Bottom line you are going to have to deep dive into this it looks like.

My only suggestion is, if possible, to setup the SIP trunks (JUST AS A TEST DONT LEAVE IT THIS WAY) bypassing the firewall to see if you get the same issue. If you don't you can at least narrow it down to the firewall.

The truth is just an excuse for lack of imagination.

 

[crumthwacket]

Does this call originate as a call to a SIP DID?

I've never been able to resolve the issue, and after giving up, I created a work-around:

Create an automated attendant (name it "SIP DID" or something). Leave the selector codes blank. Set the inactivity timeout to 1 or 2 seconds.

Set the incoming call route for the DID to the newly-created automated attendant, and make the fallback extension the desired destination extension.

The system will send the incoming call to the auto attendant, which then fails over as a transferred call to the destination extension.

Works every time.

 

[AlfonsoSF]

Yes , this call is made to a a SIP DDI.

Once isreceived is forwarded to a group. Group users have twined their cellulars.

When tha call is received, The group extensions ring and in 2 secconds, cellulars too.

When the call is answered by one of them, the call is connected, but no audio is received


The carrier support service told me that they see no audio packets from the IPO to the cellular.


In the case they call a cellular from the office, no problem with the audio.
Normal calls are ereceived and with no audio problems. Only when twinned.

 

[crumthwacket]

Your terminology isn't correct: calls aren't "forwarded" to the group, incoming calls are "routed" to the group via ICR programming.

Anyway, if a SIP DID call is actually "transferred" to a destination from another destination the audio problem disappears. To make the transfer happen, I'll repeat the steps (very simple stuff):

1) Create an automated attendant named SIP DID with a 1 or 2 second inactivity timeout. Leave all selector codes blank.
2) Change the incoming call route for the DID to the SIP DID automated attendant you just created.
3) Enter the extension number of the group as the fallback destination.

Make sure the ring mode for the group is set to "Sequential" or "Rotary".

Try it - let us know.

 

[AlfonsoSF]

You must think about english is not my language.
Sametimes I must to translate because I have the knowledge in catalan or castillian.
So, peoeple who grew up in english should be more understanding.
Anyway, thanks for the correction.

About your solution...

I am near to start the voice mail pro. Not the embebded auto atendant.
What is needed is that users must be able to twin or untwin their cellular in order to receive all calls "routed" to their extension. Even the group ones.

If calls are correctly answered at the desk phones and calls from the IPO to cellulars too....
twinned calls should work with no problems. Right ?

And that's what I am not able to solve.

Thanks a lot , anyway

 

[derfloh]

Unwound recommend to do a wireshark trace of the calls to see what is declared in SDP.

Perhaps direct media is enabled for the SIP trunk but the provider can’t handle that.

IP Office remote service
IP Office certificate check
CLI based call blocking
SCN fallback over PSTN

 

[AlfonsoSF]

direct media path is not enebled for the sip trunk nor the extensions.

 

[crumthwacket]

Alfonso:

Sorry that you were offended; that wasn't my intention.

You wrote:

If calls are correctly answered at the desk phones and calls from the IPO to cellulars too....
twinned calls should work with no problems. Right ?

The answer to that is no.

Twinned calls have a problem; transferred calls do not have the problem. The solution is to get the call transferred to the calling group extension, and after that initial transfer happens the audio problem disappears.

To do this:

1) Create an automated attendant in Voice Mail Pro and name it SIP DID. Do not enable any touch tones. Set the Timeout to 1 or 2 seconds. Since no valid input is received the call fails and is transferred to the fallback destination.
2) Change the Incoming Call Route for the DID to the SIP DID automated attendant you just created.
3) Enter the extension number of the calling group as the fallback destination.

Try it. I'm sure bigger brains on this forum can smooth out any remaining issues.

 

[AlfonsoSF]

I understand that, at the menu token, "timeout" and "not valid" have no target. And the "fallback extension" is the hunt grup.

In that manner, hunt group receives the call as "transferred", not "routed". And then , twin works.

Is it correct ?


In that case, I could use a "transfer" token, rather than "menu" token to the hunt group.