locked
call forwarding problem RRS feed

  • Question

  • Hi!

    A customer of mine is having the following problem.

    His user is configured for Enterprise Voice and In- and Outgoing calls to his user work fine. But when he configures call forwarding, instead of forwarding the call, it is just droped or he gets a busy signal. This only seems to happen when trying to forward to a telefone outside of OCS (mobil, home phone, etc.)

    As far as I can see there's nothing on the server side, which I could configure to change this, but it should work.

    Any ideas?

    Cheers,

    Gerrit
    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    Thursday, March 4, 2010 2:30 PM

Answers

  • As far as I know this problem is solved now. Forwarded calls use original caller id as calling party number ("FROM" header); this should not be presented to the ISDN network as an E.164 coded number. It is now replaced by a valid default calling party number.


    Johann Deutinger | MCTS Exchange 2007 / OCS 2007


    Hi Hans,

     Thanks for posting. I had almost forgot to post the solution here.

     Cheers,


    Gerrit


    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    • Marked as answer by Gerrit Deike Tuesday, March 23, 2010 2:05 PM
    Tuesday, March 23, 2010 2:05 PM

All replies

  • Can he call the number he is forwarding to from the communicator? If not does his Telephone Policy allow him to dial the number or is the number being normalized correctly.
    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Saturday, March 6, 2010 12:46 PM
  • Yes, he can call out normally. He can also be called from the outside normally. It's just the forwarding thats giving us problems.

    Some thing I should note: I haven't configured respones groups or any such thing, as they aren't needed by the customer.
    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    Sunday, March 7, 2010 12:55 PM
  • I would run debug tracing on the Front End server initially and see what shows up when the call come in. If that doesn't give enough information then you can also run on the mediation server.

    Usually if you get busy or no connection it is normalization, routing or policy related.
    Chris Clark - | MCTS:OCS | MCSE | MCSA | CCNA
    Sunday, March 7, 2010 1:26 PM
  • Hi Gerrit,
    One of my customer have the same problem, when a customer outside OCS call a MOC and he try to forward the call outside, the call fail.
    After a investigation, we have found that the problem was the Carrier that drop the call.
    I'll hope this is usefull.


    Ricardo Ernst ricardoernst.wordpress.com unifiednow@gmail.com
    Wednesday, March 10, 2010 1:32 PM
  • Gerrit,

    From the Mediation server out to the voice gateway, what devices are involved? I have seen the exact problem with an AudioCodes GW (firmware and configuration required). From the mediation server, where are you going?
    Brian Ricks, MCSE, MVP BriComp Computers, LLC http://blogs.bricomp.com/blogs/uc/default.aspx
    Thursday, March 11, 2010 12:09 AM
  • Hi Ricardo,

    thanks for the info. We've opend a call with MS and it does seem to be something inside of OCS. I'll keep you posted on what it was.
    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    Thursday, March 11, 2010 8:50 PM
  • Hi Brian,

    we're using the Ferrari UC Hybrid-Gateway.

    We've opened a call with MS and have TWO MS Support people working on this. I'm looking forward to hearing what the reason for the problem was...
    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    Thursday, March 11, 2010 8:52 PM
  • Interesting - we had something similiar which was a carrier issue - we had two telcos in the UK - one BT one CW. We diverted our BT inbound line number to a DDI in our CW isdn circuit but calls did not process well and we could not hear audio on the call and the isdn signalling caused our Dialogic gateways to lock up eventually with 100% processor utilization! However the ddi on CW worked fine on its own but only had an issue when an external dialled the BT exchange diverted number and that was received. Turned out that calls received by CW from BT were not being handled in the same way. Odd one
    Monday, March 22, 2010 11:32 PM
  • As far as I know this problem is solved now. Forwarded calls use original caller id as calling party number ("FROM" header); this should not be presented to the ISDN network as an E.164 coded number. It is now replaced by a valid default calling party number.


    Johann Deutinger | MCTS Exchange 2007 / OCS 2007
    Tuesday, March 23, 2010 11:40 AM
  • As far as I know this problem is solved now. Forwarded calls use original caller id as calling party number ("FROM" header); this should not be presented to the ISDN network as an E.164 coded number. It is now replaced by a valid default calling party number.


    Johann Deutinger | MCTS Exchange 2007 / OCS 2007


    Hi Hans,

     Thanks for posting. I had almost forgot to post the solution here.

     Cheers,


    Gerrit


    If you think your to small to make a differnce, try going to bed with a mosquito in the room...
    • Marked as answer by Gerrit Deike Tuesday, March 23, 2010 2:05 PM
    Tuesday, March 23, 2010 2:05 PM
  • Hello Johann,

    can you tell me how to configure the use of this default calling party number for the forwarded leg to PSTN ?
    I use a LyncServer 2010 Build 4.0.7577.0

    Thanks a lot.

    Thursday, February 10, 2011 2:09 PM
  • This was solved by a translation rule in the gateway (OfficeMaster Gate). In lync you cannot change calling party numbers for forwarded calls.
    Johann Deutinger | MCTS Exchange 2007/2010 / OCS 2007 | ucblog.deutinger.de
    Thursday, February 10, 2011 2:22 PM
  • Hello Johann,

    so with "mediation server" of lync 2010, which is connected to a SIP Trunk, there is no way ?

    Sad,
    because for the Outgoing calls the CLIR-feature in control panel allows a "Alternate caller ID" (switch "suppress caller ID" in Route rule).
    I was hoping that also for forwarded calls it would have a similar possibility.

    Thanks.

    Thursday, February 10, 2011 4:09 PM