cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
736
Views
6
Helpful
7
Replies

ISDN PRI EI Caller id problem...

johnyoon75
Level 1
Level 1

Hello.

I have a problem about caller id on ISDN PRI.

We have a two pods voip network.

Pod-A--pbx--gw-----gw----pbx-Pod-B.

Pod-A calling to Pod-B. but, sometimes, Pod-B received Caller id, spmetimes not receive.

i have a call from a to pod B

Here is the debug output on Pod-B...

*Sep 30 19:59:29.599 KST: ISDN Se1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x0, Calling num 234571244

*Sep 30 19:59:29.599 KST: ISDN Se1/0:15 Q931: Applying typeplan for sw-type 0x12 is 0x4 0x0, Called num 7902800

*Sep 30 19:59:29.599 KST: ISDN Se1/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0022

Sending Complete

Bearer Capability i = 0x8090A3

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA9839F

Exclusive, Channel 31

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0xC0, '234571244'

Plan:Unknown, Type:Subscriber(local)

Called Party Number i = 0xC0, '7902800'

Plan:Unknown, Type:Subscriber(local)

High Layer Compat i = 0x9181

*Sep 30 19:59:29.695 KST: ISDN Se1/0:15 Q931: RX <- CALL_PROC pd = 8 callref = 0x8022

Channel ID i = 0xA9839F

Exclusive, Channel 31

*Sep 30 19:59:29.699 KST: ISDN Se1/0:15 Q931: RX <- ALERTING pd = 8 callref = 0x8022

Progress Ind i = 0x8182 - Destination address is non-ISDN

*Sep 30 19:59:35.823 KST: ISDN Se1/0:15 Q931: RX <- CONNECT pd = 8 callref = 0x8022

Progress Ind i = 0x8182 - Destination address is non-ISDN

Connected Number i = 'A', 0x80, '617901100'

*Sep 30 19:59:35.827 KST: %ISDN-6-CONNECT: Interface Serial1/0:30 is now connected to 7902800 N/A

*Sep 30 19:59:35.827 KST: ISDN Se1/0:15 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x0022

*Sep 30 19:59:54.999 KST: %ISDN-6-DISCONNECT: Interface Serial1/0:30 disconnected from 7902800 , call lasted 19 seconds

*Sep 30 19:59:54.999 KST: ISDN Se1/0:15 Q931: TX -> DISCONNECT pd = 8 callref = 0x0022

Cause i = 0x8090 - Normal call clearing

*Sep 30 19:59:55.031 KST: ISDN Se1/0:15 Q931: RX <- RELEASE pd = 8 callref = 0x8022

*Sep 30 19:59:55.031 KST: ISDN Se1/0:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x0022

Regard,

John.

7 Replies 7

teodorgeorgiev
Level 4
Level 4

Nothing wrong here, the caller ID attribute is not empty. It is 234571244.

The only issue I see here is that the called number differ from the connected number, but this could be due to many things (rewriting, call forward and etc).

What kind of ISDN protocol do you use? ETSI (NET5) ?

Progress Ind i = 0x8183 - Origination address is non-ISDN

Calling Party Number i = 0xC0, '234571244'

Called Party Number i = 0xC0, '7902800'

Destination address is non-ISDN

Connected Number i = 'A', 0x80, '617901100'

Normally in ISDN, it passes last 4 digits, am i right ?

can some one explain why its so. different numbers.

thanks,

p sylvester

mail@psylvester.net

I do no think that it is true.

"Normally in ISDN, it passes last 4 digits, am i right ?"

Not sure why you folks are circumspect about the isdn should be sending 4 digits. There is nothing like sending only 4 digit out to the pstn. It depends on the dialpeer.If you have "forward-digits" statement then you can perhaps manipulate.

Now if i look at the debug, it clearly shows that its not cisco's issue. The gateway's cannot manipulate the caller id once the setup is done. This facility is there in FXS/fxo but not for isdn.

It looks like certain channels on the pbx are mapped to static caller id's. Would be a good idea to double check on the caller id configuration on the NEC.

Regards

Venky

its European standard or ETSI

The first 3 is used to identify the exchange.

thanks,

p sylvester

mail@psylvester.net

not only in Europe. The phone exchange capacity is 9999 ports. It can be extended by co-trunking them.

However this means nothing. It is up to the PTT to decide if they are going to send the full number or not.

And 90% of them send the ANI number in E-164 format (which is toooooooooo far away from the last for 4 digits).

Thank you too!

johnyoon75
Level 1
Level 1

Hi all.

The problem was caused by pbx system.

As you see the debug message, you can find different isdn type such as isdn type and isdn plan.

Calling Party Number i = 0xC0,

Plan:Unknown, Type:Subscriber(local)

Called Party Number i = 0xC0,

Plan:Unknown, Type:Subscriber(local)

When i manually configured isdn plan from unkwon to isdn using translate rule, i can see the caller number on opposit site.

the problem was caused by pbx systems...

Thank alot everybody.

regard,

john.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: