Lync 号码处理案例分析

我们都知道在Lync里面现在可以不用+号了，这让用户号码处理起来更直观，因为大家都不是很习惯那个+号。但是如果你想在用户输入的号码之前添加一些前缀的话，没有加号就会带来一些问题。我们来看看是什么问题。

 

很简单的号码规范法则，Lync内部分机为8开头，第一个规则就是处理内部号码。第二个规则则是在用户输入的号码之前加一个9。

 

Lync用户在客户端输入12345678，号码被变成了912345678，正是我们想要的。

 

在呼叫建立的阶段，我们看到了就是这个号码，不错。

 

但是接通以后，号码居然变成了9912345678，居然多了一个9。怎么回事呢？

 

INVITE sip:[email protected];user=phone SIP/2.0
FROM: "寮�椋�"<sip:[email protected];user=phone>;epid=A6F158AF53;tag=6ed2eeba2b
TO: <sip:[email protected];user=phone>
CSEQ: 161 INVITE
CALL-ID: 158f15ed-9439-47df-a3c8-c6b06d849083
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.1.82:59636;branch=z9hG4bKdfe87fbb
CONTACT: <sip:Lync2010.ucdemo.net:5068;transport=Tcp;maddr=192.168.1.82;ms-opaque=3fd30fd3bcf7bd95>
CONTENT-LENGTH: 339
SUPPORTED: 100rel
USER-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE

抓个包看看，中介服务器在送给网关的时候，已经变成了99了，这说明和网关没有什么关系，安心到Lync上找问题吧。

 

拿出强大的log工具，我们这次来抓TransltionApplication的log。

TL_VERBOSE(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a3 (TranslationApplication,PhoneProcessor.OnRequest:phoneprocessor.cs(493))[2680750736]OnRequest: INVITE, reqUri=sip:912345678;[email protected];user=phone newHostPart=NULL TL_VERBOSE(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a4 (TranslationApplication,PhoneProcessor.ProcessFromUri:phoneprocessor.cs(748))[2680750736]P-Asserted-Identity header present, skipping FROM URI processing. TL_VERBOSE(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a5 (TranslationApplication,EmergencyCallHelper.IsEmergencyCall:emergencycallhelper.cs(38))IsEmergencyCall = False TL_VERBOSE(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a6 (TranslationApplication,PhoneNumberTranslator.TranslateNumber:phonenumbertranslator.cs(265))[2680750736]calledNumber='912345678' TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a7 (TranslationApplication,RegexContainer.AddAttribute:cregexcontainer.cs(63))(000000000007B7E8)[RegexContainer::AddAttribute] added attribute beijing, key 0 TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.950.0004d4a8 (TranslationApplication,RegexWrapper.Parse:cregexwrapper.cs(108))(0000000003682D90)[RegexWrapper::Parse] regex: ^(8\d{3})$ TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.951.0004d4a9 (TranslationApplication,RegexWrapper.Parse:cregexwrapper.cs(192))(0000000003682D90)[RegexWrapper::Parse] successfully parsed regex: ^(8\d{3})$, prefix 8, num leading zeroes 0 TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.951.0004d4aa (TranslationApplication,RegexContainer.AddRegex:cregexcontainer.cs(191))(000000000007B7E8)[RegexContainer::AddRegex] added regex ^(8\d{3})$ to list with prefixes TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.951.0004d4ab (TranslationApplication,RegexWrapper.Parse:cregexwrapper.cs(108))(0000000000FC1CD6)[RegexWrapper::Parse] regex: ^(\d*)$ TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.951.0004d4ac (TranslationApplication,RegexWrapper.Parse:cregexwrapper.cs(192))(0000000000FC1CD6)[RegexWrapper::Parse] successfully parsed regex: ^(\d*)$, prefix 0, num leading zeroes 0 TL_INFO(TF_COMPONENT) [1]1274.1820::01/10/2012-08:36:15.951.0004d4ad (TranslationApplication,RegexContainer.AddRegex:cregexcontainer.cs(169))(000000000007B7E8)[RegexContainer::AddRegex] added regex ^(\d*)$ to list without prefixes TL_VERBOSE(TF_COMPONENT) [3]1274.1820::01/10/2012-08:36:15.973.0004d4ae (TranslationApplication,PhoneNumberTranslator.ApplyProfile:phonenumbertranslator.cs(510))[2680750736]ruleName='PSTN' matched Num='912345678', txNum='9912345678' TL_VERBOSE(TF_COMPONENT) [3]1274.1820::01/10/2012-08:36:15.973.0004d4af (TranslationApplication,PhoneNumberTranslator.TranslateNumber:phonenumbertranslator.cs(340))[2680750736]MATCH: New request Uri='sip:[email protected];user=phone' TL_INFO(TF_PROTOCOL) [3]1274.1820::01/10/2012-08:36:15.973.0004d4b0 (TranslationApplication,PhoneProcessor.OnRequest:phoneprocessor.cs(511))[2680750736]Retargeting [ReqUri=sip:[email protected];user=phone]

通过上面的log，我们明显的看到，Lync客户端送过来的呼叫，又执行了一遍号码规范法则，结果自然成了99了。

 

问题是找到了，那要怎么解决这个问题呢？

答案就在这里，需要在9的前面加一个+号。

客户端输入的号码变成了+912345678。

 

 

接通中和通话中，号码都是一样的，问题搞定了。

INVITE sip:[email protected];user=phone SIP/2.0
FROM: "寮�椋�"<sip:[email protected];user=phone>;epid=A6F158AF53;tag=f22c69eac
TO: <sip:[email protected];user=phone>
CSEQ: 174 INVITE
CALL-ID: d1a085c2-0f8d-43fa-8d06-2560f9801ecb
MAX-FORWARDS: 70
VIA: SIP/2.0/TCP 192.168.1.82:59818;branch=z9hG4bK4dde59bc
CONTACT: <sip:Lync2010.ucdemo.net:5068;transport=Tcp;maddr=192.168.1.82;ms-opaque=3fd30fd3bcf7bd95>
CONTENT-LENGTH: 339
SUPPORTED: 100rel
USER-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE
                                           
这次中介发出的号码就是+912345678了，+号就交给网关处理吧，它的专职工作。

TL_VERBOSE(TF_COMPONENT) [0]1274.07B4::01/10/2012-08:44:54.030.0004d50a (TranslationApplication,PhoneProcessor.OnRequest:phoneprocessor.cs(493))[4129752281]OnRequest: INVITE, reqUri=sip:[email protected];user=phone newHostPart=NULL TL_VERBOSE(TF_COMPONENT) [0]1274.07B4::01/10/2012-08:44:54.030.0004d50b (TranslationApplication,PhoneProcessor.ProcessFromUri:phoneprocessor.cs(748))[4129752281]P-Asserted-Identity header present, skipping FROM URI processing. TL_VERBOSE(TF_COMPONENT) [0]1274.07B4::01/10/2012-08:44:54.030.0004d50c (TranslationApplication,EmergencyCallHelper.IsEmergencyCall:emergencycallhelper.cs(38))IsEmergencyCall = False TL_VERBOSE(TF_COMPONENT) [0]1274.07B4::01/10/2012-08:44:54.030.0004d50d (TranslationApplication,PhoneNumberTranslator.TranslateNumber:phonenumbertranslator.cs(239))[4129752281]Global number, no further processing. RequestUri=sip:[email protected];user=phone TL_INFO(TF_PROTOCOL) [0]1274.07B4::01/10/2012-08:44:54.030.0004d50e (TranslationApplication,PhoneProcessor.OnRequest:phoneprocessor.cs(511))[4129752281]Retargeting [ReqUri=sip:[email protected];user=phone]

在看看服务器上的log，lync前端发现客户端送上来的号码已经是全局号码了，就不会再用规则再处理一次了。

结论就是如果你要在客户端输入的号码上加内容的话，记得要转换成为带+号的，不然就会出现上述的问题。

本文出自 “WW的统一沟通” 博客，谢绝转载！