locked
Skype calls dropping after approximately 30 seconds RRS feed

  • Question

  • Hi,

    I am working on setting up our Skype for Business infrastructure to allow Internal SIP calls, external PSTN calls (via our Cisco Call Manager), external SIP calls, internal meetings & external meetings.  So far Internal SIP calls, external PSTN calls & internal meetings work without issue.  External SIP calls (tested with both customers of ours & the Modality tester) fail after about 30 seconds and at best the other side can hear us.  Until this is fixed we aren't going to try external meetings.  I did have one test complete successfully, we have an Office 365 test environment for our software and SIP calls between a user in that environment and our local Skype for Business server did work without issues.  I had this rollout thrust on me and I'm not all that sure I have everything done right so any help people are able to provide will be greatly appreciated.

    Friday, December 8, 2017 7:39 PM

Answers

  • Have you done a complete sip trace on the cisco and on the SfB side.

    Mostly this problem could be also some configuration problem with the session timer?


    regards Holger Technical Specialist UC

    Holger,

    It isn't a problem with PSTN calls or calls between SfB & Cisco phones.  It was an issue with SfB to SfB calls when one party was outside our network.  Although the method I used to fix it isn't exactly what I wanted to do, I think it will work fine (putting the Edge & Reverse Proxy public legs outside our firewall & giving them Public IPs).

    • Marked as answer by shaunmccloud Friday, December 29, 2017 4:09 PM
    Tuesday, December 26, 2017 2:37 PM

All replies

  • Deleted
    Friday, December 8, 2017 8:46 PM
  • Nothing about it in the event log on the Edge server.  Now checking the firewall, but its slow going because I'm not 100% sure what an error message would say.
    Friday, December 8, 2017 9:14 PM
  • Okay

    Few ideas.

    a.

    Firewall is dropping the session

    b.

    Sounds like the SIP call is timing out and then dropping the call.  Call your provider.  Providers have a SIP INFO packet that checks that your SIP server is there and can take a call.  I am thinking that your SIP server is not sending back the SIP INFO packet.  

    You can do a WireShark capture on your SIP server and watch the INFO packet.

    Cheers

    Friday, December 8, 2017 11:36 PM
  • Hi shaunmccloud,

    You could make a external sip call between your on-premise user and online user?

    Do other users in your organization have the same problem?

    Please check the inbound port and out bound port like the following screenshot.

    Please check the SFB client log ,if have some error or warring such as SIP/2.0 504 Server time-out


    Regards,

    Leon Lu


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Monday, December 11, 2017 3:18 AM
  • Are there any update for this issue, if the reply is helpful to you, please try to mark it as an answer, it will help others who has similar issue.

    Regards,

    Leon Lu


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, December 13, 2017 9:08 AM
  • Okay

    Few ideas.

    a.

    Firewall is dropping the session

    b.

    Sounds like the SIP call is timing out and then dropping the call.  Call your provider.  Providers have a SIP INFO packet that checks that your SIP server is there and can take a call.  I am thinking that your SIP server is not sending back the SIP INFO packet.  

    You can do a WireShark capture on your SIP server and watch the INFO packet.

    Cheers

    Chris,

    I am talking about a Skype to Skype call with external users.  However, some work and some do not work which is weird.  It could still be a SIP issue so I am not ruling that out.  I will see what I can figure out on the firewall front, although we will probably be replacing our Watchguard with a Meraki soon.

    Friday, December 15, 2017 10:22 PM
  • Hi shaunmccloud,

    You could make a external sip call between your on-premise user and online user?

    Do other users in your organization have the same problem?

    Please check the inbound port and out bound port like the following screenshot.

    Please check the SFB client log ,if have some error or warring such as SIP/2.0 504 Server time-out


    Regards,

    Leon Lu


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Leon,

    I was able to successfully call from an online user to an on-prem user.  But if I try the Modality test tool for meetings at http://check.modalitysystems.net/test or the Event Zero Federation tester at https://www.eventzero.com/Tools/FederationTester3/ I have issues.  The Modality test tool disconnects the meeting after about 30 seconds and the Event Zero Federation tester messages (both voice and chat) get to me but they are not seeing that I did.  However, the chat one used to show success on their side.

    Friday, December 15, 2017 10:25 PM
  • Hi shaunmccloud,

    Thanks for your reply.

    So according your description, if I understand correctly, you have issue with your on-premise users when doing Skype call from external.

    I notice you have tested with some tools, could you share the errors of the testing with the tools?

    Another way, I also suggest that you could do a testing with a Skype for Business client, and collect the client side log for future analysis.

    For windows desktop client, you could find the client side log file “Lync-UccApi-0.UccApilog” under %userprofile%\AppData\Local\Microsoft\Office\1x.0\Lync\Tracing folder.

    The file can be opened with Notepad, you could search for related errors or information (e,g, SIP/2.0 BYE ) and post them in the forum.

    About the firewall ports, I suggest you could check the ports TCP 443, UDP 3478 are opened.


    Regards,

    Leon Lu


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Wednesday, December 20, 2017 5:42 AM
  • Did you check that the EDGE-Server´s external IPs are strictly UNROUTABLE to FE?

    Have a look at this:

    https://enablingtechcorp.com/Blog/TabId/777/ArtMID/2450/ArticleID/493/REALLY-IMPORTANT-Skype-for-Business-Edge-Server-Configuration-Note.aspx 

    I had a similar issue until i fixed that.

    Good luck - F.One


    • Edited by F.One Wednesday, December 20, 2017 7:17 AM
    Wednesday, December 20, 2017 7:15 AM
  • Hi Shaun,

    You can do a CLS logger and also check the SQL Skype reports under user activity. In the report check for the bye and look for any icewarn is occured (0x0 means no issues with firewall/nat/proxy etc).

    Greetings,

    Erdem


    Please mark as helpful if you find my contribution useful or as an answer if it does answer your question. That will encourage me - and others - to take time out to help you.

    Wednesday, December 20, 2017 8:06 AM
  • Did you check that the EDGE-Server´s external IPs are strictly UNROUTABLE to FE?

    Have a look at this:

    https://enablingtechcorp.com/Blog/TabId/777/ArtMID/2450/ArticleID/493/REALLY-IMPORTANT-Skype-for-Business-Edge-Server-Configuration-Note.aspx 

    I had a similar issue until i fixed that.

    Good luck - F.One

    Following those directions, it appears I have an issue on my router.  I will have to dig into it to see how to fix it, or if I even should right now with a router replacement coming up very soon.
    • Edited by shaunmccloud Wednesday, December 20, 2017 2:05 PM
    Wednesday, December 20, 2017 1:53 PM
  • Simply fire up new eth:x-rules at windows firewall on your Edge server for incoming and outgoing connection from/to your FE via these given 3 external IPs. That would solve this routing issue, too.

    If this can cure your 30s issue you will see in 2 minutes than.

    If not:

    Fire up Incoming/outgoing call scenario in CLS logger, reproduce your issue and take a look in snooper for reason.

    Cheers, F.One

    Wednesday, December 20, 2017 3:55 PM
  • Simply fire up new eth:x-rules at windows firewall on your Edge server for incoming and outgoing connection from/to your FE via these given 3 external IPs. That would solve this routing issue, too.

    If this can cure your 30s issue you will see in 2 minutes than.

    If not:

    Fire up Incoming/outgoing call scenario in CLS logger, reproduce your issue and take a look in snooper for reason.

    Cheers, F.One

    Well, we have the firewall disabled on our Edge Server so I would have to enable that (I know, not the best idea but it is what it is).
    Wednesday, December 20, 2017 4:10 PM
  • Dont´t worry about setting the firewall to "on":

    The install wizard has created all the rules you need for the given SfB roles you installed. Simply add the rules I mentioned.

    Wednesday, December 20, 2017 4:30 PM
  • Leon,

    Here is what I think is the relevant part of the log for my most recent test (University of Iowa instead of Modality).

    uthentication-Info: TLS-DSK qop="auth", opaque="FF12745D", srand="458234FE", snum="37", rspauth="00489bc659a03caf069c635273bdcaf553fb3955", targetname="UnimaxS4B.unimax.local", realm="SIP Communications Service", version=4
    
    From: <sip:smccloud@unimax.com>;tag=c94e6cc3db;epid=c8f9c348d3
    
    To: <sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL>
    
    Call-ID: d08b8c90ac264013a7ffe42c3e33f3c0
    
    CSeq: 1 INVITE
    
    Via: SIP/2.0/TLS 192.168.24.17:52679;ms-received-port=52679;ms-received-cid=AF76700
    
    Server: http%3A%2F%2Fwww.microsoft.com%2FLCS%2FUdcAgent
    
    Content-Length: 0
    
    
    
    
    12/20/2017|10:15:02.846 18E0:5E0 INFO  :: End of Data Received -192.168.25.181:5061 (To Local Address: 192.168.24.17:52679) 606 bytes
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPMessageCollator::AsyncProcessSipMsg - [0x1CBA0C88]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CBA0C88]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CA1E910]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: SECURE_SOCKET: decrypting buffer size: 469 (first 8):
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: 	17 03 03 01 D0 79 B5 71  :....Ðyµq
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CBE3FF0]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPCompression::DecompressRecvBuffer decompression, BytesProcessed = 387, cbDataDeCompressed = 951, psDecompressedData = 0DA76700 
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0DC21390]
    12/20/2017|10:15:02.846 18E0:5E0 INFO  :: Data Received -192.168.25.181:5061 (To Local Address: 192.168.24.17:52679) 951 bytes:
    12/20/2017|10:15:02.846 18E0:5E0 INFO  :: SIP/2.0 504 Server time-out
    
    Authentication-Info: TLS-DSK qop="auth", opaque="FF12745D", srand="95D99653", snum="38", rspauth="bcb9de95e9cea4b414f3f4b2c0ba12852ae1228b", targetname="UnimaxS4B.unimax.local", realm="SIP Communications Service", version=4
    
    Via: SIP/2.0/TLS 192.168.24.17:52679;ms-received-port=52679;ms-received-cid=AF76700
    
    Content-Length: 0
    
    From: "Shaun McCloud"<sip:smccloud@unimax.com>;tag=c94e6cc3db;epid=c8f9c348d3
    
    To: <sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL>;tag=5A8F0F960CAF97FB679B5DCBA20E749A
    
    Call-ID: d08b8c90ac264013a7ffe42c3e33f3c0
    
    CSeq: 1 INVITE
    
    Server: RTC/6.0
    
    ms-edge-proxy-message-trust: ms-source-type=AutoFederation;ms-ep-fqdn=edge.unimax.com;ms-source-verified-user=unverified;ms-source-network=federation
    
    ms-diagnostics: 1034;reason="Previous hop federated peer did not report diagnostic information";Domain="uiowa.edu";PeerServer="ocs-edge.uiowa.edu";source="edge.unimax.com"
    
    
    
    
    12/20/2017|10:15:02.846 18E0:5E0 INFO  :: End of Data Received -192.168.25.181:5061 (To Local Address: 192.168.24.17:52679) 951 bytes
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPMessageCollator::AsyncProcessSipMsg - [0x1CBA0C88]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CBA0C88]
    12/20/2017|10:15:02.846 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CA1E910]
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: verified buffer: <TLS-DSK><458234FE><37><SIP Communications Service><UnimaxS4B.unimax.local><d08b8c90ac264013a7ffe42c3e33f3c0><1><INVITE><sip:smccloud@unimax.com><c94e6cc3db><sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL><><><><><100>-length-239. signature:00489bc659a03caf069c635273bdcaf553fb3955
    12/20/2017|10:15:02.849 18E0:5E0 INFO  :: Trxn corr-id (248B03C8), SIP msg corr-id (5fabf3bb)
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: call.SetState[24B1E1B8]  SIP_CALL_STATE_CONNECTING-->SIP_CALL_STATE_ALERTING for sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL, stack=17C55008
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: SIP_CALL::NotifyCallStateChange[24B1E1B8] : CallState : 5 StatusCode: ef0064, s=5
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: MULTIPARTY_SESSION::NotifyCallChange[248DAE10]- call-leg:24B1E1B8, Callstate:5 StatusCode:ef0064 SessionState:3
    12/20/2017|10:15:02.849 18E0:5E0 INFO  :: MSP.SetState[248DAE10] SIP_CALL_STATE_CONNECTING->SIP_CALL_STATE_ALERTING, local=sip:smccloud@unimax.com
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: verified buffer: <TLS-DSK><95D99653><38><SIP Communications Service><UnimaxS4B.unimax.local><d08b8c90ac264013a7ffe42c3e33f3c0><1><INVITE><sip:smccloud@unimax.com><c94e6cc3db><sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL><5A8F0F960CAF97FB679B5DCBA20E749A><><><><504>-length-271. signature:bcb9de95e9cea4b414f3f4b2c0ba12852ae1228b
    12/20/2017|10:15:02.849 18E0:5E0 INFO  :: Trxn corr-id (248B03C8), SIP msg corr-id (5fabf3bb)
    12/20/2017|10:15:02.849 18E0:5E0 TRACE :: AddTag 24B1E210-<sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL>;tag=5A8F0F960CAF97FB679B5DCBA20E749A, local=sip:smccloud@unimax.com
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: Sending Packet - 192.168.25.181:5061 (From Local Address: 192.168.24.17:52679) 679 bytes:
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: ACK sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL SIP/2.0
    
    Via: SIP/2.0/TLS 192.168.24.17:52679
    
    Max-Forwards: 70
    
    From: <sip:smccloud@unimax.com>;tag=c94e6cc3db;epid=c8f9c348d3
    
    To: <sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL>;tag=5A8F0F960CAF97FB679B5DCBA20E749A
    
    Call-ID: d08b8c90ac264013a7ffe42c3e33f3c0
    
    CSeq: 1 ACK
    
    User-Agent: UCCAPI/16.0.4627.1000 OC/16.0.4627.1000 (Skype for Business)
    
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="FF12745D", targetname="UnimaxS4B.unimax.local", crand="402e72e1", cnum="33", response="0fcc5cf86c5dc1b0a23383054f7031e910e53a75"
    
    Content-Length: 0
    
    
    
    
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: End of Sending Packet - 192.168.25.181:5061 (From Local Address: 192.168.24.17:52679) 679 bytes
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPCompression::CompressSendBuffer after compression, BytesLeft = 679, BytesProcessed = 679, cbDataCompressed = 127, psCompressedData = 249143A8 
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: - encrypted buffer length: 197 bytes.  First 8 bytes:
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: 	17 03 03 00 C0 2C EB 62  :....À,ëb
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPTransportLayerSecurity::Send after encryption, BytesLeft = 127, BytesProcessed = 127, cbEncryptedBufSize = 197, spEncryptedBuff = 241C63D8 
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPAsyncSocket::Send this 1C948050, sending pbSendBuf 241C63D8, dwSendBufSize = 197
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPAsyncSocket::SendHelper - [0x1C948050]
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CAsyncSocketWin32::Send this 1CBB6508, pbSendBuf 241C63D8, dwSendBufSize = 197, dwBytesSent = 197
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: SIP_CALL::SendNextPendingMessageInfo MESSAGE/INFO was not sent, this 24B1E1B8
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: call.SetState[24B1E1B8]  SIP_CALL_STATE_ALERTING-->SIP_CALL_STATE_DISCONNECTED for sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL, stack=17C55008
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: SIP_CALL::NotifyCallStateChange[24B1E1B8] : CallState : 2 StatusCode: 80ef01f8, s=2
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: MULTIPARTY_SESSION::NotifyCallChange[248DAE10]- call-leg:24B1E1B8, Callstate:2 StatusCode:80ef01f8 SessionState:5
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: There is no Service-Route to copy
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: SIP_MSG_PROCESSOR::OnRequestConnectionConnectComplete - Enter this: 24D9B600, callid=(null), ErrorCode: 0x0
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: Outgoing 24D9B600-<sip:smccloud@unimax.com>, local=sip:smccloud@unimax.com
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: Out trxn corr-id (2469F0C8)
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: Trxn corr-id (2469F0C8), SIP msg corr-id (c60b35dd)
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: Sending Packet - 192.168.25.181:5061 (From Local Address: 192.168.24.17:52679) 1258 bytes:
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: SERVICE sip:smccloud@unimax.com SIP/2.0
    
    Via: SIP/2.0/TLS 192.168.24.17:52679
    
    Max-Forwards: 70
    
    From: <sip:smccloud@unimax.com>;tag=8fe35341b8;epid=c8f9c348d3
    
    To: <sip:smccloud@unimax.com>
    
    Call-ID: 5c20cf462bcc4116aad98cab1ee0776d
    
    CSeq: 1 SERVICE
    
    Contact: <sip:smccloud@unimax.com;opaque=user:epid:mtIPna120FKry-VsKmVqSAAA;gruu>
    
    User-Agent: UCCAPI/16.0.4627.1000 OC/16.0.4627.1000 (Skype for Business)
    
    Proxy-Authorization: TLS-DSK qop="auth", realm="SIP Communications Service", opaque="FF12745D", targetname="UnimaxS4B.unimax.local", crand="8f1aaa9b", cnum="34", response="7bae759459e8f5fc4445efc97e6aa42adb757ad2"
    
    Content-Type: application/msrtc-reporterror+xml
    
    Content-Length: 562
    
    
    
    <reportError xmlns="http://schemas.microsoft.com/2006/09/sip/error-reporting"><error toUri="sip:its-skype-test@uiowa.edu;gruu;opaque=app:conf:focus:id:90Y5QVFL" callId="d08b8c90ac264013a7ffe42c3e33f3c0" fromTag="c94e6cc3db" toTag="5A8F0F960CAF97FB679B5DCBA20E749A" contentType="application/cccp+xml" responseCode="504" requestType="INVITE"><diagHeader>1034;reason="Previous hop federated peer did not report diagnostic information";Domain="uiowa.edu";PeerServer="ocs-edge.uiowa.edu";source="edge.unimax.com"</diagHeader><progressReports/></error></reportError>
    
    
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: End of Sending Packet - 192.168.25.181:5061 (From Local Address: 192.168.24.17:52679) 1258 bytes
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPCompression::CompressSendBuffer after compression, BytesLeft = 1258, BytesProcessed = 1258, cbDataCompressed = 422, psCompressedData = 246DCB78 
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: - encrypted buffer length: 501 bytes.  First 8 bytes:
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: 	17 03 03 01 F0 11 3E 8C  :....ð.>Œ
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPTransportLayerSecurity::Send after encryption, BytesLeft = 422, BytesProcessed = 422, cbEncryptedBufSize = 501, spEncryptedBuff = 2449F178 
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPAsyncSocket::Send this 1C948050, sending pbSendBuf 2449F178, dwSendBufSize = 501
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CSIPAsyncSocket::SendHelper - [0x1C948050]
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CAsyncSocketWin32::Send this 1CBB6508, pbSendBuf 2449F178, dwSendBufSize = 501, dwBytesSent = 501
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: MULTIPARTY_SESSION::HandleCallLegNotifyDisconnect number of participants remaining 0, this 248DAE10
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: MSP.SetState[248DAE10] SIP_CALL_STATE_ALERTING->SIP_CALL_STATE_DISCONNECTED, local=sip:smccloud@unimax.com
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: CUccConfSession::Cleanup - entering [24AA5BB8], hr=0x80ef01f8, text=Server time-out, retryAfter=0
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: CUccConfSession::Disconnect - really disconnecting ...
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: MULTIPARTY_SESSION::Disconnect - enter [0x248DAE10]
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: MULTIPARTY_SESSION::InternalDisconnect[248DAE10] state 2, sc=0, t=(null)
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: CUccSessionParticipant::InternalSetState [24473388] - state: 0x1->0x5
    12/20/2017|10:15:02.850 18E0:5E0 TRACE :: CUccSession::InternalRemoveParticipant - Removing participant sip:smccloud@unimax.com
    12/20/2017|10:15:02.850 18E0:5E0 INFO  :: CUccConfSession::Cleanup - exiting [24AA5BB8]
    12/20/2017|10:15:02.851 18E0:5E0 TRACE :: CUccNotificationDispatcher::RegisterForUpdates - [0x1CBBB018]
    12/20/2017|10:15:02.851 18E0:5E0 INFO  :: CUccServerEndpoint::Initialize - Using the default compression Setting(UCCSCS_ENABLED_BASED_ON_ADAPTER_SPEED): 2
    12/20/2017|10:15:02.851 18E0:5E0 INFO  :: CUccEndpoint::put_TelephonyTypewrite - Set TTY enabled to false
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: domainName:uiowa.edu: serviceName:sipinternaltls: transportName:tcp:
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: Function: StringToSockAddress
    12/20/2017|10:15:02.852 18E0:5E0 ERROR :: HRESULT failed: 80072726 = HRESULT_FROM_WIN32(::ShimWSAGetLastError()) . Failed to convert string IP to SOCKADDR
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: Created Async workitem 24C9192C, txn timeout 0, time sensitive 0, txn (00000000)
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: domainName:uiowa.edu: serviceName:sip: transportName:tls:
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: Function: StringToSockAddress
    12/20/2017|10:15:02.852 18E0:5E0 ERROR :: HRESULT failed: 80072726 = HRESULT_FROM_WIN32(::ShimWSAGetLastError()) . Failed to convert string IP to SOCKADDR
    12/20/2017|10:15:02.852 18E0:5E0 INFO  :: Created Async workitem 24AE560C, txn timeout 0, time sensitive 0, txn (00000000)
    12/20/2017|10:15:02.852 18E0:1944 INFO  :: QueryDNSSrv - DNS Name[_sipinternaltls._tcp.uiowa.edu]
    12/20/2017|10:15:02.852 18E0:5E0 TRACE :: CUccConfSession::InternalGetCERProperties: Condition failed with 80ee0058: 'm_spCERProperties.IsValid()'
    12/20/2017|10:15:02.852 18E0:5E0 ERROR :: CUccSession::GetCallErrorRecordProperties: HRESULT API failed: 80ee0058 = hr. Get CER properties
    12/20/2017|10:15:02.852 18E0:5E0 TRACE :: SIP_URL::IsBaseListContainedInCompareList - No match found for SIP_URL_PARAM with m_ParamName opaque 
    12/20/2017|10:15:02.891 18E0:1944 ERROR :: QueryDNSSrv GetDnsResults query: _sipinternaltls._tcp.uiowa.edu failed 8007232b
    12/20/2017|10:15:02.891 18E0:1944 ERROR :: DNS_RESOLUTION_WORKITEM::ProcessWorkItem ResolveHostName failed 8007232b
    12/20/2017|10:15:02.891 18E0:1944 INFO  :: QueryDNSSrv - DNS Name[_sip._tls.uiowa.edu]
    12/20/2017|10:15:02.891 18E0:5E0 INFO  :: CUccDnsQuery::UpdateLookup - error code=80ee0066, index=0
    12/20/2017|10:15:02.892 18E0:5E0 INFO  :: CUccDnsQuery::CompleteLookup - index=0
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1C948058]
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: SECURE_SOCKET: decrypting buffer size: 261 (first 8):
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: 	17 03 03 01 00 7A 5D 77  :.....z]w
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x1CBE3FF0]
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: CSIPCompression::DecompressRecvBuffer decompression, BytesProcessed = 182, cbDataDeCompressed = 554, psDecompressedData = 24918F18 
    12/20/2017|10:15:02.901 18E0:5E0 TRACE :: CSIPTransportLayerNotify::OnRecv - [0x0DC21390]
    12/20/2017|10:15:02.901 18E0:5E0 INFO  :: Data Received -192.168.25.181:5061 (To Local Address: 192.168.24.17:52679) 554 bytes:
    12/20/2017|10:15:02.901 18E0:5E0 INFO  :: SIP/2.0 200 OK

    Wednesday, December 20, 2017 4:32 PM
  • Firewall is back on, but I'm still not 100% understanding how you worded the rules that need to be added.
    Wednesday, December 20, 2017 4:37 PM
  • Sorry.

    You have to create inbound and outbound rules on your edge server.

    You have to do that in "advanced mode" to specify local IP and remote IP. I put the whole /24 network in there but this depends on your settings of course...

    Cheers, F.One

    Wednesday, December 20, 2017 4:46 PM
  • Ok, telling it to to deny all traffic from the internal network (other then RDP) correct?  Sorry for all the questions, but at the current the current time my brain is just having issues wrapping around what I need to do.
    Wednesday, December 20, 2017 4:51 PM
  • No, ALL traffic from your FE must not pass to the NATed external IPs of your edge server and vice versa. RDP you have to do against the INTERNAL IP of your edge.

    Did you set up your edge correctly...? Just have a look at the link I posted above, everything is explained there:

    https://enablingtechcorp.com/Blog/TabId/777/ArtMID/2450/ArticleID/493/REALLY-IMPORTANT-Skype-for-Business-Edge-Server-Configuration-Note.aspx  

    Cheers, F.One


    • Edited by F.One Wednesday, December 20, 2017 4:57 PM
    Wednesday, December 20, 2017 4:57 PM
  • Following the directions at that link it appears to be setup correctly.

    PS C:\Users\smccloud> pathping 10.0.4.4

    Tracing route to 10.0.4.4 over a maximum of 30 hops

      0  XXXXXXXXX.unimax.XXXXX [192.168.25.181] - FE server
      1  XXXXXXXX.unimax.XXXXX [192.168.25.254] - Managed switch
      2  192.168.235.254 - Router
      3  10.0.4.4 - NATed IP of Edge Server

    Wednesday, December 20, 2017 5:05 PM
  • Nope, this is NOT correct - as described in my linked document. Read it again carefully: You MUST NOT get an answer from your NATed IP to your FE.

    Maybe you are too exhausted today. Have a break I would suggest and give it a try tomorrow - I know these days are hard struggeling with VoIP...

    Cheers, F.One

    Wednesday, December 20, 2017 5:12 PM
  • Actually, that was a typo on my part.  Corrected is below.  I am thinking our firewall is dropping the connection, so I will look at its logs.

    PS C:\Users\smccloud> pathping 10.0.4.4

    Tracing route to 10.0.4.4 over a maximum of 30 hops

      0  XXXXXXXXX.unimax.XXXXX [192.168.25.181]
      1  XXXXXXXX.unimax.XXXXX [192.168.25.254]
      2  192.168.235.254
      3     *        *        *


    • Edited by shaunmccloud Wednesday, December 20, 2017 5:46 PM
    Wednesday, December 20, 2017 5:46 PM
  • Thinking it was a firewall issue and considering the fact that the new firewall will not be installed until February at this point, I put out edge & reverse proxy servers in front of the firewall with public IPs.  So far everything is working fine, and the firewalls are enabled on them.  The one thing I'm having issues with the Modality test tool I've been using is down.  Does anyone else have site they use to test meetings?
    Friday, December 22, 2017 7:27 PM
  • Have you done a complete sip trace on the cisco and on the SfB side.

    Mostly this problem could be also some configuration problem with the session timer?


    regards Holger Technical Specialist UC

    Friday, December 22, 2017 11:47 PM
  • Have you done a complete sip trace on the cisco and on the SfB side.

    Mostly this problem could be also some configuration problem with the session timer?


    regards Holger Technical Specialist UC

    Holger,

    It isn't a problem with PSTN calls or calls between SfB & Cisco phones.  It was an issue with SfB to SfB calls when one party was outside our network.  Although the method I used to fix it isn't exactly what I wanted to do, I think it will work fine (putting the Edge & Reverse Proxy public legs outside our firewall & giving them Public IPs).

    • Marked as answer by shaunmccloud Friday, December 29, 2017 4:09 PM
    Tuesday, December 26, 2017 2:37 PM
  • Thanks for your update.

    Regards,

    Leon Lu


    Please remember to mark the replies as answers if they helped.
    If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Saturday, December 30, 2017 4:57 AM
  • Hi shaunmccloud,

    Ok, if the call is dropped after 30 seconds, it is a problem with the edge leg. The proxy server is not involved in this scenario.

    If you will use NAT for the edge you have to configure the internal A/V IP for this scenario.

    If you Edge will not work behind your firewall, you should check, that no state full inspection for this traffic is activated.


    regards Holger Technical Specialist UC

    Saturday, December 30, 2017 9:57 AM