Call-forward with corlist under call-manager-fallback issue

[ichehouri]

I have centralized call processing and remote sites with SRST gateways. the call-manager-fallback is as follows:

call-manager-fallback

secondary-dialtone 0

max-conferences 8 gain -6

transfer-system full-consult

ip source-address 192.168.105.1 port 2000

max-ephones 100

max-dn 150 dual-line

keepalive 10

voicemail 601012504

call-forward busy 601012504

call-forward noan 601012504 timeout 20

mwi relay

moh moh1.wav

multicast moh 239.1.1.1 port 16384 route 192.168.105.1

cor incoming Internal-CSS default

cor incoming Local-CSS 1 601012002

cor incoming National-CSS 2 601012001

cor incoming Mobile-CSS 3 601012000

if i make CFAll on the phone having Mobile access (601012000) to a mobile number then in SRST mode the phone having National access 601012001 (no mobile) gets fast busy tone when he call the forwarded extension. So it look like it is based on the level of access he have and not based on the destination. Note that iam using corlist under my dial-peers.

how can i overcome this issue.

regards,

Ibrahim Chehouri

[ashok_boin]

Hi Ibrahim,

You have not provided complete configuration but the CoR lists behavior depends upon the combinations of incoming and outgoing cor lists for a call.

Pls find a table giving the details about CoR lists behavior in a table from this URL.

http://www.cisco.com/en/US/docs/voice_ip_comm/cusrst/admin/srst/configuration/guide/srs_call.html#wp1010389

Regards...

-Ashok.

[ichehouri]

Hi Ashok,

please find below the configuration i have:

dial-peer cor custom

name VM

name Local

name National

name International

name Mobile

!

!

dial-peer cor list Local-PT

member Local

!

dial-peer cor list VM-PT

member VM

!

dial-peer cor list National-PT

member National

!

dial-peer cor list International-PT

member International

!

dial-peer cor list Local-CSS

member VM

member Local

!

dial-peer cor list National-CSS

member VM

member Local

member National

!

dial-peer cor list International-CSS

member VM

member Local

member National

member International

!

dial-peer cor list Internal-CSS

member VM

!

dial-peer cor list Mobile-PT

member Mobile

!

dial-peer cor list Mobile-CSS

member VM

member Local

member National

member Mobile

!

!

dial-peer voice 102 pots

corlist outgoing Local-PT

destination-pattern 0.......

port 0/1/0

forward-digits 7

!

dial-peer voice 103 pots

corlist outgoing National-PT

destination-pattern 00[^05].......

port 0/1/0

forward-digits 9

!

dial-peer voice 104 pots

corlist outgoing Mobile-PT

destination-pattern 005........

port 0/1/0

forward-digits 10

!

dial-peer voice 105 pots

corlist outgoing International-PT

destination-pattern 000T

forward-digits 0

prefix 00

!

dial-peer voice 106 pots

destination-pattern 0800.......

port 0/1/0

forward-digits 10

!

dial-peer voice 107 pots

destination-pattern 09200.....

port 0/1/0

forward-digits 9

!

dial-peer voice 108 pots

destination-pattern 09[^2].

port 0/1/0

forward-digits 3

!

!

dial-peer voice 110 voip

description Voicemail in SRST mode

destination-pattern 601022504

session protocol sipv2

session target ipv4:192.168.113.10

dtmf-relay sip-notify

codec g711ulaw

no vad

!

dial-peer voice 111 voip

description Autoattendant in SRST mode

destination-pattern 601022505

session protocol sipv2

session target ipv4:192.168.113.10

dtmf-relay sip-notify

codec g711ulaw

!

dial-peer voice 113 voip

preference 1

destination-pattern 601022...

session target ipv4:192.168.10.10

dtmf-relay h245-alphanumeric

no vad

!

dial-peer voice 112 voip

destination-pattern 601022...

session target ipv4:192.168.20.10

dtmf-relay h245-alphanumeric

no vad

!

!

num-exp 2... 601022...

sip-ua

mwi-server ipv4:192.168.113.10 expires 3600 port 5060 transport udp unsolicited

!

!

!

gatekeeper

shutdown

!

!

call-manager-fallback

secondary-dialtone 1

max-conferences 8 gain -6

transfer-system full-consult

ip source-address 192.168.113.1 port 2000

max-ephones 100

max-dn 150 dual-line

keepalive 10

voicemail 601022504

call-forward busy 601022504

call-forward noan 601022504 timeout 20

mwi relay

moh moh1.wav

multicast moh 239.1.1.1 port 16384 route 192.168.113.1

cor incoming Internal-CSS default

cor incoming Local-CSS 1 601022002

cor incoming National-CSS 2 601022001

cor incoming Mobile-CSS 3 601022000

!

!

Please let me know if iam missing something

regards,

Ibrahim

[ashok_boin]

Hi Ibrahim,

It's working as expected from this configuration. It's matching to 4th rule in the COR table URL provided to you in my earlier reply.

In simpler terms...

The phone Incoming CoR list for 601022001 is National-CSS.

dial-peer cor list National-CSS

member VM

member Local

member National

The outgoing dial peer CoR list is "Mobile-PT".

dial-peer cor list Mobile-PT

member Mobile

If you compare both, incoming CoR list is not either subset or superset of outgoing CoR list for the call to mobile phone by 601022001 so the Call will NOT succeed. You need to add "member mobile" for National-CSS if you want to enable mobile calling for 601022001 but not sure any business restrictions for you to do this. If you want to enable mobile calling for everybody but impose other calling restrictions, then you can achieve this by removing Mobile-PT from the outgoing dial peer.

Hope it helps...

Regards...

-Ashok.

[ichehouri]

Hi Ashok,

i know that Mobile is not member of the National-CSS and i know why it is not allowing the user to reach the remote (mobile). But i looking about the way it should work. I mean since a user forwarded (CFALL) to mobile, everyone should be able to reach him even if they do not have mobile access. If the phones are registered to CUCM 7.1.3 i do not have this issue since it is not based on the one who is calling but based on the destination (called number) and the system will forward the call to the mobile even if i do not have access.

how can i overcome this. knowing that i have business need that not everybody have mobile access.

regards,

Ibrahim

[Steven Holl]

I find it way more confusing to think about COR lists as CSS and partitions.  I know that's suggested somewhere, but it isn't really how COR lists work.  You need to think about 'Is the inbound COR a subset of memeber compared to the outbound COR?'  If so, the call fails.  Every other scenario, the call succeeds.

COR simply boils down to this:

* You have an inbound COR list, with specific members, on the inbound dial-peer match.

* You have an outbound COR list, with specific members, on the outbound peer.

One of the criteria will match:

That should help get you on the right track.

[ichehouri]

Hi,

i understand that Steven. My issue is that we are replacing an existing system (Nortel) with new system (Cisco) and the customer needs to maintain the same setup. they have users with different prevelages and at the same time if someone forwards his phone to a remote destination (mobile) then everybody can reach him even if they do not have access to this destination (just having local access). the point out of this is logical since i should not have confusion between what i have access to call and what the phone iam calling is forwarding to.

Is what iam looking for duable in case of SRST? In case of CUCM i know it is duable and i tested it.

regards,

Ibrahim

[Steven Holl]

The way IOS works, you will always match an outbound dial-peer when extending the call to that mobile number.

The call originally will match these peers:

Scenario A - Call from PSTN to a forwarded DN:

Inbound POTS peer is matched.

Outbound peer is the ephone DN.

After forwarding, the outbound leg is torn down, and a new outbound leg out the POTS leg is built.

Hence the COR decision is based on the inbound POTS and outbound POTS peers.

Scenario B - Call from internal DN to a forwarded DN:

Inbound CME virtual peer is matched (20XXX).

Outbound peer is the ephone DN.

After forwarding, the outbound leg is torn down, and a new outbound leg out the POTS leg is built.

Hence the COR decision is based on the inbound CME and outbound POTS peers.

For scenario A, you can control this simply by having the inbound POTS peer's incoming COR to have the member for dialing mobile numbers.  That way, hairpinning is allowed, and the calls will work.

For scenario B, there is no way to get this to work without giving the DN the original right to call a mobile phone directly.

Really, this is by design, anyway.  If you let calls forward to mobile  numbers off of DNs, but not dial directly, the system could be abused. A  user could set any phone to whatever mobile number they want to call,  and then bounce the call off that IP phone to the external mobile number.  That's essentially internal toll fraud.

We can't configure a COR list specific for forwarding (it would actually require rehauling the way the call control API works).  I can't think of any way to satisfy your requirement and allow for scenario B to work while having the IP phone not be able to call the mobile number.  The only way would be to have the users entering the number for CFA to have a special prefix, which is only known to those users.  Then you have a special dial-peer for that prefix, and assign COR appripriately.  The caveat with this is that if your 'untrusted' users learn what this code is (like if they talk to someone that knows the code for entering the number in CFA), they will still be able to dial the mobile numbers directly.

[ichehouri]

thanks steven for the detailed explanation. just to clarify something, if a PSTN caller dials a forwarded DN (Scenario A) then all i need to do is to add an incoming corlist to the same POTS dial peer as the following:

dial-peer voice 104 pots

corlist outgoing Mobile-PT

corlist incoming Mobile-PT

destination-pattern 005........

port 0/1/0

forward-digits 10

am i correct or it should be done with another dial peer and how?

regards,

Ibrahim

[Steven Holl]

Yes, that will work.  Since the call will match that peer in and out for a hairpinned scenario, and you have the same COR list on both, the call will succedd.  Then if you apply another COR (let's say with no members in it) in the incoming direction on the DN, the IP phone won't be ableto call the mobile number, but calls from the PSTN will be able to forward back out to that mobile number.

-Steve

[ashok_boin]

Hi Steve,

Thanks for sharing the tip. But I doubt this will work for all the cases as this particular dial peer would match for calls from only mobile phones starting with 005... , not other PSTN phones. The configuration is having other dial peers matching other PSTN numbers with same port. Please correct me if I am wrong.

Let's wait for test results from Ibrahim as well

Regards...

-Ashok.

[Steven Holl]

Ashok, I'm not sure what you are getting at here.

It all hinges on which dial-peer is matched inbound, which for FXO is going to be controlled with what port it comes in on (so 102-108 are all valid inbound matches).  They should all have an inbound COR of mobile, and then the outbound match should match a peer with outgoing COR mobile.

I don't know this country's dialplan, so I don't know what the actual pattern of the mobile numbers looks like.  You would need mobile numbers to be a different pattern to do any granualr class of restriction on mobile numbers, though.  But apply the concepts as they pertain to the dialplan.  Again it all boils down to inbound and outbound peer matches, what CORs are applied, and if the incoming is a subset of the outgoing or not.

[ashok_boin]

Hi Steven,

Ok, I guess little misunderstanding here.

This is what I tried to mention out that there is a need to apply on all POTS dial peers (102-108). If it's just on Dial peer 104 which is having destination pattern to reach mobiles, then this solution works only for mobile callers from PSTN.

Thanks for your help.

Regards..

-Ashok.

[ashok_boin]

Hi Ibrahim,

Ok. I understood that you have been trying to achieve the equivalent feature CFwdAll and the respective CSS in CUCM configuration. I think it's nearly impossible to achieve this with SRST configuration as it will give us only global Call forward busy or no-answer destinations under "call-manager-fallback" for all IP Phones.

Moreover, I have not seen any option to configure "CFwdAll" under "Call-manager-fallback" directly. The options available are busy or noan.

Regards...

-Ashok.