咱們都知道在Lync裏面如今能夠不用+號了，這讓用戶號碼處理起來更直觀，由於你們都不是很習慣那個+號。可是若是你想在用戶輸入的號碼以前添加一些前綴的話，沒有加號就會帶來一些問題。咱們來看看是什麼問題。前端
很簡單的號碼規範法則，Lync內部分機爲8開頭，第一個規則就是處理內部號碼。第二個規則則是在用戶輸入的號碼以前加一個9。服務器
Lync用戶在客戶端輸入12345678，號碼被變成了912345678，正是咱們想要的。app
在呼叫創建的階段，咱們看到了就是這個號碼，不錯。ide
可是接通之後，號碼竟然變成了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上找問題吧。spa
拿出強大的log工具，咱們此次來抓TransltionApplication的log。.net
| 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]
3d |
經過上面的log，咱們明顯的看到，Lync客戶端送過來的呼叫，又執行了一遍號碼規範法則，結果天然成了99了。blog
問題是找到了，那要怎麼解決這個問題呢？ip
答案就在這裏，須要在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前端發現客戶端送上來的號碼已是全局號碼了，就不會再用規則再處理一次了。
結論就是若是你要在客戶端輸入的號碼上加內容的話，記得要轉換成爲帶+號的，否則就會出現上述的問題。
