Alcatel Unleashed

Hi all!

I have a very strange problem in the following scenario:

Node 1 is all IPTouch based
Node 2 is a "transit" node with some QSIG and ABC-F over T2 links to others PBX.

Node 1 and 2 are linked by an ABC-F IP trunk.
Node 1 and 2 are running 9.1.

Calls from/to Node 1 to Node 2 or any PBX beyond Node 2 works fine, BUT:
1.-If an IPTouch (user1) from Node 1 calls another IPTouch (user2) in Node 1, they establish the RTP flow correctly.
2.-Then, user 2 perfoms a query to user3, who is beyond Node 2, so the RTP flow is correctly established between user2 and the INTIP board on Node 2.
3.-User 1 have stablished the RTP flow with the GD Board in Node1 at this moment (listening MOH)
4.-When user2 transfers the call from user1 to user3, user1 starts sending RTP flow to INTIP board in node2, but this INTIP board reject the flow. This produce NO AUDIO in this call.

If user1 calls directly to user3, the RTP flow is correctly established between user1 and the INTIP Board on node2. The call works fine.

User3 can be from another OXE linked by ABC-F-T2 or from others PBK linked by QSIG-T2 to Node 2.


I've found this parameter at Trunk Group Level, that seems to have something to do:
Homogenous network for direct RTP:
Must be set to 'Yes' if software versions of all nodes of all the
sub-networks linked by ABC-IP are equal or greater than R9.0
Default value = 'No'

In this scenario, we cover the requirements, but there is no way to leave this parameter at YES. If I create a new trunk group validating this parameter at YES, OXE says OK!, but you consult again the trunk group and it says NO!.


So the summary of this, when we make a transfer to something beyond node 2, it seems that the INTIP not learns that should receive the flow from the user 1, and the call is establish with NO AUDIO.

Any help will be grateful!!

Thanks,

Txami

When you say about Node 1, 2,3 - speach about one ABC-F network (VoIP TG, Hybrid link, VPN overflow) or different network?
Managed or not prefixes "PCX address in DPNSS"?

Node1 is linked to node2 with ABC-F over IP (VoIP TG, Hybrid link, VPN prefixes and DPNSS prefix) and works fine.
Node2 is also linked to node3 with ABC-F over T2 (ABC TG, VPN prefixes, etc) and also works fine.
Node2 is also linkes to 2 more PBX with QSIG links over T2.

Calls between node1 and node3 (or the other QSIG linked PBX) works fine, the problem is transfering calls if the 2 first users are IPTouch users from node1.
I have found TC1612 with title "Wrong call routing on transit node". No more details in TC, but I will upgrade to 33c patch which should fix this issue.

For the moment, I have't found the way to enable "Homogenous network for direct RTP" parameter on TG...

I will post results here.
Thanks!

Well, isn't a version problem. This issue has been reported by other clients running 9.1 with patch 33c... So now, support people has discovered that the common thing in these installations in the presence of a Fortinet firewall between the nodes linked by ABC-F over IP.

We are all becoming crazy with this. If there is someone interested, I should find the way to upload some wireshark traces that we have extracted today.

Go back to work! Thanks!

Finally resolved!! The Fortigate firewall was using "IP HELPER FOR H323", so when they DEACTIVATE this parameter, transfers started working FINE!! Sounds strange, but in the traces we saw a packet entering in the FW with an IP address for RTP and in the same packet at the FW exit had the RTP address modified.

Bye!

Hi
We have faced similar issue

For us also the transfer issue gets resolved after the fortigate disables the IP HELPER FOR H323

but the customer has got other issues with Video Conferencing units, ( polycom make)

Can you help

Logs? Scenario? Something to help you with


Enviado de meu E6633 usando Tapatalk

Thanks for your response, Sorry I never imagined some one will respond to this very old thread.
We have IP ABCF Logical Link network of 9 nodes
5 nodes are in Campus hence the traffic does not go through firewall
4 nodes are through MPLS and the traffic passes through Firewall.
When ever and Ip Phone from the Campus network calls a TDM user on the MPLS nodes and tries to transfer the call to an another IP phone from the capmpus, we get one way speech.

if the Firewall team disables the H323 helper then we have no issues.

Hope I am able to communicate to you the issue

Well...you already have the answer and root of your problem. So, what do you need on OXE?

Enviado de meu E6633 usando Tapatalk

Maybe just create a rule for the OXE IPs involved so you can still use the H323 helper on other parts of your network.

Enviado de meu E6633 usando Tapatalk