Finally a breakthrough. Tac suggested we try split tunnel on the E1 port (connected to our laptop avaya for desktop softphone client) and that worked. We did several calls and the rtp traffic from the client finally went through the rap towards and through the controller. We toggled back to tunnel mode for port e1 and symptom returned. Toggled back to split tunnel and it resolved.
So, something with split tunnel gives the rap either more intelligence or better decision making to allow the udp (rtp) stream from client through.
As a side note , we briefly tested this on our older v6.5.4.16 controllers and split tunnel also worked.
So, we don't have a root cause yet but we have a viable workaround.
TAC case is still open as we sent them some AP tech-support with the split tunnel parameter on for e1.
Original Message:
Sent: Oct 27, 2023 01:45 PM
From: jgauruder
Subject: Remote AP (RAP) with Avaya agent for desktop softphone H323 - one way audio
Hi Herman,
Agreed 100%. Yes, tac case is still open. We also have a ticket with Avaya. Luckily our VAR is the same for both Aruba/HPE and Avaya, so we are also engaging with VAR. Hopefully will get this to resolution. I will post additional info as I receive it.
thank you,
Jason
Original Message:
Sent: Oct 27, 2023 09:24 AM
From: Herman Robers
Subject: Remote AP (RAP) with Avaya agent for desktop softphone H323 - one way audio
I think TAC is the best approach in that case. Please share if (when) you were able to fix this.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Oct 23, 2023 04:05 PM
From: jgauruder
Subject: Remote AP (RAP) with Avaya agent for desktop softphone H323 - one way audio
Hi Herman,
Appreciate your follow up.
Yes - scenario is a wired windows laptop connected to E1 port of rap (303H in this case)
The RTP traffic (g729 codec) is fairly low packet size - 74 bytes on the wire. I do not believe potential of ipsec fragmentation is in play due to that small packet size.
Yes, we do have an "any" rule at the end (see below for "show rights" output). The current hunch or theory is that there is something in the H.225 "CS" (call setup or call session or call signaling) messages that the RAP gets confused by and correspondingly drops the forthcoming RTP flow in the direction from the wired client. Even though we have H.323 ALG disabled on the controller. Perhaps RAP alg-lite or something else on the RAP itself is dropping before it encrypts to send to the controller.
The captures we took of a working avaya "one-x" and non-working "agent for desktop" definitely indicate differences in the TCP session messages (H.225 "CS" messages)
the one-x working instance had a much larger "CS: setup OpenLogicalChannel" payload compared to the agent-desktop not-working instance.
the one-x has a parameter set called "h245Tunneling = False" whereas in avaya-agent desktop that same parameter is set to True for some of the CS messages (but not all)
there are other "CS:" messages that are unique to "agent for desktop" that I do not see in one-x such as
"CS: facility masterSlaveDetermination" and
"CS: facility terminalCapabilitySet"
Aruba TAC is currently examining output from "show log system all" and "show log user all" as well as the controller tech support bundle and "show ap tech-support ap-name " output. TAC had us enable this debugging on the controller for the "show log system" and "show log user" commands to have more info
logging system process ucm level debugging
logging user process stm level debugging
(V7205-MDF-MA1) *[mynode] #show rights USER-ROLE-TERM
Valid = 'Yes'
CleanedUp = 'No'
Derived Role = 'USER-ROLE-TERM'
Up BW:No Limit Down BW:No Limit
L2TP Pool = default-l2tp-pool
PPTP Pool = default-pptp-pool
Number of users referencing it = 2
Periodic reauthentication: Disabled
DPI Classification: Enabled
Youtube education: Disabled
Web Content Classification: Enabled
IP-Classification Enforcement: Enabled
ACL Number = 97/0
Openflow: Enabled
Max Sessions = 65535
Check CP Profile for Accounting = TRUE
Application Exception List
--------------------------
Name Type
---- ----
Application BW-Contract List
----------------------------
Name Type BW Contract Id Direction
---- ---- ----------- -- ---------
access-list List
----------------
Position Name Type Location
-------- ---- ---- --------
1 global-sacl session
2 apprf-user-role-term-sacl session
3 IP-ACL-SESSION-AVAYA session
4 voip-applications-acl session
5 IP-ACL-SESSION-ALL-PHM-INTERNAL session
6 IP-ACL-SESSION-ANY-PERMIT session
global-sacl
-----------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
apprf-user-role-term-sacl
-------------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
IP-ACL-SESSION-AVAYA
--------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
1 any any app alg-h323 permit High 46 4
voip-applications-acl
---------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
1 any any app alg-skype4b-audio permit Low 4
2 any any app alg-skype4b-video permit Low 4
3 any any app alg-skype4b-desktop-sharing permit Low 4
4 any any app alg-skype4b-app-sharing permit Low 4
5 any any app alg-sip-audio permit Low 4
6 any any app alg-sip-video permit Low 4
7 any any app alg-sccp permit Low 4
8 any any app alg-vocera permit Low 4
9 any any app alg-noe permit Low 4
10 any any app alg-h323 permit Low 4
11 any any app alg-jabber-audio permit Low 4
12 any any app alg-jabber-video permit Low 4
13 any any app alg-jabber-desktop-sharing permit Low 4
14 any any app alg-facetime permit Low 4
15 any any app alg-wifi-calling permit Low 4
16 any any app alg-webrtc-audio permit Low 4
17 any any app alg-webrtc-video permit Low 4
18 any any app alg-teams-audio permit Low 4
19 any any app alg-teams-video permit Low 4
20 any any app alg-rtp permit Low 4
IP-ACL-SESSION-ALL-PHM-INTERNAL
-------------------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
1 grp-phm-all-net any any permit Low 4
2 any grp-phm-all-net any permit Low 4
IP-ACL-SESSION-ANY-PERMIT
-------------------------
Priority Source Destination Service Application Action TimeRange Log Expired Queue TOS 8021P Denylist Mirror DisScan IPv4/6 Contract Mark Description
-------- ------ ----------- ------- ----------- ------ --------- --- ------- ----- --- ----- -------- ------ ------- ------ -------- ---- -----------
1 any any any permit Low 4
Expired Policies (due to time constraints) = 0
(V7205-MDF-MA1) *[mynode] #
Regards,
Jason G.
Original Message:
Sent: Oct 23, 2023 10:49 AM
From: Herman Robers
Subject: Remote AP (RAP) with Avaya agent for desktop softphone H323 - one way audio
If I read this correctly, it looks like the laptop connected to E1 on the RAP sends packets, but these never arrive on the controller?
Can you have a look at the packet sizes that are sent? The RAP will encapsulate (and think for wired also IPSec encrypt) those packets, and if there is some device in the path between the RAP and the controller (including the internet) which has a too small MTU, the packets may be dropped or fragmented, and fragmented inbound packets may be dropped by firewalls in the path. I would try to capture packets on a few places between the RAP and controller, and see if the packet actually reaches the controller unfragmented (my guess would be: no), and where it breaks. Also the RAP uses UDP 4500 (NAT-T/IPSec encapsulation), for which some firewalls try to decapsulate and break the flow. However, that would be the same for the older client that works... And packet sizes may be different between the different version.
Can you share the user-role? As there is also an implicit deny at the end, so if you don't have an 'any any any permit' at the end, you do have drops but won't see them.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your Aruba partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact Aruba TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or Aruba Networks.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: Oct 20, 2023 11:25 AM
From: jgauruder
Subject: Remote AP (RAP) with Avaya agent for desktop softphone H323 - one way audio
Hi Aruba Community,
We have an open ticket with aruba tac and avaya, but wanted to post this out to the community to see if anyone else is using this combination
-Aruba RAP (such as 303H, 203, RAP3)
-wired win laptop with Avaya "agent for desktop" connected to the rap and communicating with avaya call manager and associated gateway services on the enterprise network
-Using H.323
The scenario we have is that, the audio (RTP) stream is sent/received by the laptop, but the controller does not "see" (has "zero" packets) for the client side of the stream.
for example, the client with 172.22.77.6 having an RTP stream with avaya gateway 130.140.219.130 will show with "0" for the packets counter. Yet we see (with wireshark on the client laptop and as a man in the middle) the packets sent towards the RAP E1 port.
(V7205-MDF-MA1) *[mynode] #show datapath session table 172.22.77.6 | include 2052
172.22.77.6 130.140.219.130 17 2048 2052 0/0 6 46 1 vlan 128 73 0 0 FYHPTCIV 0
130.140.219.130 172.22.77.6 17 2052 2048 0/0 6 46 0 vlan 128 73 5608 336480 FHPTIVQu 14
(V7205-MDF-MA1) *[mynode] #
If we use "agent for desktop" set for SIP, this works just fine (but we could only do SIP for testing, our prod environment is not fully ready to simply transition to SIP)
If we use the older avaya one-x agent, using H323, this works fine
The avaya agent for desktop on the same win laptop using H323 works just fine on our internal enterrpise network AND on remote vpn using anyconnect.
It is strictly when paired with the RAP that it does not work...the symptom is 100% consistent, reproducible every single time.
Our only logical conclusion at this time is that the RAP is either dropping the wireshark observed RTP stream from the client for some unknown reason (such as some hiccup with h.323 tcp control session and not being able to understand the forthcoming RTP stream expected UDP ports) or the controller is dropping the packets (again for some unknown reason).
Yes - we have disabled the H.323 in ALG for testing with Aruba TAC, to no avail.
We have this "agent for desktop" h.323 issue in arubaos 6.5.4.x and in a newer standalong lab , testing 8.11 and 8.10
there are no drop acls in our user role.
Is anyone out there using this combo that can comment on success/failures and maybe specific versions having success ?
-aruba rap
-avaya "agent for desktop" windows client connected to the rap
-h.323 (not SIP)
thank you,
Jason