Hey folks,
a customer of mine is using LDAP based routing to route calls towards their Microsoft Teams cloud. If the LDAP-query on the SBC is matching, call goes towards Microsoft Teams – if not, call goes to their old Skype onPrem environment.
Callflow in simple:
Carrier VF <-> SIP <-> SBC <-> SIP <-> Teams (and/or Skype)
They called us and mentioned that it seems a lot of calls are routed to Skype while they should be routed to Teams. The customer requested to check the LDAP-query that we’re using on the SBC.
So I checked the connectivity to the LDAP-servers which is the first requirement to enable LDAP-based routing. Then I went to the query – but it looked good from what I saw. So a check of the logs was needed and indeed, there I saw a mismatch – phone number replaced with ‚123456789‘
I do not have the original log files anymore, but basically the TO-header on the ingress sides INVITE looked like this:
TO: <sip:+123456789;phone-context=local@123.123.123.123
(N 51589972) send --> LDAP SearchID:-100 key:msRTCSIP-Line=tel:+123456789;phone-context=local* Group:0
(N 51589973) (#3):Call Setup Run Rule 0: Query LDAP for msRTCSIP-Line=tel:+123456789;phone-context=local*
[S=82681023] ProcessStartSearch Search [Time:06-01@21:55:26.059]
[S=82681024] search group index 0 name DefaultCTRLServersGroup [Time:06-01@21:55:26.059]
[S=82681025] dict msRTCSIP-DeploymentLocator search msRTCSIP-DeploymentLocator 0 0 [Time:06-01@21:55:26.059]
[S=82681026] dict 0 search 0 [Time:06-01@21:55:26.059]
[S=82681027] cache 0x1436be20 attrMismatch 0 userdata 0 0x136c45f4 [Time:06-01@21:55:26.059]
[S=82681028] Search: respond sent from cache =, = [Time:06-01@21:55:26.059]
[S=82681029] LookForAllSearchRequestsAndSetResultSent:searchRequestId=89 groupIndex 0 [Time:06-01@21:55:26.059]
[S=82681030] Set resultSent=1 searchRequestId 89 [Time:06-01@21:55:26.059]
[S=82681031] InsertResultToCache: i msRTCSIP-DeploymentLocator: msRTCSIP-DeploymentLocator [Time:06-01@21:55:26.059]
[S=82681032] InsertResultToCache: i msRTCSIP-DeploymentLocator: msRTCSIP-DeploymentLocator [Time:06-01@21:55:26.059]
[S=82681033] InsertResultToCache: i 0 numberOfAttr 1 MAX_NUMBER_OF_LDAP_ATTRIBUTES_NAMES 100 [Time:06-01@21:55:26.059]
[S=82681034] add to cache: att:0 msRTCSIP-DeploymentLocator: [Time:06-01@21:55:26.059]
[S=82681035] acEV_LDAP_SEARCH_RESULT inserted to the cache key msRTCSIP-Line=tel:+123456789;phone-context=local* status 2 [Time:06-01@21:55:26.060]
[S=82681036] SendLdapSearchResultEvent from cache 0 [Time:06-01@21:55:26.060]
[S=82681037] (N 51589976) recv <-- acEV_LDAP_SEARCH_RESULT SearchId:89 SearchResultStatus=2 [Time:06-01@21:55:26.060]
[S=82681038] acEV_LDAP_SEARCH_RESULT requestid 89 status 2 [Time:06-01@21:55:26.060]
[S=82681039] DeleteSearchRequestFromQueue: _searchRequestId=89 refcount 1 [Time:06-01@21:55:26.060]
[S=82681040] cancelTimer timerId=(nil), searchRequestId=89 [Time:06-01@21:55:26.060]
[S=82681041] cancelTimer timerId=(nil), searchRequestId=89 [Time:06-01@21:55:26.060]
[S=82681042] DeleteSearchRequestFromQueue: deleting_searchRequestId=89 [Time:06-01@21:55:26.060]
(N 51589981) (#3):Query LDAP response: Fail/Not Found
(N 51589982) (#3):Call Setup Run Rule 0: Execute condition/action
(N 51589983) (#3):Call Setup Run Rule 0: Execute result: 1, Condition was: FalseSo clearly the LDAP-query did not match. Customer confirmed that the number would be correctly configured on the LDAP, but what is this here? Why are we searching for ;phone-context=local in our query?
This parameter was delivered by carrier Vodafone in this case – I tried to remove it with Message manipulations, but the normal ones did not work – due to the order of processing different tasks within the Classification and Routing process in the AudioCodes SBCs.
As example it did not help to remove the parameter out of the TO-number utilizing the Inbound IP-Group settings – with a Message Manipulation set. Why? Because the LDAP-query is a Call Setup Rule, configured to be used by the same IP-Group – just earlier than manipulation takes place.
So any manipulation configured the „normal“ way is useless at this point.
I spoke with a colleague about this LDAP-issue and together we developed the idea to „kick out“ the unwanted to-header-information before the CallSetupRule takes actually place. Means we need to edit the INVITE-content before it is passed through to the LDAP-query.
There is a feature called „Pre-classification Manipulation“ which can be configured to a SIP Interface. This is what we did for the Ingress-SIP Interface (Vodafone) where the calls come from:
So what are we doing in our Pre-Class manipulation? Basically we are matching any phone number (based on Vodafones delivered patterns) and store the number, but only the number into a variable, called „var.session.TONUMBER“ – this is a flexible part to be defined by you btw…
As last step we went back to the LDAP query setting itself – our CallSetupRule that is querying the LDAP servers for the called (TO) number. There we replaced the request key
from: ‚msRTCSIP-Line=tel:’+param.call.dst.user+’*‘
to: ‚msRTCSIP-Line=tel:’+var.session.TONUMBER
Et voilà. Works like a charm – as it is not using the destination (TO) user parameter anymore, but our newly created variable. To query the LDAP.
Maybe a bit nerd talk in this post – but maybe it helps someone one day (:
PS: You can check Robertos‘ articles for more insights into LDAP-based routing
Cheers,
Enrico
