Local private to public overflow

[Medbck]

Hi all, I've an issue about local private to public overflow feature, let me explain the issue:

I have a centralized call server in one site and several media gateways in other sites secured by PCS.
I already managed all parameters of local private to public overflow, and for internal sets, it's working fine.
But when there is an external incoming call which arrived to the MG secured by the PCS and the DDI number corresponding to this incoming call is on another media gateway, the overflow fail. When I did a t3 trace, this is what I get:

______________________________________________________________________________
| (075242:000002) Concatenated-Physical-Event :
| long: 45 desti: 0 source: 0 cryst: 20 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : SETUP [05] Call ref : 00 10
|______________________________________________________________________________
|
| IE:[04] BEARER_CAPABILITY (l=3) 80 90 a3
| IE:[18] CHANNEL (l=3) a9 83 83 -> T2 : B channel 3 exclusive
| IE:[1e] PROGRESS_ID (l=2) 80 83
| IE:[6c] CALLING_NUMBER (l=7) -> 01 81 Num : 30001
| IE:[7d] HLC (l=2) 91 81
|______________________________________________________________________________

______________________________________________________________________________
| (075242:000003) 1207: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 23 desti: 0 source: 15 cryst: 20 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : SETUP ACK [0d] Call ref : 80 10
|______________________________________________________________________________
|
| IE:[18] CHANNEL (l=3) a9 83 83 -> T2 : B channel 3 exclusive
|______________________________________________________________________________

______________________________________________________________________________
| (075257:000004) Concatenated-Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 20 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : INFORMATION [7b] Call ref : 00 10
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=2) -> 81 Num : 7
|______________________________________________________________________________

______________________________________________________________________________
| (075269:000005) Concatenated-Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 20 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : INFORMATION [7b] Call ref : 00 10
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=2) -> 81 Num : 4
|______________________________________________________________________________

______________________________________________________________________________
| (075282:000006) Concatenated-Physical-Event :
| long: 22 desti: 0 source: 0 cryst: 20 cpl: 2 us: 0 term: 0 type a5
| tei: 0 >>>> message received : INFORMATION [7b] Call ref : 00 10
|______________________________________________________________________________
|
| IE:[70] CALLED_NUMBER (l=2) -> 81 Num : 5
|______________________________________________________________________________

______________________________________________________________________________
| (075282:000007) 1207: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 18 desti: 0 source: 15 cryst: 20 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : CALL PROC (02) Call ref : 80 10
|______________________________________________________________________________

______________________________________________________________________________
| (075282:000008) 1207: Send_IO1 (link-nbr=1, sapi=0, tei=0) :
| long: 22 desti: 0 source: 15 cryst: 20 cpl: 2 us: 8 term: 0 type a5
| tei: 0 <<<< message sent : DISCONNECT [45] Call ref : 80 10
|______________________________________________________________________________
|
| IE:[08] CAUSE (l=2) 81 aa -> [aa] SWITCHING EQUIPMENT CONGESTION
|______________________________________________________________________________


If someone has an idea about a reason of this failure, please share with me this reason.

Thanks by advance

Best regards

[tot3nkopf]

Did you managed the external DID translation for private to public overflow?
In your case 745 corresponds to which external number?

[Medbck]

Yes I already manage it, the external number corresponding to 745 is 745. When the link between MGD and the call server is Up, I'm able to call 745 trough the public network, but not when the MGD is secured by PCS

[tot3nkopf]

Public number 745? I would expect xxxxxxx745 (the exact number that you dial from outside to reach extension 745..

[Medbck]

In deed, but the ISDN provider send only three digits in this E1

[tot3nkopf]

In deed, but the ISDN provider send only three digits in this E1

Again, the translation table should specify the external number to be dialed by the remote site for the internal user, not the user number received from the public provider.

[Medbck]

Yes, you're right about that, and the external number is 00212522489745. I already manage it. But because it still not working, I added local media gateway (close to the call server) and PCS with a different IP domain. I connect this media gateway trough an E1 trunk-group to another system (like training simulator). From this system, when the link between MG and the call server is UP, I'm able to call trough the "local E1 access" the set 745. And when the"local PCS" is actif, I manage an overflow to an analog set connected to the simulator system.

So when I try to make a call to 745 from a local MGD and the PCS is actif, the overflow is working fine. But when I try to make an incoming call (from a second analog set connected to the simulator) trough the E1 to reach 745 the overflow is not working, and the trace I sent before was for this type of call.

[tot3nkopf]

From sys doc regarding overflow on DID set:

The system checks the right to overflow of the calling party (61001).

Note: If this parameter is set to No, then the call is rejected.

Maybe this is your case? Or maybe routing (ARS) wrongly configured (for sets belonging to the remote IP domain containing the PCS a second route should be configured with a local E1 access)?

[Medbck]

I'd like to specify that the calling party is external, when it's internal the overflow is working fine, so where should I manage rights for external calling party?
And thanks for your kind assistance

[tot3nkopf]

I'd like to specify that the calling party is external, when it's internal the overflow is working fine, so where should I manage rights for external calling party?
And thanks for your kind assistance

The rights must be assigned to internal users that belong to a different IP domain: In user COS of the destination extension overflow on o/s must be set to yes.

Additionally you can check if in calsses of service --> access COS -->public access cos -->DID overflow on total busy (but I do not think this is relevant in this case --> never had problems with private to public overflow but maybe I did not had smth modified here in my case).