cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
437
Views
0
Helpful
1
Replies

Meeting Place dial out

gb-fairchild
Level 1
Level 1

I'm not sure exactly how to ask this question but here is what I have.

I have CUCM 7.1.3 and Meetinmg Place 8.x.  The connection between CUCM and MP is a SIP trunk.  When a user logs in via the web to start a meeting they are given an option to have Meeting Place call them.  The issue I have is that users from outside our company do not realize they need to tell Meeting Place to dial 9 for an outside number.  I have both internal and external users so internal users can tell it to call their internal 6 digit extension.  The dialing strings overlap.  So for example someone could ask MP to call them at 355667 but an outside user could put in 355-667x-xxxx or 355-667x.  So is there a way around this?  The one distinguishing characteristic is that if the user enters 6 digits it is an internal call and if they enter 7 or more it's external.  If I have a partition with internal extensions and two route patterns ([2-9]XXXXXX and [2-9]XXXXXXXXX and dial a number that matches an internal extension it sends the call after the 6th digit - just testing with a SCCP phone.  I don't know if the SIP trunk processes the digits the same way as the phone.

Another way around this would be to modify the dialogue box presented to the user by Meeting Place to tell outside callers to prefix their number with a 9 but I have heard you can't do that.

Thanks,

Bill

1 Reply 1

Tim Smith
Level 4
Level 4

Hi,

When you say after the 6th digit, is there a wait for the inter-digit timeout or are you saying it's immediate?

If you have route pattern overlapping with your internal extension - CUCM should wait for interdigit timeout to figure out if you are going to dial any more digits. After that it should figure out your most specific match is the internal extension, and try and send the call there.

Is this happening? do you get a pause before the call gets sent to the extension?

SIP trunk should behave the same, it's not really the trunk or SCCP phone doing the matching in this case, it's the callmanager processes themselves. You can see this in the CCM traces.

Cheers,

Tim