咱们都知道在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前端发现客户端送上来的号码已是全局号码了，就不会再用规则再处理一次了。
结论就是若是你要在客户端输入的号码上加内容的话，记得要转换成为带+号的，否则就会出现上述的问题。
