locked
1-800 number dialing issue RRS feed

  • Question

  • We've been able to call 1-800 numbers without any problems.  However today I found a 1-800 number that we can't dial from the MOC client, but we can from a standard PBX phone that isn't connected to OCS.  The number is a conferencing bridge dial in # in the USA.  It's 1-800-504-8071 and I get a fast busy after one ring.  Looking in the S4 and mediation logs, it just shows the call connected status 183 and then when I hang up that it's disconnected.  Any ideas?

    Friday, August 7, 2009 4:57 PM

Answers

  • What is the setup of the environment?

    In the S4 and SIP stack logs do you see the call being routed to the PBX via IP GW or IP PBX?

    Where is the call getting dropped ?  Also are the normalization rules/location profiles being applied when you make the call?  How does the # translate in the MOC when you end the number e.g. +1800xxxxxxx?  Usually the 183 event represent the SIP SESSION progress after getting the SIP Invite header, so depending on where you are getting this, it could mean serveral different things.


    HTH
    James

    Saturday, August 8, 2009 3:11 AM

All replies

  • What is the setup of the environment?

    In the S4 and SIP stack logs do you see the call being routed to the PBX via IP GW or IP PBX?

    Where is the call getting dropped ?  Also are the normalization rules/location profiles being applied when you make the call?  How does the # translate in the MOC when you end the number e.g. +1800xxxxxxx?  Usually the 183 event represent the SIP SESSION progress after getting the SIP Invite header, so depending on where you are getting this, it could mean serveral different things.


    HTH
    James

    Saturday, August 8, 2009 3:11 AM
  • Hi Russ,

    Any luck with this problem?  We're seeing the same behavior - most toll-free numbers work fine, but one in particular results in a single ring followed by a fast busy signal.  And a second number results in the following message: "The number you dialed cannot be completed: P-U-A-M-I".

    We're using a SIP Trunk (TCP) to BroadVox.   If anyone has ideas on how to troubleshoot this, or what I should be looking for in the logs, I'd appreciate it!

    Thanks,
    Dave
    Thursday, August 20, 2009 6:21 PM
  • The entire message reads "Your call is NOT allowed, PUAMI".

    You might want to check with Broadvox. Either their upstream provider does not route properly to the destination or the destination does not allow inbound from Broadvox. In any case, this is not a problem in your environment.

    Drago
    • Proposed as answer by dsmithwv Friday, August 21, 2009 1:22 PM
    Thursday, August 20, 2009 9:40 PM
  • I just got off the phone with Broadvox's tech support; We did some interactive testing - apparently OCS is not including an ANI (calling number).  Since we have a static configuration, he said we should be able to simply set the "username" field to our ANI, so I'm going to give that a shot.

    Dave
    Tuesday, August 25, 2009 2:25 PM
  • Will you please post your findings? Negative result is also a valuable information...

    Thanks in advance!

    Drago
    Tuesday, August 25, 2009 2:36 PM
  • Hi Drago,

    I've looked everywhere and it doesn't seem (correct me if I'm wrong here) that the OCS Mediation Server has an option to specify a username - I imagine this could be accomplished using FreeSwitch, but we are connecting direct to Broadvox.

    However, I did find another way to solve the problem:  We hadn't configured LineURIs for our users because they don't have DIDs (OCS won't let you use the same number for more than one contact).  But it turns out that it is possible to specify unique LineURIs in this scenario: Simply append the user's extension number to the company's public phone number, for example "+18005551234;ext=201".

    And the toll-free numbers that had been giving us problems are working fine now!

    Thanks,
    Dave
    Tuesday, August 25, 2009 4:25 PM
  • Ah, I see now. OCS R2 indeed allows user to be enabled for EV without LineURI to be populated, thus "Unknown" will appier as CID. This comes very handy for devices in common areas, where for example we allow our students to make outbound calls to ask for a ride etc. but not to accept innound calls.

    When TEL URI is in format: "+18005551234;ext=201", ";ext=xxx" is stripped and a valid phone number is presented.

    Lastly, you are correct that with FS such manipulation is possible. Fact is, I had to use this method last night to solve 911 issue with one of our campuses, where the 911 originaly were send to the National Emergency Center and then they route to the local center. Now, if 911 call is placed, the caller ID is rewritten to be the BTN (E911 number of the trunk) and all others call made from the campus present the main Auto Attendant of this campus. No change of the call quality were noticed. Another cool feature is... music on hold. Believe it or not, now when OCS user places PSTN call on hold, FS plays MOH.

    Thanks for the info, Buddy!

    Drago
    • Proposed as answer by dsmithwv Thursday, August 27, 2009 3:17 PM
    Wednesday, August 26, 2009 11:34 AM