Edge Server but no voice RRS feed

  • Question

  • Hi

    I recently set up an edge server (one server with all three roles) for
    my OCS lab. The goal is to have the public side in our productive LAN
    so that people can connect to it (we currently don't have a productive
    deployment and unless you are in a dedicated showroom / lab lan
    there's no way to connect to OCS from the productive network). 

    Network wise things look as follows: 

    Productive data LAN (notebooks with MOC):, segmented
    into 4 parts (we connect from and
    depending on which access switch we're connecting to)
    "Internet":, the edge server has 3 IPs here, access
    edge, web edge, av edge
    "Internal network" (lab domain): (actually, segmented
    into 4 parts.. 201.64/26 is where the OCS servers are plus some VMs
    with MOC, 201.192/26 is where 3 Tanjays are, plus where we connect
    notebooks with MOC for testing purposes) 

    Within the internal network, we have full communication capabilities
    (even between a client in the server segment and the client segment...
    there are no firewalls in between). There are also no firewalls
    between the 201 and the 206 network and at the moment there are no
    hindrances between the 18 and the 206 network (there's no direct path
    between the 18 and the 201 network though.. it's just a routing thing -

    the route to the 201 network isn't propagated to the productive lan,

    and the router in the 201 network only has a route to the 206 network).

    Also note that there is no NAT anywhere.

    If I connect a client from the "Internet" or productive LAN, I get
    presence and IM, but I cannot establish a voice call (at the point
    where the voice channel should be setup the client remains silent for
    a few seonds, then the call is aborted and the error message is that
    no audio was received). Looking at the MOC logs when I try to make a
    call between a MOC in the internal network and the productive LAN I
    see that both sides try to send media to each other directly. This
    explains why things work if both ends are in the same subnet and why
    things don't work if both clients are in a net that cannot reach the
    net of the other endpoint. 

    Now I would think that when using edge servers, media would pass
    through the a/v edge server, the MOC on the productive LAN should send
    media, whereas the MOC on the internal LAN should send
    media to (the internal address of my edge server) - but
    the INVITE is forwarded (by the edge server) as is, and the same
    applies to the 200 OK response.. so then both clients try to send
    media to an unreachable net which explains why the call gets aborted. 

    Does anybody have an idea why the edge doesn't rewrite the addresses
    in the SDP in order to have media proxied by the a/v edge? 

    Monday, August 4, 2008 2:35 PM

All replies

  • Stephan,


    Based on your description it sounds like your A/V Edge interface has a private 10.x.x.x IP address assigned to it rather than a publicly routable, non-NAT IP address, which is a requirement for the A/V Edge.  As a result, the external client in an audio connection is given that 10.x.x.x IP address when attempting to start an audio connection, which of course will fail.


    See page 102 of the OCS 2007 Planning Guide for more details on this.




    Monday, August 4, 2008 3:16 PM
  • Mike

    You're correct, the a/v edge (along with the access edge and web conferencing edge) have a 10.145.206.x IP address, so non public. I cannot do reverse address translation (plus we'd need to buy another block of public IPs) for this scenario and the whole setup never will reach the public internet.. but since it's a separate and non connected domain we cannot use the regular (internal) mechanism to connect from our productive clients.

    So far I've always heard that the A/V edge should have a public IP but not that it must. Isn't there a way to trick the a/v edge into translating the IP addresses in the SDP packets in order to instruct the remote endpoint to send the audio stream to the a/v edge (as it does when there's a public IP address) instead of sending it directly to the local endpoint (it's the only thing that doesn't work.. as soon as those addresses are changed, it would work.. I know that since I have interop with Cisco CCM which is also in the 10.145.206.x network and and as soon as I gave the mediation server a leg in the 10.145.206.x network clients on my OCS network can talk just fine to clients on the other side of the network.. regardless of which subnets they're in (everything has full access to my "Internet" (10.145.206.x)).

    Basically the "external" client isn't really external.. it has a 10.x IP address as well.. it's just external with respect to the domain where my OCS is. The productive and the lab network are separated in a way that matches a typical Internet setup (there's no communication except what is allowed through the firewall.. and there's no routing in between the networks).

    All I really need is the edge to replace the remote endpoint address with its own address (the internal address when sending the INVITE/ACK to a local client.. and with the "public" address when sending the INVITE/ACK to a remote client).

    Monday, August 4, 2008 4:42 PM
  • The A/V Edge IP must be directly reachable by all clients.  For an explanation of this take a look here.  Your scenario is slightly unique since your external clients aren't really outside your network, so in your case it means that the 10.145.206.x address that you've assigned to your A/V Edge must be directly reachable by all clients (no NAT allowed).


    Monday, August 4, 2008 9:56 PM
  • Mike

    The a/v edge (in this case is directly accessible by all clients, there's no NAT and firewalls in place.

    However, I think the problem comes from the client's use of STUN and it failing in my environment.. I see that the internal endpoint (on the 10.145.201.x network) sending out a lot of STUN messages but not getting a response (I haven't noted the same on the external client though). Now I presume (because this is how regular SIP phones work) that the external endpoint tries STUN and then uses the address found in its INVITE packet. Since STUN yields no response, it uses its own IP address (e.g. for a notebook in the productive network) and sends that as media terminal address to the edge. That is fine though since the edge (all 3 of them) can reach that address just fine.
    The edge now forwards this via OCS but it forwards the same endpoint address (I think it should replace the endpoint address with the address of its internal interface)... which is unreachable because even though the 10.145.18.x network is reachable from the edge, it is not reachable from the internal (10.145.201.x) network.

    Similarly, the internal client not getting a STUN answer will use its own address and send that to the internal address of the edge. So far so good again because that communication, too, is fine. The edge then sends that packet to the outside without changing the endpoint address... and now you're telling the external client to send media to an internal address... and that neither works in my special setup nor in a real world scenario.

    I see that the edge proxies SIP messages.. they are not send directly between endpoints.. isn't the media stream supposed to take the same path and the external client sending the stream to the a/v edge and it forwarding it from the internal edge address to the internal client, and the internal client sending the media stream to the internal edge address and the a/v edge forwarding the data from its external address? Isn't the a/v edge a media proxy when you have an internal and an external participant?

    Is there a diagram that shows the communication setup in an internal <-> external scenario somewhere so that I could verify that my assumptions are correct?

    Even thogh if both clients do stun, and we assume that the external client is behind a NAT, then we have the public IP of the external client sent to the edge, but if the a/v edge is a media proxy, it still has to replace that address when it forwards the INVITE on the internal network (the internal client is supposed to send the media stream to the edge and not directly to the external client, correct?).


    @edit: I found at least a diagram on how internal and external clients communicate. According to the Technical Overview guide page 40 the a/v edge is definitely a media proxy.. now I understand why they say no NAT (in that case the a/v edge would tell the remote client to send traffic not to its public IP but it's private IP and that of course would not work). However, in my case I have no NAT and despite that the a/v edge (or rather the access edge which does the signalling) tells the remote client to send the audio stream not to the a/v edge, but to the private endpoint.. needless to say that this is completely and utterly incorrect since the a/v edge is supposed to receive all media. Likewise, the INVITE that the internal endpoint gets the ip address of the external endpoint as destination for the media stream even though it should send the media to the a/v edge's internal IP address. Once again, this is incorrect and cannot work.

    Having a flow diagram that explains each step the two participants take to communication would still be helpful imho as it might explain why things work out the way they do (and why the access edge forwards packets without swapping out IP addresses of the media endpoints).
    Tuesday, August 5, 2008 1:44 PM