Dismiss Notice
We would like to remind you that we’re updating our login process for all 3CX forums whereby you will be able to login with the same credentials you use for the Partner or Customer Portal. Click here to read more.

Transfering calls from remote extension to remote extension

Discussion in '3CX Phone System - General' started by netelligence, Jan 17, 2013.

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

    Joined:
    Sep 24, 2012
    Messages:
    31
    Likes Received:
    0
    Greetings,

    I am testing a cloud based 3cx server setup. I have 2 grandstream phones. Each phone can place an out bound call. Each phone can receive an outside call. Each phone can call each other. I am using the SIP Proxy Manager. I have searched thru this forum to overcome a great deal of small aggravating issues and have done alot of tweaking and searching thru this forum just to get this far.

    Now my new problem for which I cannot find an answer.

    If phone 1 receives and outside call and I answer it there is audio both ways just like a normal call should be. However, when I transfer the call to phone 2, phone 2 rings and I answer it, but there is no audio on either end. The call does not end, there is just no audio. When I hang up phone 2, then the call ends. I assume this has to do with RTP ports, but I don't understand where the problem is? I would think the SPM should be able to handle this.

    On a more general level, I am doing all of this thru the SIP Proxy Manager. Would it be better if I just used STUN and/or went thru the hassle of configuring the firewall to do port forwarding to each phone? I was experimenting with the SPM to see what it would do in hopes that it would simplify firewall changes/issues -- so I would appreciate any opinions on that from those that have successfully setup a remote server and a number of remote extensions.

    Thanks,
    Loren.
     
  2. 3CXfoxhallsolutions

    3CXfoxhallsolutions New Member

    Joined:
    Sep 8, 2012
    Messages:
    211
    Likes Received:
    0
    Re: Transfering calls from remote extension to remote extens

    First - I'm assuming you have seen and followed the suggestions in this ...
    http://www.3cx.com/blog/voip-howto/remote-extensions/

    Without a lot more detail, it's difficult to give a better answer, but you might try this ...

    From the fact that you transfer the call and answer it on the other extension, it appears that both extensions are behind the same router. Therefore, you can make it easier for 3CX and the router to get traffic to and from each individual phone by having different 'local SIP prorts' on each phone. By default, a phone will typically set up with port 5060 as the local SIP port for it's primary extension (phones with more than one extension e.g. Cisco SPA504G - will have 5060, 5061,5062,5063 as local SIP ports for their 4 extensions).

    When I have had problems with remote phones, I've often 'cured' it by setting phone 1, extension 1 to 5060, phone 2 extension 1 to 5061, phone 3 extension 1 to 5062 etc. i.e. the router's firewall is not having to service multiple requests regarding the same port numbers. I'm not familiar with Grandstream phones (we deploy Cisco & Yealink), but you should be able to find this parameter against the extension config for each phone.

    Let me know & best of luck ...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. jj12

    Joined:
    Dec 19, 2012
    Messages:
    2
    Likes Received:
    0
    Re: Transfering calls from remote extension to remote extens

    HAve you attempted to go the 3cx web portal --->extension status--->other---> and check pbx delivers audio? That may help thoguh positing a 3cx log can provide more infrmation on the issue. Check your server activity log after attempting that ext to ext call what do you see?. also attempt to set them up as exsternal extension and find out if there is any change in behavior of those calls as opposed to using SPM.
     
Thread Status:
Not open for further replies.