locked
Lync 2010 Colocated Mediation NAT with single IP on SIP trunk RRS feed

  • Question

  • I've read the previous posts on this and was wondering if someone's managed to make it work.  I had been using Lync just fine with another provider but am switching to Broadvox along with changing my ISP.  With my new ISP I only have a single public IP and am trying to get Lync to work as streamlined as possible.

    My current issue is the "one way audio" issue on outbound calls....audio is send out but not recieved in.  I'm using a Cisco SB WRVS4400N router with SALG (tried both enabled and disabled) as well as media bypass in Lync.  Other than getting an additional public IP or installing an additional border device / server has anyone made this work?

    Any suggestions or information requests appreciated!

    -trevor

    Friday, June 24, 2011 6:25 PM

Answers

  • Sorry all...technet forum notifications have failed me and I didn't check back in.  I wound up solving this by giving the system what it wanted...a static / routable IP.  Everything now working fine.

    • Proposed as answer by Lasse WedøMVP Wednesday, July 13, 2011 6:54 AM
    • Marked as answer by Sharon.Shen Wednesday, June 27, 2012 7:35 AM
    Saturday, July 9, 2011 12:13 AM

All replies

  • Hi,

     

    I do see your problem, and here's a few "things" popping into my mind:

    First of all, You can not enabe media bypass in your scenario when you are NAT'ng on the way out/in.

    Second: How do you control which session NAT's to Which IP (Or asked in another way; How is your NAT translations built in your firewall?  Have you created static rules siganlling only? Many take a look at the topology and sees sip thunk/gateway = TCP 5060 (or 50whatevere you have configured, 5060 is the default for most vendors), and fail to realize this is only the signalling port. You also have to create NAT rules for all the other ports used for media exchange. Have a look at the workloads poster to get the entire picture: http://www.microsoft.com/download/en/details.aspx?id=6797 (lower right corner for voice. Notice the green arrow for sip trunking = 5067? But do you also see all the red arrows with STUN and SRTP ports? The SRTP ports are the actual media channels, check with your vendor if these corresond, and see what your firewall/NAT unit does with the media channels coming in.

     

    Hope this helps a bit.

    KR


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    Friday, June 24, 2011 7:11 PM
  • Thanks for the reply.  I have 5060-5070 TCP configured as a static forward to Lync - additionally I've tried adding 1024-65535 UDP to Lync without success.

    Further thoughts?

     

    -trevor

    Friday, June 24, 2011 7:42 PM
  • Hi again,

    I know the text book says UDP. But the Lync documentation actually states TCP/UDP for the given range: http://www.microsoft.com/download/en/details.aspx?id=6797

    Have had a look at NAT debugging under a session? Made a call in a quiet hour, where it would be possible to see the actual session?

    How a bout your SIP trunk conig? Is it with our without SRTP? Are you sure the vendor supports whatever you have configured (has the vendor updated their config after you switched ISP?)

    I'ld also consider using wireshark (any good sniffer tool will do) on the client, to see if you could make anything out. And do a session with Lync server logging tool and snooper tool to see if you could get any hints there. Debug the SIP stack first, but if you can't see anything there, start adding mediastack RTP (or RTCP).

    What I really would like to see from these debug is if you get any RTP packets in at all. If you do, we'll have to dig into your Lync setup (But this should be ok, as it has worked before). If you don't, You'll have to take a closer look at the NAT/Firewall (Is there any sip-fixup in Cisco unit? That might really mess things up in some deployments), or talk to your sip provider for input.

    KR


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    Friday, June 24, 2011 8:05 PM
  • Thanks for the reply (again)...new ISP /and/ new SIP trunk provider too.  Previously I used a public IP for mediation but am trying to make it work wholly behind NAT.  Broadvox (new SIP provider) states media is UDP only from their turn-up docs.

    I'm actually a VAR and am trying to make this work in what would be a typical small office environment....single public IP behind generic internet service.  I'll get a trace capture of an outbound call and post it here.

    Thanks again!

    Friday, June 24, 2011 8:40 PM
  • The thing is: 

    The supported topology calls for the mediation server to have an IP address the ISP can ip-route to.

    You might be doing NAT on packeets, but when I come to think about the SIP messages, they might be giving the internal IP address as the source address in the SIP messages (not fqdn). And the SIP provider might not know where to return the setup. (I've seen this in other SIP implementations as well. Where I have ended up doing SIP header re-writes in border elements.)

    Would it be possible to create a static VPN to your SIP vendor, and route everything through it?

    Anyway, a debug session will soon show if my suspicion is correct.

    KR


    Lasse Wedø,
    Blog:Tech@work, Twitter: @lawedo

    Please take a second to hit the green arrow on the left if the post was helpful, or mark it as an answer if it resolved your issue.
    • Proposed as answer by Sean_Xiao Wednesday, June 29, 2011 9:53 AM
    Friday, June 24, 2011 8:47 PM
  • Hi,Trevor,

    How is your issue going on?

    If you have made any progress please share something with us.Thanks!

    Regards,

    Sharon

    Friday, July 8, 2011 2:16 AM
  • Sorry all...technet forum notifications have failed me and I didn't check back in.  I wound up solving this by giving the system what it wanted...a static / routable IP.  Everything now working fine.

    • Proposed as answer by Lasse WedøMVP Wednesday, July 13, 2011 6:54 AM
    • Marked as answer by Sharon.Shen Wednesday, June 27, 2012 7:35 AM
    Saturday, July 9, 2011 12:13 AM