locked
Communicator to Communicator Call problems - Federated Partners RRS feed

  • Question

  • Hi,

     

    I've recently come across an odd OCS 2007 issue that has me stumped on whats wrong. Essentially it's in establishing OCS calls to federated partners via our edge server. I can monitor the SIP traffic with the snooper tool from the RESKIT and everything looks great up until the SDP is negotiated via the SIP ACK. But no RTP session is ever established past the SIP/SDP traffic talking about it. I assume this is why IM has no problems, as we don't see a problem with SIP. Literally 10 seconds after the SIP ACK i see the following error in the SIP BYE when the call is torn down.

    Ms-client-diagnostics:  52031; reason="Call terminated on media connectivity failure"

    Researching this error has not lead to any successful resoltions as yet.

     

    If I perform a wireshark, I can see my client sending lots of STUN packets to our federated partners edge, but no replies are recieved. On a working example (thanks to a friends setup) I can see STUN packets returning. Its almost as if federated partners are simply ignoring our request for an RTP Stream. (we are running a comodo SAN cert on the edge)

     

    anyway - whats even more bazzar is that Live Meeting works flawlessly for everyone. Internal, external and federated partners. I should mention that our consolidated Edge server has fully routable interfaces for all three Edge Roles, and yes it has been working for about 6 months until recently.

     

    anyway - I'd love to hear any feedback or thoughts about what could be wrong..

     

    thanks

     

    Courtenay

    Wednesday, September 17, 2008 1:01 PM

Answers

  • Understood - I thought from your first message that the problem was only with one federated partner.  Your configuration is exactly like mine in that everything is at a data center and you are always a remote user.  That in itself shouldn't be a problem - our federation with partners, including Microsoft, works perfectly with audio and video.

     

    Based on your description it sounds like either the ports aren't open or your A/V Edge doesn't have a public, non-NAT'ed IP address.  If you add me as a contact (address is in my profile) we can give it a shot and I'll gather a trace from my side to see what the issue is.

    Thursday, September 18, 2008 2:56 PM
    Moderator

All replies

  • Has calling ever worked with your federated partner?  It sounds to me like their A/V Edge or firewall is not properly configured.

    Wednesday, September 17, 2008 1:06 PM
    Moderator
  • One possiblity is that the firewall team on the other side has recently closed TCP & UDP ports 50,000-59,999. those are the ports that federated voice/video require. If these are closed, you'll be able to send signalling back & forth and have communicator ring, but the stream will obviously never cut through.

     

    I'd have the partner on the remote end get confirmation from the firewall person/people that those ports are still open.

     

    Regards,

    Matt

     

    Wednesday, September 17, 2008 2:31 PM
  •  

    Hi Mike,

     

    I've got a feeling that the problem is residing with my config rather then our partners. SImply becasue we are federated with a few partners, Microsoft included and we can't open a Communicator 2 Communicator call to any of them.

     

    I know it would be time for a Holiday if I were paraniod enough to think that all of our federated partners decided to simulatneously change their RTP ports.

     

    BPA's all come through cleanly - and we can obvioulsy use our edge server for everything else. Just wondering, being that the SIP traffic will go to the AccessEdge IP Address and once SIP/SDP has negotiated. Should i start to see my client talking peer to peer or peer to partners-edge. My understanding is that the A/V Edge Server role are only used to multiplex voice/video calls when more than two parties are involved in a call.

     

    If I know what that exact traffic flow is for a call then I should be able to nail the fault.

    I should also mention that all of our infrastructure is located in a DataCentre, so I am always a remote user to OCS. I only ever connect to my gear over the internet.

     

    Cheers...

    Wednesday, September 17, 2008 11:24 PM
  • Understood - I thought from your first message that the problem was only with one federated partner.  Your configuration is exactly like mine in that everything is at a data center and you are always a remote user.  That in itself shouldn't be a problem - our federation with partners, including Microsoft, works perfectly with audio and video.

     

    Based on your description it sounds like either the ports aren't open or your A/V Edge doesn't have a public, non-NAT'ed IP address.  If you add me as a contact (address is in my profile) we can give it a shot and I'll gather a trace from my side to see what the issue is.

    Thursday, September 18, 2008 2:56 PM
    Moderator
  • Thanks Mike - I think I'll take you up on your offer, A trace from your side would be great, I've just added you to my Buddy list on OCS, so feel free to contact me when you have time.

    Thursday, September 18, 2008 10:43 PM
  •  

    Thanks Mike, with your help we were able to identify exactly what the problem was and resolve it.

     

    After we examined the OCS logs you sent with the snooper tool - I was able to see what a clean SIP Invite should look like. Essentially, your invites had about 8 "a=candiate" records with both TCP and UPD options. These are used to provide the invited party with a sequence of IP Addresses with which to try and open the RTP Voice stream, after its been negiatiated.

     

    What we found from our SIP Invites is that we were only offering about 4 "a=candiate" records, and they were all exclusively TCP. No UDP options were listed in our Invites. I now had to try and figure out how I could get more addresses into the SIP invites. So far as I'm aware - there is no way to manually provide these addresses to your OCS Servers, so that they provide a static list. And whats more, you wouldn't want to! Because it seems the multiple "a=candiate" records in the SIP Invite are created dynaiically based upon the clients connection topology to their front-end server. And being that you could connect in a number of differnt ways, via differnet network etc - it would be unrealistic to provide a manual list.

     

    So what did I do to resolve it? Well being that the problem seem to be in the SIP Invite I looked at the Edge Servers configuration. We actually have our edge configured in a consolidated mode with 1 physical interface per service, so we have a total of 4 interfaces.  All of our external Interfaces are fully routable public IP Addresses on the same subnet, but firewalled obviously to block non-required traffic. After going over the configuration again, I noticed that the Access Edge Interface had the default gateway set as oppoed to the A/V Edge Interfce, After chaning this on the fly, I tested and we were able to connect with our federated partners. Back in business!! And when I interogated our SIP Invites after this i noticed that we were now advertising 10 "a=candidate" records in both TCP and UDP.

     

    What really interesting is that after checking out all of our federated partners invites most are only offering UDP! and our issue was that we were only offering TCP. Now that we are offering both, we can talk to everyone. This was demonstrated by Mike as he was able to call me late last week, even when we were mis configured and having problems with everyone else.

     

    Cheers...

    Courtenay

    Sunday, September 21, 2008 11:27 PM
  • Thanks for posting the follow-up. The way I usually configure Edge servers is to assign private IPs to the internal interface, Access Edge and Web Conferencing Edge while assigning the requisite public IP to the A/V Edge.  Only the interface assigned to the A/V Edge has a default gateway and all the routes to DMZ/internal subnets are provided via persistent routes (route add -p).  This is also good if you don't have an abundance of public IP addresses.

     

    In any case, I doubt you'll be the last person to hit this so your detailed investigation and resolution are very much appreciated.

    Monday, September 22, 2008 1:51 AM
    Moderator