3CX System and Skype Connect service

Discussion in '3CX Phone System - General' started by nakanet, Sep 11, 2012.

Thread Status:
Not open for further replies.
  1. nakanet

    Joined:
    May 1, 2011
    Messages:
    25
    Likes Received:
    0
    Dear friends,

    I´m facing an issue with our 3CX connected to the Skype Connect service.
    First, we´ve bought a communication channel from Skype Connect and get all the login information to be setted-up in our 3CX installation.
    Inside the 3CX Management Console, we´ve created the VOIP provider using the Skype for SIP profile (standard profile provided by 3CX).
    We´ve made the setting up of DID and outbound rules.
    Everything looked fine until we started to test this new line. First, we made an OUTBOUND call and everything works fine, with the call being completed to landlines or mobiles withou problems.
    Then, as our Skype Connect account has an inbound phone number (in our case, a Japan based inbound phone number), we´ve tried to call this dial-in number and see if the call were routed to our 3CX. But this time we had a problem.
    The number called looks to work fine, because the ring tone is heard, but no sign of any ringing in our 3CX extensions.
    For a test, we´ve changed the Skype´s online number (the dial in number) to another account (that is accessible thru a wireless wi-fi Skype Phone) and when we called the assigned number, it works, with the phone ringing.
    Then, we take a look on the 3CX Management Console logs (both the Server Activity Log and the Server Event Log).
    In the Server Event Log, we could saw that the virtual extension related with the connection with Skype Connected is registered and seems do be OK. Also, we take a look at the Skype Manager to see if the account were logged in and in that page, it says that the SIP client is correctly connected.
    After this, we took a look at the Server Activity Log and searched for registry of inbou or outbound calls thru the Skype Connect channel and related to the outbound call (that was OK), we find the registers of the activity as related bellow:

    07:02:38.593 [CM505003]: Provider:[Skype Connect] Device info: Device Not Identified: User Agent not matched; Capabilities:[reinvite, replaces, able-no-sdp, recvonly] UserAgent: [] PBX contact: [sip:990510XXXXXXXX@XX.X.XXX.XXX:47669]
    07:02:38.588 [CM503002]: Call(1): Alerting sip:990510XXXXXXXX@sip.skype.com:5060
    07:02:33.356 [CM503025]: Call(1): Calling VoIPline:+8156755XXXX@(Ln.10026@Skype Connect)@[Dev:sip:990510XXXXXXXX@sip.skype.com:5060]
    07:02:33.110 [CM503004]: Call(1): Route 1: VoIPline:+8156755XXXX@(Ln.10026@Skype Connect)@[Dev:sip:990510XXXXXXXX@sip.skype.com:5060]
    07:02:33.084 [CM503010]: Making route(s) to <sip:056755XXXX@sip.xxxxxxxxxx.com:5060>

    And with this, the call is completed normally.
    But we noticed that there´s no reference that an incomming call reached the 3CX service, as we had when we were using the old 3CX Skype Gateway that received a signaling from the incomming call and the correspondent signaling to the extensions as defined on the inbound dial rules.
    We don´t have any mention about this incomming call trial in the Server Activity Log nor in the Server Event Log.
    So we decided to conduct a firewall test to see if there´s no firewall blockages that can have a role in this issue.
    The firewall test results were reported as below:

    3CX Firewall Checker, v1.0. Copyright (C) 3CX Ltd. All rights reserved.

    <07:14:13>: Phase 1, checking servers connection, please wait...
    <07:14:13>: Stun Checker service is reachable. Phase 1 check passed.
    <07:14:13>: Phase 2a, Check Port Forwarding to UDP SIP port, please wait...
    <07:14:14>: UDP SIP Port is set to 5060. Response received correctly with no translation. Phase 2a check passed.

    <07:14:14>: Phase 2b. Check Port Forwarding to TCP SIP port, please wait...
    <07:14:14>: TCP SIP Port is set to 5060. Response received correctly with no translation. Phase 2b check passed.

    <07:14:14>: Phase 3. Check Port Forwarding to TCP Tunnel port, please wait...
    <07:14:14>: TCP TUNNEL Port is set to 5090. Response received correctly with no translation. Phase 3 check passed.

    <07:14:14>: Phase 4. Check Port Forwarding to RTP external port range, please wait...
    <07:14:23>: UDP RTP Port 9000. Response received correctly with no translation. Phase 4-01 check passed.
    <07:14:23>: UDP RTP Port 9001. Response received correctly with no translation. Phase 4-02 check passed.
    <07:14:23>: UDP RTP Port 9002. Response received correctly with no translation. Phase 4-03 check passed.
    <07:14:23>: UDP RTP Port 9003. Response received correctly with no translation. Phase 4-04 check passed.
    <07:14:23>: UDP RTP Port 9004. Response received correctly with no translation. Phase 4-05 check passed.
    <07:14:23>: UDP RTP Port 9005. Response received correctly with no translation. Phase 4-06 check passed.
    <07:14:23>: UDP RTP Port 9006. Response received correctly with no translation. Phase 4-07 check passed.
    <07:14:23>: UDP RTP Port 9007. Response received correctly with no translation. Phase 4-08 check passed.
    <07:14:23>: UDP RTP Port 9008. Response received correctly with no translation. Phase 4-09 check passed.
    <07:14:23>: UDP RTP Port 9009. Response received correctly with no translation. Phase 4-10 check passed.
    <07:14:23>: UDP RTP Port 9010. Response received correctly with no translation. Phase 4-11 check passed.
    <07:14:23>: UDP RTP Port 9011. Response received correctly with no translation. Phase 4-12 check passed.
    <07:14:23>: UDP RTP Port 9012. Response received correctly with no translation. Phase 4-13 check passed.
    <07:14:23>: UDP RTP Port 9013. Response received correctly with no translation. Phase 4-14 check passed.
    <07:14:23>: UDP RTP Port 9014. Response received correctly with no translation. Phase 4-15 check passed.
    <07:14:23>: UDP RTP Port 9015. Response received correctly with no translation. Phase 4-16 check passed.
    <07:14:23>: UDP RTP Port 9016. Response received correctly with no translation. Phase 4-17 check passed.
    <07:14:23>: UDP RTP Port 9017. Response received correctly with no translation. Phase 4-18 check passed.
    <07:14:23>: UDP RTP Port 9018. Response received correctly with no translation. Phase 4-19 check passed.
    <07:14:24>: UDP RTP Port 9019. Response received correctly with no translation. Phase 4-20 check passed.
    <07:14:24>: UDP RTP Port 9020. Response received correctly with no translation. Phase 4-21 check passed.
    <07:14:24>: UDP RTP Port 9021. Response received correctly with no translation. Phase 4-22 check passed.
    <07:14:24>: UDP RTP Port 9022. Response received correctly with no translation. Phase 4-23 check passed.
    <07:14:24>: UDP RTP Port 9023. Response received correctly with no translation. Phase 4-24 check passed.
    <07:14:24>: UDP RTP Port 9024. Response received correctly with no translation. Phase 4-25 check passed.
    <07:14:24>: UDP RTP Port 9025. Response received correctly with no translation. Phase 4-26 check passed.
    <07:14:24>: UDP RTP Port 9026. Response received correctly with no translation. Phase 4-27 check passed.
    <07:14:24>: UDP RTP Port 9027. Response received correctly with no translation. Phase 4-28 check passed.
    <07:14:24>: UDP RTP Port 9028. Response received correctly with no translation. Phase 4-29 check passed.
    <07:14:24>: UDP RTP Port 9029. Response received correctly with no translation. Phase 4-30 check passed.
    <07:14:24>: UDP RTP Port 9030. Response received correctly with no translation. Phase 4-31 check passed.
    <07:14:24>: UDP RTP Port 9031. Response received correctly with no translation. Phase 4-32 check passed.
    <07:14:24>: UDP RTP Port 9032. Response received correctly with no translation. Phase 4-33 check passed.
    <07:14:24>: UDP RTP Port 9033. Response received correctly with no translation. Phase 4-34 check passed.
    <07:14:24>: UDP RTP Port 9034. Response received correctly with no translation. Phase 4-35 check passed.
    <07:14:24>: UDP RTP Port 9035. Response received correctly with no translation. Phase 4-36 check passed.
    <07:14:24>: UDP RTP Port 9036. Response received correctly with no translation. Phase 4-37 check passed.
    <07:14:24>: UDP RTP Port 9037. Response received correctly with no translation. Phase 4-38 check passed.
    <07:14:24>: UDP RTP Port 9038. Response received correctly with no translation. Phase 4-39 check passed.
    <07:14:24>: UDP RTP Port 9039. Response received correctly with no translation. Phase 4-40 check passed.
    <07:14:24>: UDP RTP Port 9040. Response received correctly with no translation. Phase 4-41 check passed.
    <07:14:24>: UDP RTP Port 9041. Response received correctly with no translation. Phase 4-42 check passed.
    <07:14:25>: UDP RTP Port 9042. Response received correctly with no translation. Phase 4-43 check passed.
    <07:14:25>: UDP RTP Port 9043. Response received correctly with no translation. Phase 4-44 check passed.
    <07:14:25>: UDP RTP Port 9044. Response received correctly with no translation. Phase 4-45 check passed.
    <07:14:25>: UDP RTP Port 9045. Response received correctly with no translation. Phase 4-46 check passed.
    <07:14:25>: UDP RTP Port 9046. Response received correctly with no translation. Phase 4-47 check passed.
    <07:14:25>: UDP RTP Port 9047. Response received correctly with no translation. Phase 4-48 check passed.
    <07:14:25>: UDP RTP Port 9048. Response received correctly with no translation. Phase 4-49 check passed.
    <07:14:25>: UDP RTP Port 9049. Response received correctly with no translation. Phase 4-50 check passed.


    Application exit code is 0

    So, no evident problems with the firewall.
    We looked to the network traffic using different sniffing tools (Colapsa and Wireshark), and we discover just one strange behavior under the SIP protocol.
    The server hosting the 3CX application makes a SIP request to Skype´s server and then, the Skype server answer with an 407 error (Unauthorized) answer. Next the server makes a new SIP request to Skype and in this second attempt, the Skype´s server returns an 200 OK answer.
    And this behavior happens in a ciclical pattern.
    Below, I´m posting an example of this pattern, that repeats many times:

    REGISTER sip:sip.skype.com:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-4817f119b30e1336-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:990510XXXXXXXX@XX.X.XXX.XXX:48005;rinstance=a2f1671a8656445e>;expires=0
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=1854757e
    Call-ID: NWNiNzJjZmU3Y2Q3ZDI3NDk1MzQxMzdlODgyYmEzN2E.
    CSeq: 10 REGISTER
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Supported: replaces
    User-Agent: 3CXPhoneSystem 10.0.23053.0
    Authorization: Digest username="990510XXXXXXXX",realm="sip.skype.com",nonce="504fb93800000f5ae932fe2584762c8b69b1c825cee4fda7",uri="sip:sip.skype.com:5060",response="ebc4e0171f30542bdac2385e27fe75c2",algorithm=MD5
    Content-Length: 0

    SIP/2.0 401 Unauthorized
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=1854757e
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.21b9
    Call-ID: NWNiNzJjZmU3Y2Q3ZDI3NDk1MzQxMzdlODgyYmEzN2E.
    CSeq: 10 REGISTER
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-4817f119b30e1336-1---d8754z-;rport=5060;received=XX.X.XXX.XXX
    WWW-Authenticate: Digest realm="sip.skype.com", nonce="504fba650000162c0e2f27ac4a99486d32962d450aef09f5", stale=true, algorithm=MD5
    Server: OpenSIPS
    Content-Length: 0

    SIP/2.0 401 Unauthorized
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=04607f39
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.0831
    Call-ID: MTkzMDg3MTQ5NjFmYWJlMzVmYTZjNzE4ODczMDMzODk.
    CSeq: 1 REGISTER
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-c9239b7a1d592f1f-1---d8754z-;rport=5060;received=XX.X.XXX.XXX
    WWW-Authenticate: Digest realm="sip.skype.com", nonce="504fba650000162e63a4fb1994f71f72411884d254b0e5bd", algorithm=MD5
    Server: OpenSIPS
    Content-Length: 0

    SIP/2.0 401 Unauthorized
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=1854757e
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=c97b4d1cb1f3d0da549e06a8d482ef63.21b9
    Call-ID: NWNiNzJjZmU3Y2Q3ZDI3NDk1MzQxMzdlODgyYmEzN2E.
    CSeq: 10 REGISTER
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-4817f119b30e1336-1---d8754z-;rport=5060;received=XX.X.XXX.XXX
    WWW-Authenticate: Digest realm="sip.skype.com", nonce="504fba650000162c0e2f27ac4a99486d32962d450aef09f5", stale=true, algorithm=MD5
    Server: OpenSIPS
    Content-Length: 0

    REGISTER sip:sip.skype.com:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-4e0582311f65b21b-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:990510XXXXXXXX@XX.X.XXX.XXX:48005;rinstance=a2f1671a8656445e>;expires=0
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=1854757e
    Call-ID: NWNiNzJjZmU3Y2Q3ZDI3NDk1MzQxMzdlODgyYmEzN2E.
    CSeq: 11 REGISTER
    Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE
    Supported: replaces
    User-Agent: 3CXPhoneSystem 10.0.23053.0
    Authorization: Digest username="990510XXXXXXXX",realm="sip.skype.com",nonce="504fba650000162c0e2f27ac4a99486d32962d450aef09f5",uri="sip:sip.skype.com:5060",response="b19704b316c4ac5288f4a04d0a08caf5",algorithm=MD5
    Content-Length: 0

    REGISTER sip:sip.skype.com:5060 SIP/2.0
    Via: SIP/2.0/UDP 192.168.24.100:5060;branch=z9hG4bK-d8754z-23493d5db9226454-1---d8754z-;rport
    Max-Forwards: 70
    Contact: <sip:990510XXXXXXXX@XX.X.XXX.XXX:48092;rinstance=e34d077b096cd0bf>
    To: <sip:990510XXXXXXXX@sip.skype.com:5060>
    From: <sip:990510XXXXXXXX@sip.skype.com:5060>;tag=04607f39
    Call-ID: MTkzMDg3MTQ5NjFmYWJlMzVmYTZjNzE4ODczMDMzODk.

    Does anybody faced this kind of issue ? How can I work to fix this problem and allow the calls to flow inbound and outbound from our 3CX thru Skype Connect ?
    Any help is welcome !!
    Thanks in advance

    Eduardo Nakagawa
    Main Director
    Nakanetworks Japan Holdings - Telecommunications Division
    3CX Reseler
    Aichi - Tsushima - Japan
     
Thread Status:
Not open for further replies.