Lync Federation - Accept SIP Reverse Negotiation (SIP Invite without SDP)

Hello,
Recently I tested a SIP Federation trunk between Lync Server 2013 and non-Lync Client.
In this scenario the Lync Client 2013 support SIP Reverse Negotiation, by other words if SIP Invite without SDP it's sent to Lync Client 2013 it will be accepted by any configuration option?
With the default settings seams that it's not supported with error reason "Error parsing body"
Trace-Correlation-Id: 3549384327
Instance-Id: 4C9
Direction: outgoing
Peer: lynctest.domain.com:2138
Message-Type: response
Start-Line: SIP/2.0 488 Not Acceptable Here
From: "User4" <sip:[email protected]>;tag=3794445243
To: <sip:[email protected]>;epid=abad235729;tag=a130a7e357
Call-ID: [email protected]
CSeq: 12784624 INVITE
Via: SIP/2.0/TLS 172.16.3.51:5065;branch=z9hG4bK-5765F571;rport;alias;received=172.16.3.51;ms-received-port=2138;ms-received-cid=1200
Content-Length: 0
ms-client-diagnostics: 52009;reason="Error parsing body"
Regards,
Claudio

Hello All,
After some analysis I got the following conclusions.
Lync PC Client doesn't accept initial Invite without SDP ( Delayed Offer ).
However our goal was to test the SIP Reverse Media Negotiation mechanism, so we sent initially a dummy SDP for the initial invite and after the connect send a SIP INVITE without SDP and for my surprise the Lync Client accepted and sent his own SDP on the
200 OK and we sent the new SDP offer in the ACK.
However the result was no Audio, and Lync Client kept sending the Audio to the initial INVITE SDP and ignored the new SDP offered in the ACK message.
So my conclusion it's that LYNC Client doesn't support SIP Reverse Media Negotiation (Delayed Offer) at all since it ignores the new SDP offered in the ACK message for the mid call media renegotiation attempt with SIP INVITE without SDP.
Traces:
INVITE sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="F5054EF3", snum="104", rspauth="040401ffffffffff0000000000000000e9693240576b479326af5617", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 56
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Contact: <sip:[email protected]:5065;transport=TLS>
Allow: REGISTER,SUBSCRIBE,NOTIFY,INVITE,ACK,PRACK,OPTIONS,BYE,CANCEL,REFER,INFO,UPDATE,PUBLISH
Content-Length: 0
Require: 100rel
Supported: 100rel,replaces,privacy,timer,from-change,histinfo,answermode
User-Agent: (Virtual Appliance)
P-Asserted-Identity: "" <sip:[email protected]>
Session-Expires: 720;refresher=uac
P-Sig-Options: Sending-Complete
SIP/2.0 100 Trying
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="785246a1", cnum="92", response="040400ffffffffff000000000000000000b60640ac2c60c49bc1b427"
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK97FD40ED.FD1FE32C7CB76CCD;branched=FALSE;ms-internal-info="bb0yvN-Txta-aXcfTMPmVSdyK0kBz7b-pamgWfOIbn8vks4x_9o9kUwQAA"
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CED;rport;alias;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 INVITE
Record-Route: <sip:LYNC2013-FE.domain.sifi:5061;transport=tls;opaque=state:F:Ci.R1f9c00;lr;ms-route-sig=aaCRxLomQ6J6ATKjSZx4vJQ22miSAfUAExqMcDvEWyHdss4x_99VHTLQAA>;tag=C161B833E3EAA57C26010E775AC607C8
Contact: <sip:[email protected];opaque=user:epid:wc5Y6-kDo16CxuVbyxqk9gAA;gruu>
User-Agent: UCCAPI/15.0.4701.1000 OC/15.0.4701.1000 (Microsoft Lync)
Supported: histinfo
Supported: ms-safe-transfer
Supported: ms-dialog-route-set-update
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service", opaque="D83CD7C8", targetname="sip/LYNC2013-FE.domain.sifi", crand="e903d142", cnum="93", response="040400ffffffffff0000000000000000dbe0e9524a1031ef81a19d2f"
Content-Type: application/sdp
Content-Length: 354
v=0
o=- 0 1 IN IP4 172.16.1.87
s=session
c=IN IP4 172.16.1.87
b=CT:99980
t=0 0
m=audio 12530 RTP/SAVP 8 0 13 101
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:mIMHiJBpn4ZRZfg2VXYSTdQfS4wyJ0x57QQ0q4kU|2^31
a=maxptime:200
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
ACK sip:172.16.1.87:64425;transport=tls;ms-opaque=a3edae884b;ms-received-cid=1F9C00;grid SIP/2.0
Via: SIP/2.0/TLS 172.16.0.37:5061;branch=z9hG4bK301D467E.2E943CC97CBC4CCD;branched=FALSE
Via: SIP/2.0/TLS 172.16.13.192:5065;branch=z9hG4bK-57656CEE;rport;received=172.16.13.192;ms-received-port=2051;ms-received-cid=1D0800
Proxy-Authentication-Info: Kerberos qop="auth", opaque="D83CD7C8", srand="B8AB5336", snum="105", rspauth="040401ffffffffff0000000000000000de85d6c7415302c9b7535777", targetname="sip/LYNC2013-FE.domain.sifi",
realm="SIP Communications Service", version=4
Max-Forwards: 69
From: "" <sip:[email protected]>;tag=3691888833
To: <sip:[email protected]>;epid=8a34f77d58;tag=4066ac742a
Call-ID: [email protected]
CSeq: 12046301 ACK
Contact: <sip:[email protected]:5065;transport=TLS>
Content-Length: 326
Content-Type: application/sdp
v=0
o=- 262 2 IN IP4 172.16.13.192
s=session
t=0 0
m=audio 16392 RTP/SAVP 8 101 13
c=IN IP4 172.16.13.191
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=silenceSupp:off - - - -
a=sendrecv
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:X0rDwl9KxCJfSsRaX0rEkl9KxNJfSsUCX0rFOtIK|2^31

Similar Messages

When there is call on Lync IM, instead of user name SIP address is displayed.

Lync: User name of instant message.
When there is call on Lync IM, instead of user name SIP address（[email protected]） is displayed on Office365.
In February I was guided that it was temporary problem, however again there is problem that SIP address is displaying all the time.
Inquiry content are mentioned in separate sheet ■SIP address is displayed when IM is called, is it specific, however if one can view user name, Let me know the best way and please confirm this.
Thanks in Advance.

I'd ask them over here.
http://social.technet.microsoft.com/Forums/lync/en-US/home?category=lync
Regards, Dave Patrick ....
Microsoft Certified Professional
Microsoft MVP [Windows]
Disclaimer: This posting is provided "AS IS" with no warranties or guarantees , and confers no rights.

LYNC Federation - Internal Error on Verify Message by Lync PC Client.

Hello all,
Recently I set a static route for SIP "interdomain" Federation between Lync 2013 and other vendor PBX.
However I'm struggling with the Lync PC Client error message on validating the messages received by Lync FE. Lync Mobile Client or IPAD client don't have the same issue.
In the Lync FE logs I see that the Invite it's received by the FE and forward to the Lync PC Client. However the in the Lync PC Logs we see WARN message that verify message failed what result in abort of the incoming call on the Lync Client.
Lync PC Client Log:
08/05/2014|17:36:21.102 26F8:C4 TRACE ::
verified buffer: <TLS-DSK><D82A1226><26><SIP Communications Service><Lync2013-PC.innodemo.local><[email protected]><11892668><INVITE><sip:[email protected]><1641009297><sip:[email protected]><><><><>-length-220.
signature:1fa6a6801d168888125378d7ff858578f30b6bf2
08/05/2014|17:36:21.102 26F8:C4 WARN ::
VerifyMessage failed
x6 times
In the FE Logs I see:
TL_INFO(TF_PROTOCOL) [0]12E4.1EEC::08/05/2014-15:32:40.429.000000c6 (InboundRouting,InboundRoutingClientTransaction.SendImpl:inboundroutingcontext.cs(2308))[2344625192]
SendImpl() to sip:172.16.93.12:60561;transport=tls;ms-opaque=0e66ad0711;ms-received-cid=A600
TL_INFO(TF_DIAG) [0]10CC.1314::08/05/2014-15:32:40.430.000000c8 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(778))[2344625192]
$$begin_record
Severity: information
Text: Routed a request on behalf of an application
SIP-Start-Line: INVITE sip:172.16.93.12:60561;transport=tls;ms-opaque=0e66ad0711;ms-received-cid=A600 SIP/2.0
SIP-Call-ID: [email protected]
SIP-CSeq: 11892668 INVITE
Peer: 172.16.93.12:60561
Data: destination="[email protected]";application="http://www.microsoft.com/LCS/DefaultRouting"
$$end_record
TL_INFO(TF_PROTOCOL) [0]10CC.1314::08/05/2014-15:32:40.430.000000c9 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(196))[2344625192]
$$begin_record
Trace-Correlation-Id: 2344625192
Instance-Id: 32C
Direction: outgoing
Peer: 172.16.93.12:60561
Message-Type: request
INVITE sip:172.16.93.12:60561;transport=tls;ms-opaque=0e66ad0711;ms-received-cid=A600 SIP/2.0
Start-Line: INVITE sip:172.16.93.12:60561;transport=tls;ms-opaque=0e66ad0711;ms-received-cid=A600 SIP/2.0
From: <sip:[email protected]>;tag=1641009297
To: <sip:[email protected]>;epid=5acfd7e726
Call-ID: [email protected]
CSeq: 11892668 INVITE
Contact: <sip:[email protected]:5061;transport=TLS>
Via: SIP/2.0/TLS 172.16.93.3:5061;branch=z9hG4bK32626C7B.D608D12EF622D7A8;branched=FALSE;ms-internal-info="ca-uvj7g7cd2YxUxssjsnQep4sdcBc90oFo27_60ZBaigu0QjWk5N33QAA"
Via: SIP/2.0/TLS 172.16.93.11:5061;branch=z9hG4bK-2B43DB32;rport;alias;received=172.16.93.11;ms-received-port=60028;ms-received-cid=AD00
Record-Route: <sip:Lync2013-PC.innodemo.local:5061;transport=tls;opaque=state:F:Ci.Ra600;lr;ms-route-sig=aam67Qa-S2QyV9XEtcYaQRQjPC9PgzSs05BJukjXBgjxMu0QjWLwDDRgAA>;tag=45D3B960B6E2B498388A5465B5BFF35F
Max-Forwards: 58
Content-Length: 427
Content-Type: application/sdp
Message-Body: v=0\no=- 34 1 IN IP4 172.16.93.11\ns=-\nt=0 0\nm=audio 16422 RTP/AVP 18 4 8 0 101 13\nc=IN IP4 172.16.93.19\na=rtpmap:101 telephone-event/8000\na=fmtp:18 annexa=yes\na=fmtp:18 annexb=no\na=fmtp:101 0-15\na=ptime:60\na=silenceSupp:off - - - -\na=sendrecv\na=ice-ufrag:Xgox\na=ice-pwd:v8uT6XAZFNHQeDNrOtUWni\na=candidate:1
1 UDP 2130706431 172.16.93.19 16422 typ host\na=candidate:1 2 UDP 2130706430 172.16.93.19 16423 typ host
$$end_record
TL_INFO(TF_DIAG) [0]10CC.1314::08/05/2014-15:32:40.430.000000ca (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(778))[2344625192]
$$begin_record
Severity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 100 Trying
SIP-Call-ID: [email protected]
SIP-CSeq: 11892668 INVITE
Peer: ipva.innodemo.local:60028
$$end_record
ERROR message:
TL_ERROR(TF_COMPONENT) [0]10CC.1644::08/05/2014-15:32:43.159.000000d4 (SIPStack,CSIPRequest::ProcessVia:SIPRequest.cpp(685))
( 00000016ABEDAD40 ) Exit - the via header contains unexpected received-cid attribute. Returned 0xC3E93F04(SIPPROXY_E_REQUEST_NO_CORRECT_VIA)
TL_ERROR(TF_COMPONENT) [0]10CC.1644::08/05/2014-15:32:43.159.000000d5 (SIPStack,CSIPRequest::ValidateInboundHeaders:SIPRequest.cpp(1495))
( 00000016ABEDAD40 ) Exit - failed to ProcessVia(). Returned 0xC3E93F04(SIPPROXY_E_REQUEST_NO_CORRECT_VIA)
TL_WARN(TF_DIAG) [0]10CC.1644::08/05/2014-15:32:43.159.000000d6 (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(781))[2344625192]
$$begin_record
Severity: warning
Text: Routing error occurred; check Result-Code field for more information
Result-Code: 0xc3e93f04 SIPPROXY_E_REQUEST_NO_CORRECT_VIA
SIP-Start-Line: ACK sip:[email protected] SIP/2.0
SIP-Call-ID: [email protected]
SIP-CSeq: 11892668 ACK
Peer: ipva.innodemo.local:60028
$$end_record
So they are two different errors here, in the Lync client PC failed to verify the message, and in the FE it fail to validate the ms-received-cid in the via header.
What indeed looks to exist a mismatch between "A600" to "AD00", looks the 6 was replaced by 6.I believe this headers are generated internally by Lync FE, not sure what is going wrong here for this mismatch.
Any expert could give a look and have an hint why this weird behavior of Lync FE.
Thanks in advance,
Regards,
Claudio

Hi,
From your description, it happened after the setting of static route. Please double check the route setting. Then publish Topology again, and run Step 2 Setup or Remove Lync Server Components on Lync Server Deployment Wizard.
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support

Snom phones in secondary subnet unable to call out - SIP CANCEL in SIP log

I've been trying to diagnose this very strange problem we are having. All our servers and some SNOM phones are in the subnet 192.168.100.0, the main building. They all work fine. Phones located in two other buildings connected with high-speed fiber use subnets
192.168.1.0 and 192.168.200.0. They can receive calls but are unable to call out. This doesn't affect the Lync 2010 and 2013 desktop clients with enterprise voice...they work fine anywhere, even externally.
We are running Lync Server 2013 Standard Edition, with the latest updates applied. Mediation role is co-located. Edge server is setup and I think I have configured everything correctly. I have two network adapters, one external facing and one internal facing.
External facing one has dns settings and gateway, internal facing has neither. I have setup persistent routes that enable the edge server to ping hosts in 1.0 and 200.0 no problem. DNS is setup internally so anyone anywhere can ping the edge server (its dns
entry is routable lync2013edge.network.domain.ca). Phones used are the SNOM 720, I have the latest updates applied (8.8.3.27 UC)
On the actual SNOM phone, I will dial 7804636201. It will call and start ringing the other party. Almost exactly 10 seconds later I will hear a busy signal and then the phone displays "Media Connectivity Failure". I ran a log on SIP from the FE
Standard Edition server, here are some entries that I noticed that may have something to do with it (see bottom four paragraphs for SIP CANCEL)
TL_VERBOSE(TF_PARSE) [0]411C.2DE8::02/24/2015-17:23:42.240.0008db5d (SIPStack,CSIPMessage::ParseBufferChain:SIPMessage.cpp(694))( 0000005F03D806F0 ) Start Line: INVITE sip:7804636201;[email protected];user=phone SIP/2.0
TL_INFO(TF_PROTOCOL) [0]411C.2DE8::02/24/2015-17:23:42.269.0009106f (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3706963737] $$begin_record
Trace-Correlation-Id: 3706963737
Instance-Id: 2F91
Direction: outgoing
Peer: lync2013.network.caedm.ca:5070
Message-Type: request
Start-Line: INVITE sip:[email protected]:5070;user=phone;maddr=lync2013.network.caedm.ca SIP/2.0
From: "Joel Smith" <sip:[email protected]>;tag=2ksjs48fxg;epid=000413774E0401
To: <sip:7804636201;[email protected];user=phone>
Call-ID: 3faa35f677ef48719b27c796251b0519
CSeq: 1 INVITE
Contact: <sip:[email protected];opaque=user:epid:cO0WSS9wCFqUnP0dpEh6uQAA;gruu>;reg-id=1
Via: SIP/2.0/TLS 192.168.100.17:55489;branch=z9hG4bKE036484A.405BD23C943B158E;branched=TRUE
Via: SIP/2.0/TLS 192.168.1.201:51470;branch=z9hG4bK-fdh7rhbbvsri;rport;ms-received-port=51470;ms-received-cid=600
Record-Route: <sip:Lync2013.network.caedm.ca:5061;transport=tls;opaque=state:T;lr>;tag=B39FB8145D545F357B2737F43833CEB4
Max-Forwards: 69
Content-Length: 3563
Content-Type: multipart/alternative;boundary="next_part_u00iwyrezkkuxf3d"
P-Asserted-Identity: "Joel Smith"<tel:+17808092404;ext=2404>
Message-Body: --next_part_u00iwyrezkkuxf3d
Content-Type: application/sdp
Content-Transfer-Encoding: 7bit
Content-Dis; handling=optional; ms-proxy-2007fallback
TL_INFO(TF_DIAG) [0]411C.2DE8::02/24/2015-17:23:42.270.000915ec (SIPStack,SIPAdminLog::WriteDiagnosticEvent:SIPAdminLog.cpp(802))[3706963737] $$begin_record
Severity: information
Text: Routed a locally generated response
SIP-Start-Line: SIP/2.0 100 Trying
SIP-Call-ID: 3faa35f677ef48719b27c796251b0519
SIP-CSeq: 1 INVITE
Peer: 192.168.1.201:51470
Data: destination="[email protected]"
$$end_record
TL_INFO(TF_PROTOCOL) [0]411C.2DE8::02/24/2015-17:23:42.274.000928d4 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3706963737] $$begin_record
Trace-Correlation-Id: 3706963737
Instance-Id: 2F93
Direction: outgoing;source="local"
Peer: 192.168.1.201:51470
Message-Type: response
Start-Line: SIP/2.0 101 Progress Report
From: "Joel Smith" <sip:[email protected]>;tag=2ksjs48fxg;epid=000413774E0401
To: <sip:7804636201;[email protected];user=phone>
Call-ID: 3faa35f677ef48719b27c796251b0519
CSeq: 1 INVITE
Via: SIP/2.0/TLS 192.168.1.201:51470;branch=z9hG4bK-fdh7rhbbvsri;rport;ms-received-port=51470;ms-received-cid=600
Content-Length: 0
ms-diagnostics: 12006;reason="Trying next hop";source="LYNC2013.NETWORK.CAEDM.CA";PhoneUsage="Long Distance";PhoneRoute="LocalRoute";Gateway="208.68.17.53";appName="OutboundRouting"
$$end_record
TL_INFO(TF_PROTOCOL) [1]411C.2DE8::02/24/2015-17:23:42.488.000930bc (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[741182734] $$begin_record
Trace-Correlation-Id: 741182734
Instance-Id: 2F96
Direction: incoming
Peer: lync2013.network.caedm.ca:5070
Message-Type: response
Start-Line: SIP/2.0 183 Session Progress
FROM: "Joel Smith"<sip:[email protected]>;tag=2ksjs48fxg;epid=000413774E0401
TO: <sip:7804636201;[email protected];user=phone>;tag=d265bdc1c8;epid=0A24894D6D
CALL-ID: 3faa35f677ef48719b27c796251b0519
CSEQ: 1 INVITE
CONTACT: <sip:[email protected];gruu;opaque=srvr:MediationServer:0wzNMLUTNFKXO5KjW1mbdQAA>;isGateway
VIA: SIP/2.0/TLS 192.168.100.17:55489;branch=z9hG4bKE036484A.405BD23C943B158E;branched=TRUE,SIP/2.0/TLS 192.168.1.201:51470;branch=z9hG4bK-fdh7rhbbvsri;rport;ms-received-port=51470;ms-received-cid=600
RECORD-ROUTE: <sip:Lync2013.network.caedm.ca:5061;transport=tls;opaque=state:T;lr>;tag=B39FB8145D545F357B2737F43833CEB4
CONTENT-LENGTH: 1388
CONTENT-TYPE: application/sdp
TL_VERBOSE(TF_NETWORK) [0]411C.2DE8::02/24/2015-17:23:51.369.00098f6b (SIPStack,CRecvContext::CreateIncomingRequest:RecvContext.cpp(920))[3030787245]( 0000005F01E739D0 ) creating SIP_MID_CANCEL request
TL_VERBOSE(TF_PARSE) [0]411C.2DE8::02/24/2015-17:23:51.369.00098f90 (SIPStack,CSIPMessage::ParseBufferChain:SIPMessage.cpp(694))( 0000005F03D7E2E0 ) Start Line: CANCEL sip:7804636201;[email protected];user=phone SIP/2.0
TL_VERBOSE(TF_PARSE) [0]411C.2DE8::02/24/2015-17:23:51.369.00099054 (SIPStack,CSIPMessage::ParseNextHeader:SIPMessage.cpp(1532))( 0000005F03D7E2E0 ) Found Header: Reason: SIP;cause=488;text="Media Connectivity Failure"
TL_INFO(TF_PROTOCOL) [0]411C.2DE8::02/24/2015-17:23:51.369.000990c6 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:ProtocolRecord.cpp(265))[3706963737] $$begin_record
Trace-Correlation-Id: 3706963737
Instance-Id: 2FA0
Direction: incoming
Peer: 192.168.1.201:51470
Message-Type: request
Start-Line: CANCEL sip:7804636201;[email protected];user=phone SIP/2.0
From: "Joel Smith" <sip:[email protected]>;tag=2ksjs48fxg;epid=000413774E0401
To: <sip:7804636201;[email protected];user=phone>
Call-ID: 3faa35f677ef48719b27c796251b0519
CSeq: 1 CANCEL
Via: SIP/2.0/TLS 192.168.1.201:51470;branch=z9hG4bK-fdh7rhbbvsri;rport
Max-Forwards: 70
Content-Length: 0
$$end_record
I thought it might be a timeout issue, so I tried following these steps located here:
http://ipfone.hu/lync-mediation-server-cancel-problem/ After rebooting the server no changes were noticed.
I also checked out this website
http://blog.insidelync.com/2013/04/sip-trunking-101-with-lync-server-2013/ regarding disabling the check box "enable outbound routing failover timeout". Doing that had no effect.
Any other ideas would be appreciated.

Hi,
yes I see the config file is very simple and standard.
So the issue with snom on branch sites is random, it's correct?
From what I read in your answer, sometimes you can establish a correct communication between a snom and the called number +17804636201.
Have you tried to collect a network capture on a snom at branch location?
Do you have some other version of snom phone (300, 710, 821) to test?
Do you have some LPE ip-phone (Polycom CX600 o HP4110-4120) to test?
Regards
Luca
Luca Vitali | MCITP Lync/Exchange | snom Certified Engineer | Sonus SBC1000 Engineer

Lync 2013 Web Scheduler SMTP Server for invitations - non-exchange env

We cannot get the Lync 2013 Web Scheduler to send email invites to anyone even after configuring the SMTP server for both the external and internal sites on our one and only front-end (we did the super simple same box install for testing
purposes). Yes we have done an IISReset;) Has the SMTP server configuration process for the now built-in Lync 2013 Web Scheduler changed since the add-on Lync 2010 Web Scheduler?
BTW, unless we haven't search for the right phrase(s), it seems there is ZERO documentation about configuring this for 2013 - only for 2010.
HELP!!!

Hi,
You can refer to this blog Lync web scheduler without Exchange:
http://blog.lyncfreak.com/2011/11/02/lync-web-scheduler-without-exchange/
Note: Microsoft is providing this information as a convenience to you. The sites are not controlled by Microsoft. Microsoft cannot make any representations regarding the quality, safety, or suitability of any software or information found there. Please make
sure that you completely understand the risk before retrieving any suggestions from the above link.
Kent Huang
TechNet Community Support

Lync Federated and VPN to trusted forest

Trying to figure out how to work around this. I have a VPN between two companies. I have added the second company to my DNS as a secondary zone. As soon as I do this lync federation stops working. Obviously this is a DNS issue, but I have no idea how to
work around it. I can't wrap my head around what needs to be done to do this. The only thing that comes to mind is to create a primary zone for their domain and just populate the servers we need manually. Any ideas?

Federated conversations will route everything through the edge server. The edge servers will find each other using the _sipfederationtls._tcp SRV record. With the VPN in place, each edge will still need to be able to resolve that SRV record as well as
the host name inside of it. The host name should still resolve to the external access edge ip. If that all works, see if you can telnet from your edge to port 5061 on their access edge external ip. Also run the debug logger and watch sipstack for potential
clues.
Please remember, if you see a post that helped you please click "Vote As Helpful" and if it answered your question please click "Mark As Answer".
SWC Unified Communications

Accept invitation without sending repsonse?

I have my iphone connected to my Exchange account. I want to be able to accept meeting invites without sending a response to the meeting organizer.
Is that possible?

Actually, the "iCal" invite comes from Exchange. I can add them to my iCal calendar just fine but the reply sent back to the originator of the event does nothing for my status in the Exchange item -- I still show as tentative. All they get is an email that says I'll be attending (or not).
Since most folks I know around here don't really look to see who's attending or not, I'd rather just not send the response.
Your suggestion for disconnecting is interesting though. While that is not an option for me (I'm always connected to one or more servers), I could try going offline while accepting the invite and then delete the message.
I'll give that a try.
Thanks!

SIP Server vs SIP Servlet

Hello,
Can someone let me exact what the difference between SIP Server and SIP Servlet.?
Regards,
Deepak

It's hard to be precise since "SIP Server" does not have a precise definition, but I'll try to help.
The term SIP Server can apply to any network node meant to affect a SIP session. A server can act as SIP User Agent (UA), proxy, or back-to-back UA. Nothing about the way these applications are programmed is implied by the term "SIP Server."
The SIP Servlet API (SSAPI) is a popular technology for implementing SIP applications; therefore you could say that a SIP Servlet container is a type of SIP Server. The SSAPI is specified in [JSR 289|http://jcp.org/en/jsr/detail?id=289] , and is an extension of the familiar servlet model that is also used for programming HTTP applications.
OCCAS is a SIP Servlet container, and therefore also a SIP Server.
Hope this helps,
Tom.

How can I delete a spam calendar invitation without replying?

OS X 10.9.4, Calendar version 7.0 (1841.1)
I have a spam calendar invitation. I am pretty sure it did not come through email, since I can't find any email message in inbox, junk, trash, or anywhere else, with any content that matches this spam event.
Besides, "Add new invitations to Calendar" has been set to "Never" all along.
How can I get rid of this invitation without sending a reply to the spammer?
One suggestion I read is to move it to a local "on my mac" calendar first. I don't have any such calendar, and can't see a way to create one!

You might try just selecting the event and pressing the delete key. You would normally get a prompt with the option to delete without notifying:

How can I add a person to an event (and send that person an invite) without resending the meeting invitation to all participants?

How can I add a person to an event (and send that person an invite) without resending the meeting invitation to all participants?

Apple doesn't make it easy to do what you want. However, here's how I do it.
Select the photo you want to move and create a new Event for it via the Event ➙ Create Event menu option.
In the Event mode select the new Event with the one picture and drag it onto the Event you want to move the photo to.

Lync 2013 certificate requirements for multiple SIP domains

Hi All,
I am engaged with a client in respect of a Lync 2013 implementation initially as a conferencing platform with a view to enabling EV functions (inc. PSTN conferencing) in the future. They initially need to support 30 SIP domains and eventually
around 100 SIP domains which is proving to be either not possible or severely cost prohibitive. Their current certificate provider, Thawte, can only support up to 25 SANs and have quoted them 5 figures. We tend to use GeoTrust as they are cheaper but they
appear to have a limit of 25 SANs. GoDaddy appear to support up to 100 SANs for a pretty reasonable cost. My questions are as follows:
Is there a way that I’m missing of reducing the number of SANs required on the Edge server?
Use aliases for access edge FQDNs - Supported by desktop client but not by other devices so not really workable
Don’t support XMPP federation therefore removing the need for domain name FQDNs for each SIP domain
Is there a way that I’m missing of reducing the number of SANs required on the Reverse Proxy server?
Friendly URL option 3 from this page:
http://technet.microsoft.com/en-us/library/gg398287.aspx
Client auto-configuration:
i.
Don’t support mobile client auto-configuration in which case no lyncdiscover.sipdomain1.com DNS records or SANs would be required.
ii.
Support mobile client auto-configuration over HTTP only in which case CNAME records are required for each SIP domain (lyncdiscover.sipdomain1.com, etc. pointing to lyncdiscover.designateddomain.com) but no SANs are required.
iii.
Support mobile client auto-configuration over HTTPS in which case DNS records are required for each SIP domain and a SAN entry for each SIP domains is also required. This is because a DNS CNAME to another domain is not supported over
HTTPS.
If the answer to 1 and/or 2 is no, are there certificate providers that support over 100 SANs?
How do certificate requirements differ when using the Lync 2013 hosting pack? I would think that this issue is something that a hosting provider would need to overcome.
Would the Lync 2013 Hosting Pack work for this customer? The customer uses SPLA licensing so I think is eligible to use the hosting pack but not 100% sure it will work in their environment given that client connections are supposed
to all come through the Edge where their tenants will be internal and also given the requirement for an ACP for PSTN conferencing.
Many thanks,

Many thanks for the response.
I was already planning to use option 3 from the below page for simple URLs to cut down on SAN requirement.
http://technet.microsoft.com/en-us/library/gg398287.aspx
What are the security concerns for publishing autodiscover over port 80? I.e. Is this only used for the initial download of the discovery record and then HTTPS is used for authentication? This seems to be the case from the following note on the below page:
http://technet.microsoft.com/en-gb/library/hh690030.aspx
Mobile device clients do not support multiple Secure Sockets Layer (SSL) certificates from different domains. Therefore, CNAME redirection to different domains is not supported over HTTPS. For example, a DNS CNAME record for lyncdiscover.contoso.com that redirects
to an address of director.contoso.net is not supported over HTTPS.
In such a topology, a mobile device client needs to use HTTP for the first request, so that the CNAME redirection is resolved over HTTP. Subsequent requests then use HTTPS. To support this scenario, you need to configure your reverse proxy with a web publishing
rule for port 80 (HTTP).
For details, see "To create a web publishing rule for port 80" in Configuring the Reverse Proxy for Mobility. CNAME redirection to the same domain is supported over HTTPS. In this case, the destination domain's certificate covers the originating
domain.”
I don’t think SRV records for additional SIP domain access edge is a workable solution as this is not supported by some devices.
As per the below article:
http://blog.schertz.name/2012/07/lync-edge-server-best-practices/
“The recommended approach for external client Automatic Sign-In when supporting multiple SIP domains is to include a unique Access Edge FQDN for each domain name in the SAN field. This is no longer a requirement (it was in OCS) as it is possible to
create a DNS Service Locator Record (SRV) for each additional SIP domain yet have them all point back to the same original FQDN for the Access Edge service (e.g. sip.mslync.net).
This approach will trigger a security alert in Windows Lync clients which can be accepted by the user, but some other clients and devices are unable to connect when the Automatic Sign-In process returns a pair of SRV and Host (A) records which do not share
the same domain namespace. Thus it is still best practice to define a unique FQDN for each additional SIP domain and include that hostname in the external Edge certificate’s SAN field”.
===================
1. Basically the requirement is to initially provide Lync conferencing services (minus PSTN conferencing) to internal, external, federated and anonymous participants with a view to providing PSTN conferencing and therefore enterprise voice services later.
2. The customer currently supports close to 100 SMTP domains and wants to align their SIP domains with these existing domains. The structure of their business is such that “XXX IT Services” provide the IT infrastructure for a collection of companies who
fall under the XXX umbrella but are very much run as individual entities.
Question:
Would you agree that I’m going to need a SAN for every SIP domain’s access edge FQDN?
Thanks.

Voice gateway, SIP Options ping without SDP

Hi all.
I see following SIP options call-flow for sip options ping:
17907581: Jan 16 08:11:31.057: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
OPTIONS sip:10.250.20.25:5060 SIP/2.0
Via: SIP/2.0/UDP 10.11.3.17:9256;branch=z9hG4bKabuf3p5e3es57i595u9viaf77
Call-ID: [email protected]
From: <sip:[email protected]>;tag=sbc0800uf7upc43
To: <sip:10.250.20.25>
CSeq: 1 OPTIONS
Max-Forwards: 70
Content-Length: 0
17907583: Jan 16 08:11:31.057: //28111388/1CCF073F9ED3/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.11.3.17:9256;branch=z9hG4bKabuf3p5e3es57i595u9viaf77
From: <sip:[email protected]>;tag=sbc0800uf7upc43
To: <sip:10.250.20.25>;tag=BC08FBDC-1F16
Date: Fri, 16 Jan 2015 08:11:31 GMT
Call-ID: [email protected]
Server: Cisco-SIPGateway/IOS-15.4.20141104.060737.
CSeq: 1 OPTIONS
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
Allow-Events: telephone-event
Accept: application/sdp
Supported: timer,resource-priority,replaces,sdp-anat
Content-Type: application/sdp
Content-Length: 363
v=0
o=CiscoSystemsSIP-GW-UserAgent 1616 9170 IN IP4 10.13.4.43
s=SIP Call
c=IN IP4 10.13.4.43
t=0 0
m=audio 0 RTP/AVP 18 0 8 9 4 2 15
c=IN IP4 10.13.4.43
m=image 0 udptl t38
c=IN IP4 10.13.4.43
a=T38FaxVersion:0
a=T38MaxBitRate:9600
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:320
a=T38FaxUdpEC:t38UDPRedundancy
I know that this is normal behavior for voice gateway(3925 in our case).
Is it possible to disable SDP in 200 OK message going out to ITSP. They said that their PBX can't recognize 200 ok with SDP as reply to sip Options message.

Oleh,
I am not sure you can do this..
RFC3261 states the following:
The SIP method OPTIONS allows a UA to query another UA or a proxy
   server as to its capabilities. This allows a client to discover
   information about the supported methods, content types, extensions,
   codecs, etc. without "ringing" the other party. For example, before
   a client inserts a Require header field into an INVITE listing an
   option that it is not certain the destination UAS supports, the
   client can query the destination UAS with an OPTIONS to see if this
   option is returned in a Supported header field. All UAs MUST support
   the OPTIONS method.
If the response to an OPTIONS is generated by a proxy server, the
   proxy returns a 200 (OK), listing the capabilities of the server.
   The response does not contain a message body.
So it looks like your ITSP hasn't designed their system based on this RFC. When you send an OPTIONs message, the response has to include the capabilities the other party can support..

Combining Lync Edge certificate of Reverse Proxy

I wonder if the creation of a certificate from the combined Lync Edge server names and Reverse Proxy will work?
Wants to create a certificate for Lync Edge with CN = sip.domain.com and add names required for the Edge and Reverse Proxy as an additional DNS:
sip.domain.com
webconf.domain.com
webext.domain.com
meet.domain.com
dialin.domain.com
lyncdiscover.domain.com

Hi,
Yes, you can use the same certificate for both Edge Server (external interface) and Reverse Proxy, which SAN including all Edge Server and Reverse Proxy needed (such as: webcon.contoso.com, sip.contoso.com, webext.contoso.com, meet.contoso.com, dialin.contoso.com,
lyncdiscover.contoso.com, and so on).
More details:
https://technet.microsoft.com/en-us/library/gg398519.aspx?f=255&MSPPError=-2147217396
https://technet.microsoft.com/en-us/library/gg429704.aspx
There is no special SAN for federate with Skype. However, the certificate must be the public SAN certificate.
Best Regards,
Eason Huang
Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact [email protected]
Eason Huang
TechNet Community Support

Lync Federation and Push Notification with Lync Trusted model domain

Hi Team,
One of our customer has the query about office 365 push nofification support.
We have three kinds of federation types:
Dynamic
Direct
Enhanced
Questions:
Whether all the three are supported by office 365 push notification server or only specific federation type is supported?
Please advise. Many Thanks.

Hi,
Base on my understanding, as there is no special DNS requirements to enable federation for push notification. You only need to do the following steps:
Enable federation and public IM connectivity in Lync Server 2013
Create public SIP federated providers in Lync Server 2013
Create hosted SIP federated providers Lync Server 2013
More details:
https://technet.microsoft.com/en-us/library/hh690047.aspx
Best Regards,
Eason Huang
Eason Huang
TechNet Community Support

Lync 2013 edge-no reverse proxy question

I deployed lync 2013 edge server and no reverse proxy yet.I am trying to connect from my windows 7 machine with no luck and I can see a top reset on the firewall,my question is is reverse proxy required for the normal client to connect and do basic IM?
Plz confirm.thx

*****Update**********
now when i am trying to test connevity using microsoft connecvitry analyer i am getting error realted to the external certifictare stating that " certificate couldn't be validated because SSL negotiation
wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation." with UC troubleshotter i am getting the same.any idea?
PS certificate is from Digi
cert and i have checked the installation with thier tool and all was green
regards
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with the certificate installation.
The certificate couldn't be validated because SSL negotiation wasn't successful. This could have occurred as a result of a network error or because of a problem with
the certificate installation.

Lync Federation - Accept SIP Reverse Negotiation (SIP Invite without SDP)

Similar Messages

Maybe you are looking for