locked
OCS R2 Internal users cannot make a call to federated partners RRS feed

  • Question

  • Hello!

     

    We have an issue in Office Communication Server R2, which cannot resolve:

     

    So, when the internal user from inside the organization try to call to federated partner he received error message: Call was disconnected. But when the user make the same call from outside the network(Internet) it goes perfect

     

    We compare the logs of two calls and found the difference:

    a good one:

    Content-Type: application/sdp

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional; ms-proxy-2007fallback

    v=0

    o=- 0 0 IN IP4 195.245.253.140

    s=session

    c=IN IP4 195.245.253.140

    b=CT:7180

    t=0 0

    m=audio 56810 RTP/AVP 8 0 97 13 118 101

    k=base64:9I7JSiprE0wdhImfF1VN6t6KAAiZgoJuOH0LPeBd3cGQXMLpaJJ2yiBhZikr

    a=candidate:GxYCMUUlDs+YNCt6TeqfSTWz/iwwPchdYjJrKCLjAz0 1 WDOJyPQHinOKMYjOytmiqQ UDP 0.860 94.179.195.16 18220

    a=candidate:GxYCMUUlDs+YNCt6TeqfSTWz/iwwPchdYjJrKCLjAz0 2 WDOJyPQHinOKMYjOytmiqQ UDP 0.860 94.179.195.16 19445

    a=candidate:lPKFMIGTGiHdM3wPTtgPGeam9XB5im4fcV4z8JEwSz4 1 PBGOevhsF2dM7ynnvwUMow UDP 0.490 195.245.253.140 56810

    a=candidate:lPKFMIGTGiHdM3wPTtgPGeam9XB5im4fcV4z8JEwSz4 2 PBGOevhsF2dM7ynnvwUMow UDP 0.490 195.245.253.140 58954

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:asWDLaXLQH5t3JUQB5APoabQ672BvY1W77E4zI1l|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:OcwRs8shVmPJ3xMnp0CxVB3H9T2GZw0uhTAo2AXd|2^31|1:1

    a=maxptime:200

    a=rtcp:58954

    a=tty

    a=rtpmap:8 PCMA/8000

    a=rtpmap:0 PCMU/8000

    a=rtpmap:97 RED/8000

    a=rtpmap:13 CN/8000

    a=rtpmap:118 CN/16000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=encryption:required

    ------=_NextPart_000_004B_01CA1547.34A5E8B0

    Content-Type: application/sdp

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional

    v=0

    o=- 0 0 IN IP4 195.245.253.140

    s=session

    c=IN IP4 195.245.253.140

    b=CT:7180

    t=0 0

    m=audio 59660 RTP/AVP 8 0 97 13 118 101

    k=base64:9I7JSiprE0wdhImfF1VN6t6KAAiZgoJuOH0LPeBd3cGQXMLpaJJ2yiBhZikr

    a=ice-ufrag:QIVv

    a=ice-pwd:AnKYM5pPJ305IVjorD4QB4qq

    a=candidate:1 1 UDP 2130706431 94.179.195.16 23643 typ host

    a=candidate:1 2 UDP 2130705918 94.179.195.16 27991 typ host

    a=candidate:2 1 UDP 16648703 195.245.253.140 59660 typ relay raddr 195.245.253.140 rport 59660

    a=candidate:2 2 UDP 16648702 195.245.253.140 53937 typ relay raddr 195.245.253.140 rport 53937

    a=candidate:3 1 TCP-ACT 1684798719 94.179.195.16 23643 typ srflx raddr 94.179.195.16 rport 23643

    a=candidate:3 2 TCP-ACT 1684798206 94.179.195.16 23643 typ srflx raddr 94.179.195.16 rport 23643

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:asWDLaXLQH5t3JUQB5APoabQ672BvY1W77E4zI1l|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:OcwRs8shVmPJ3xMnp0CxVB3H9T2GZw0uhTAo2AXd|2^31|1:1

    a=maxptime:200

    a=rtcp:53937

    a=tty

     

     and a bad one:


    Content-Type: application/sdp

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional; ms-proxy-2007fallback

    v=0

    o=- 0 0 IN IP4 10.1.9.70

    s=session

    c=IN IP4 10.1.9.70

    b=CT:99980

    t=0 0

    m=audio 13256 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

    k=base64:STjcYQ7aAiBm8MqrRPBkmDg2Alv7/U3HyX28rWz41V4TmUEsg+v5KUi7e4pp

    a=candidate:tyNIU7cvK8Iq2AtZqN2YF6JrbWR9XjD5aEfEpcIScT0 1 IQ9YAtnyIqeTb1w0s+sG3w UDP 0.830 10.1.9.70 13256

    a=candidate:tyNIU7cvK8Iq2AtZqN2YF6JrbWR9XjD5aEfEpcIScT0 2 IQ9YAtnyIqeTb1w0s+sG3w UDP 0.830 10.1.9.70 4862

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:QMOaSLXFNUYhoF57psHki07pF9XqXCYzqVKR0n5p|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:MaE/5TThKjqW3gyNdLe5cp3+PzrK8EGZyAcTn+Hi|2^31|1:1

    a=maxptime:200

    a=rtcp:4862

    a=rtpmap:114 x-msrta/16000

    a=fmtp:114 bitrate=29000

    a=rtpmap:111 SIREN/16000

    a=fmtp:111 bitrate=16000

    a=rtpmap:112 G7221/16000

    a=fmtp:112 bitrate=24000

    a=rtpmap:115 x-msrta/8000

    a=fmtp:115 bitrate=11800

    a=rtpmap:116 AAL2-G726-32/8000

    a=rtpmap:4 G723/8000

    a=rtpmap:8 PCMA/8000

    a=rtpmap:0 PCMU/8000

    a=rtpmap:97 RED/8000

    a=rtpmap:13 CN/8000

    a=rtpmap:118 CN/16000

    a=rtpmap:101 telephone-event/8000

    a=fmtp:101 0-16

    a=encryption:required

    ------=_NextPart_000_003F_01CA1549.F673F1B0

    Content-Type: application/sdp

    Content-Transfer-Encoding: 7bit

    Content-Disposition: session; handling=optional

    v=0

    o=- 0 0 IN IP4 10.1.9.70

    s=session

    c=IN IP4 10.1.9.70

    b=CT:99980

    t=0 0

    m=audio 19311 RTP/AVP 114 111 112 115 116 4 8 0 97 13 118 101

    k=base64:STjcYQ7aAiBm8MqrRPBkmDg2Alv7/U3HyX28rWz41V4TmUEsg+v5KUi7e4pp

    a=ice-ufrag:KPuP

    a=ice-pwd:T4fYVCkSEcMyPkdCXZIUGh7I

    a=candidate:1 1 UDP 2130706431 10.1.9.70 19311 typ host

    a=candidate:1 2 UDP 2130705918 10.1.9.70 3590 typ host

    a=candidate:3 1 TCP-ACT 1684798719 10.1.9.70 19311 typ srflx raddr 10.1.9.70 rport 19311

    a=candidate:3 2 TCP-ACT 1684798206 10.1.9.70 19311 typ srflx raddr 10.1.9.70 rport 19311

    a=cryptoscale:1 client AES_CM_128_HMAC_SHA1_80 inline:QMOaSLXFNUYhoF57psHki07pF9XqXCYzqVKR0n5p|2^31|1:1

    a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:MaE/5TThKjqW3gyNdLe5cp3+PzrK8EGZyAcTn+Hi|2^31|1:1

    a=maxptime:200


    The difference is that in first situation the server gives a=candidates of the Edge Server and in the second case there no a=candidates of Edge Server
    IP address 10.1.9.70 is local ip of client endpoint

    We tried to debug with WireShark (on client) and saw the next situation

    The client is trying to connect directly to external Microsoft  address  (addresses sent in a=candidates) and saw the checksum error



    On our consolidated edge
    We have 3 reale external, routable IP addresses on separate NIC's
    And One internal address with a static route  

     

     

    I will really appreciate your help!

    Wednesday, August 5, 2009 5:08 PM

Answers

  • I worked with Denis offline.  The appropriate candidates were not being advertised because of a firewall issue between the internal network and the Edge server.  Once he corrected this everything started working.
    Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
    Thursday, August 13, 2009 4:02 AM
    Moderator

All replies

  • Have you configured

    A/V Conference Edge Server Settings 
    - Internal FQDN: server.domain.com
    - A/V authentication port: 5062 

    If you click on your pool in MMC then you will find the information in Meeting Settings
     


    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Thursday, August 6, 2009 8:52 AM
  • Hello!

    Yes i have configured it correctly and it looks on edge FQDN  by port 5062

     
    Thursday, August 6, 2009 10:37 AM
  • Did you run the any of the validation wizards in OCS?
    (Front-End validation wizard)
    - Belgian Unified Communications Community : http://www.pro-exchange.be -
    Thursday, August 6, 2009 1:31 PM
  • Is the company you are federated with using R1? Port requirements are different if you are connecting to an R1 Federated system.
    Mitch Roberson |MCITP:Enterprise Server Admin, Messaging |MCTS:OCS with Voice Achievement |MCT
    Thursday, August 6, 2009 4:44 PM
  • hi
    Any update?

    Regards!
    Wednesday, August 12, 2009 3:55 AM
    Moderator
  • Hi:

    Per your description, you have some issue with the internal user make calls with federated partner user.

    Firstly you can do below procedures to make a troubleshooting.

    1.     Verify that the access edge service is running and connected.

    2.     Verify the configuration of the A/v edge service on the General tab of the pool-level A/V conferencing server properties dialog box. Including the configuration of the FQDN, IP address, SIP listening port, and media port range.

    3.     Make sure have made correct DNS record for A/V edge server, make sure the port of the internal interface of the A/V edge server for the service is opened.

    4.     Make sure the certificates are configured properly.

    5.     Make sure the connection between the A/V edge server and the FE server is good (you can get some tracing to test).

    Make sure A/V edge server should have routing network to internal OCS server, connected the internal NIC of A/V edge to LAN to have a direct connectivity with OCS server. No NATED.

    6.     According to the logs you referred. It seems that the external candidate shows the internal IP, and Edge Server never show as a candidate. So, you can make a test to resolve the edge FQDN from the internal users.

     

    You can learn more information about the troubleshooting refer to below links:

    http://technet.microsoft.com/en-us/library/dd572573(office.13).aspx
    Wednesday, August 12, 2009 11:41 AM
    Moderator
  • I worked with Denis offline.  The appropriate candidates were not being advertised because of a firewall issue between the internal network and the Edge server.  Once he corrected this everything started working.
    Mike Stacy | Evangelyze Communications | http://www.evangelyze.net/cs/blogs/mike
    Thursday, August 13, 2009 4:02 AM
    Moderator