ISSUE: When a lync user start call negotiation with federated user this 400 Malformed route header problem arise. 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.0 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=AAEAA...
Network programming and scalable micro-services in Azure