WHY?
As the federated user's are most of the case out of the local lync server and they are not the user of this local lync server edge end, they often need clear and concrete route header so that server could extract route header value in-order and route the message to remote federated client end.
Example:
Sending:
CANCEL sip:demouser@yy.com;opaque=user:epid:SsEhlbS7GFGJkfHOY836rAAA;gruu SIP/2.0Received:
Via: SIP/2.0/TLS x.x.x.x:33360;branch=18n2L9K88eMlGn7CcctT9RwKSB1FebW397VI5uG1
From: <sip:test@xx.local>;tag=1375467581;epid=13754675
To: <sip:demouser@yy.com>;epid=fd941b3907;tag=9c85c700e3
Call-ID: BHQjMXffBDJ3cWfS4CAvb2wTByEnCZT2xxb7jecK
CSeq: 2 CANCEL
Max-Forwards: 70
User-Agent: Matrix
1. Route: <sip:ddd.yy.local:5061;transport=tls;opaque=state:T;lr>
2. Route: <sip:sip.yy.com:5061;transport=tls;epid=fd941b3907;lr;ms-key-info=AAEAAXibVCEA-ehQqI_OAWg1-HXGy3EkInAKsk_XnfP0Bi3YEKqfMhvIhCCYTmXxe7rq5jzR0t2r-3Xro344SxogHqb7E5u-qup95bHlZZn6TtF_B6acjtJBmBEGBJuMcTDmbFXy8F8yEs4K6be_BnXEbLN4reAl6fnnM3ZiHW3FJ2rlACd7ZmiGZKTQtJSj1UYod0R0xmhp9h2ZVzg0EKgJJRVFiw8Q_CxxejtrSeWz-r_swfbtunQ8Yx5gw4ZOnPA4-5iE9cA0A32UC9sbus5hmoflbHwlLBC6coRgOR77mhHlENEWVD-hu-ST310vDRoPHPHuDESLzfNx51FYaomQhJq3LoIrix0yhm3-SpWpvZukSFlOFQzmLhzKOcp9qDyxFQ5jD_5UceCN2zISwMAM5zJ2S7L8Ul9PbLSUvrPvRZmMQ9gYYXFpNT0W7Kmn5b0BTczTI0RaxyPdSWvttXZHf54aSd5ZBsQjidwe4UfhoM1hKeugfGi4ussirDH3xGl1zTkEx6g2cwkXZVvfCSRFvlE7m8_HivSPlAZ1hhEGB3Yroay9IjaQX_FTTqhivFCUbZxtTH0gtKl2pNUWLWFWPTJWojnepwPiy26qf-TX9_J8On4klv0LNfS4dYbv5QQzGgWI0ugKz0__PDuAlZAg_TkwZwwkK6zIk9fX2iTM9gBeV99Xe140jbJOUW8x;ms-route-sig=cpKH4I1JtS7c8B9C70cuDyHcDmdEwioQpamH2axMYYijK2L-D7sUkAygAA>
3. Route: <sip:edge.local:5060;transport=tls;lr>
4. Route: <sip:front.local:5061;transport=tls;opaque=state:F:Ci.R5d100;lr;ms-route-sig=fa3hMVCHMsTtGw5vppLnUTnejWyRrYeWtU5_2aZCmQ1jTdIktRI12ObwAA>
Authorization: NTLM qop="auth", realm="SIP Communications Service", opaque="514B89F0", targetname="front.local", version=4, crand="13754676", cnum ="7", response="010000007fbad6bfe83cd76e64000000"
Content-Length: 0
SIP/2.0 400 Malformed route header
Authentication-Info: NTLM qop="auth", opaque="514B89F0", srand="068FFCAB", snum="9", rspauth="0100000047762b4d20bf8ba564000000", targetname="front.local", realm="SIP Communications Service", version=4
From: <sip:test@xx.local>;tag=1375467581;epid=13754675
To: <sip:demouser@yy.com>;epid=fd941b3907;tag=9c85c700e3
Call-ID: BHQjMXffBDJ3cWfS4CAvb2wTByEnCZT2xxb7jecK
CSeq: 2 CANCEL
Via: SIP/2.0/TLS x.x.x.x:33360;branch=18n2L9K88eMlGn7CcctT9RwKSB1FebW397VI5uG1;received=192.168.0.101;ms-received-port=33360;ms-received-cid=5D100
ms-diagnostics: 1018;reason="Parsing failure";source="front.local"
Server: RTC/4.0
Content-Length: 0
SOLUTION: When a Lync caller get response (200 OK) against an INVITE request, this response has the Record route: in order of callee arrangement. So now you need to make reverse of these Route and used it in caller end. ex: if the order is 1---->3 in callee response ,in caller next request it will be 3--->1 .
No comments:
Post a Comment