我们都知道在Lync里面现在可以不用+号了，这让用户号码处理起来更直观，因为大家都不是很习惯那个+号。但是如果你想在用户输入的号码之前添加一些前缀的话，没有加号就会带来一些问题。我们来看看是什么问题。
很简单的号码规范法则，Lync内部分机为8开头，第一个规则就是处理内部号码。第二个规则则是在用户输入的号码之前加一个9。
Lync用户在客户端输入12345678，号码被变成了912345678，正是我们想要的。
在呼叫建立的阶段，我们看到了就是这个号码，不错。
但是接通以后，号码居然变成了9912345678，居然多了一个9。怎么回事呢？
INVITE sip:9912345678@AFM400.ucdemo.net;user=phone SIP/2.0
FROM: "寮犻"<sip:+8001@lync2010.ucdemo.net;user=phone>;epid=A6F158AF53;tag=6ed2eeba2b TO: <sip:9912345678@AFM400.ucdemo.net;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;phone-context=beijing@ucdemo.net;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:9912345678@ucdemo.net;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:9912345678@ucdemo.net;user=phone] |
通过上面的log，我们明显的看到，Lync客户端送过来的呼叫，又执行了一遍号码规范法则，结果自然成了99了。
问题是找到了，那要怎么解决这个问题呢？
答案就在这里，需要在9的前面加一个+号。
客户端输入的号码变成了+912345678。
接通中和通话中，号码都是一样的，问题搞定了。
INVITE sip:+912345678@AFM400.ucdemo.net;user=phone SIP/2.0
FROM: "寮犻"<sip:+8001@lync2010.ucdemo.net;user=phone>;epid=A6F158AF53;tag=f22c69eac TO: <sip:+912345678@AFM400.ucdemo.net;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:+912345678@ucdemo.net;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:+912345678@ucdemo.net;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:+912345678@ucdemo.net;user=phone] |
在看看服务器上的log，lync前端发现客户端送上来的号码已经是全局号码了，就不会再用规则再处理一次了。
结论就是如果你要在客户端输入的号码上加内容的话，记得要转换成为带+号的，不然就会出现上述的问题。