Dans le cadre d'un projet de migration Lync 2010 vers 2013, je suis tombé sur une nouvelle erreur: 485 Ambiguous call.
Le contexte:
- Pabx Mitel
- Deux passerelles Dialogic 2000
- Deux serveurs FE/MED 2013
- Deux serveurs FE/MED 2010
- Une centaine d'utilisateur sur 1000 utilisent Lync en tant que téléphonie principale
Problème:
Il s’agit d’une migration d’un environnement Lync 2010 vers 2013, l’ensemble des règles et stratégies voix ainsi que les règles du fichier Company… furent tout simplement récupérés. Dans l’ancien environnement 2010, l’affichage du nom dans le client lync 2010 lors d’un appel depuis un téléphone Mitel fonctionnait correctement.
Il y avait en fait deux problèmes constatés pendant et suite à la migration :
- L’erreur 485 pour les utilisateurs étant migrés sous 2013 lors d'un appel entrant:
SIP/2.0 485 Ambiguous
SERVER: RTC/5.0
ms-diagnostics: 4002;
reason="Multiple users associated with the source phone number";
HRESULT="0x8004C3CC";
processing-cluster="****************";
processing-frontend="******************";
source="*****************"
ms-application-via: ms-udc.cdr%3D8d9a4ab905fd5433dce8a519521903da%3A5;
ms-pool=*****************************;
ms-application=http://www.microsoft.com/LCS/UdcAgent;
ms-server=************
- L’affichage du nom
L’erreur 485 fut contourné temporaire en créant simplement une stratégie utilisateur différente du site par défaut et en y affectant l’ensemble des utilisateurs. Le fait d’être sur deux phones context différents ne causait plus de problème.
Par contre, le non affichage du nom d’un appelant Mitel est toujours présent.
Diagnostique:
Ayant épuisé toutes mes tentatives de correction du problème qui n'existait pas avec la version 2010, j'ai du me résoudre à ouvrir un case chez Microsoft.
L'ensemble des numéros étant au format E.164 tel que "tel:+1514XXXYYYY:ext=AAA, Le premier soupçon porté évidemment sur l'affectation du numéro +1514XXXYYYY directement à un utilisateur ou contact, ce qui n'était pas le cas, l'ayant vérifié à de nombreuses reprises.
Après être escaladé au support, la raison est enfin connue, c'est un bug!
1. L’appel entre depuis la passerelle PSTN avec le numéro en format extension :
2. Il passe par le serveur de Mediation avec la modification du contexte dans le numéro source et un nouveau Call-ID
3. En réponse, le TranslationService informe le serveur de Mediation qu’il essaye de localiser le destinataire :
4. C’est à ce point que la règle de normalisation modifiée devrait être prise en compte, mais le message 485 Ambiguous provient d’UdcAgent
Si vous souhaitez confirmer être victime du même bug, faîtes une trace avec l'option UdcAgent
Vérifiez que vous avez les informations suivantes:
TL_INFO(TF_PROTOCOL) (TranslationApplication,PhoneProcessor.OnRequest:1709.idx(591))[2133674422]Retargeting [ReqUri=sip:+1514*******;ext=****@*****.ca;user=phone]
TL_WARN(TF_COMPONENT) (UserServices,OdbcDetermineError:2923.idx(386))
----
Odbc State: 42000,
Severity: 11,
Native: 50124,
Sproc: DbRaiseError,
Line: 20,
Sql State: 1,
Message: [Microsoft][SQL Server Native Client 11.0][SQL Server]
###50124:RtcpQueryResourceDirectoryByUserOrPhone:More than one resource is assigned the phone number [+1514*******].
Unable to route to this phone number.
----
TL_ERROR(TF_COMPONENT) ((Shared),CDbAccessBase::ProcessErrorCodes:3001.idx(1443))
^^^^
RtcMessageDispatcher sproc execution failed : ExecHr = [hr=S_OK],
NativeError = [50124],
NativeErrorSeverity = [11],
NativeErrorLineNumber = [20],
NativeErrorSqlState = [1],
OdbcSqlState = [01000],
ErrorText = [[# [Microsoft][SQL Server Native Client 11.0][SQL Server]###50124:RtcpQueryResourceDirectoryByUserOrPhone:More than one resource is assigned the phone number [+1514*******]. Unable to route to this phone number. #]
[# [Microsoft][SQL Server Native Client 11.0][SQL Server]###50001:RtcMessageDispatcher:Propagation #]]
^^^^.
TL_ERROR(TF_COMPONENT) (UserServices,CSprocCompletionHandler::HandleCommonSprocErrors:2599.idx(76)) Sproc failed [SprocName=RtcMessageDispatcher] [ExecuteResult: S_OK] [NativeError: 50124]
L’erreur est retournée par le code suivant de la procédure stockée RtcpQueryResourceDirectoryByUserOrPhone, que vous pouvez retrouver dans votre banque de données. Dans une trace SQL Profiler nous aurions vu que PhoneExt a été mis à nul, ce qui fait que le résultat retourné soit de plusieurs lignes au lieu d’une seule.
select @_ResourceId = p.ResourceId
from dbo.ResourcePhone as p
inner join dbo.ResourceDirectory as d on
( d.ResourceId = p.ResourceId
and ( (d.OptionFlags & 0x00000080) <> 0
or (d.OptionFlags & 0x00000200) <> 0 ) )
where p.PhoneNum = @_PhoneNum
and ((@_PhoneExt is null) or (p.PhoneExt = @_PhoneExt))
La cause a été identifiée dans le code du Message Dispatcher, et il sera corrigé dans CU4, dont la date tentative est de mars/avril 2014. Veuillez noter que la date du release pourrait changer ultérieurement en fonction des nécessités du moment.
