cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
368
Views
0
Helpful
3
Replies

Charging on E1 before Call Connection

rushabhns
Level 1
Level 1

Dear NetPros,

We have a peculiar scenario here. We are having a Cisco AS5350 connected to E1 R2 CAS. The issue is that even before the calling user is getting connected or actual conversation is taking place, there is charging taking place in the system. This means that even before the actual conversation is taking place, the duration starts ticking. How can we fix this issue?? Any help or suggestions would be appreciated. Below is the config of the E1 Controller:

****************************************************

controller E1 3/0

framing NO-CRC4

ds0-group 1 timeslots 1-15,17-31 type r2-digital r2-compelled ani

cas-custom 1

country china

category 2

answer-signal group-b 1

dnis-digits min 1 max 9

groupa-callerid-end

*****************************************************

Thanx

Rushabh

3 Replies 3

smahbub
Level 6
Level 6

AS5300 will cut through its voice path as soon as it receives an ALERING message with in-band info or a CONNECT. At that point the call is established as far as the as5300 is concerned.

check the bug - CSCdm13286

some of the troubleshooting you can do was

1) On both as5300s configure:

service internal

service time deb date msec

service time log date msec

2) Make sure you're on the console or issue a "terminal monitor" if not.

3) Enable following debugs:

modem-mgmt csm debug-rbs

debug vtsp all

debug voip cc in

pacameron
Level 4
Level 4

Are the AS5350's connected to a central office switch via digital trunks or would they be attached to external channel banks that have FXO connections to the PSTN? We have had issues in the past with certain channel banks providing an immediate answer after the call is sent to them. Not much can be done about this as the problem is with the channel banks.

If you are not using channel banks, then we need to know more about who is seeing the answer - is the AS5350 sending the answer back towards the IP cloud after it has sent the call out the R2 port, or is the R2 port receiving an answer and it is being sent across the IP cloud.

Set the timestamps to the msec (service timestamps debug datetime local msec) and enable 'debug cas' and 'debug sigsm r2' and make a test call. Post the configs here so we can check them out.

Here is the debug output:

May 18 04:10:29.446: from Trunk(3): (2/28): Tx IDLE (ABCD=1001)

May 18 04:10:30.550: from Trunk(3): (2/28): Rx IDLE (ABCD=1001)

May 18 04:10:47.542: from Trunk(3): (2/8): Tx SEIZURE (ABCD=0001)

May 18 04:10:47.690: from Trunk(3): (2/8): Rx SEIZURE_ACK (ABCD=1101)

May 18 04:10:47.730: sigsm:R2: OUTGOING IDLE Got START

May 18 04:10:47.730: sigsm:R2: sig_r2_out_initialize

May 18 04:10:47.730: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:47.730: sigsm:R2: sig_r2_send_digit digit 10

May 18 04:10:47.826: sigsm:R2: OUTGOING PROCESS-A Got Digit: 1

May 18 04:10:47.826: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:47.906: sigsm:R2: OUTGOING PROCESS-A Got TONE_OFF

May 18 04:10:47.906: sigsm:R2: sig_r2_send_digit digit 2

May 18 04:10:48.006: sigsm:R2: OUTGOING PROCESS-A Got Digit: 1

May 18 04:10:48.006: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:48.090: sigsm:R2: OUTGOING PROCESS-A Got TONE_OFF

May 18 04:10:48.090: sigsm:R2: sig_r2_send_digit digit 10

May 18 04:10:48.214: sigsm:R2: OUTGOING PROCESS-A Got Digit: 1

May 18 04:10:48.214: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:48.298: sigsm:R2: OUTGOING PROCESS-A Got TONE_OFF

May 18 04:10:48.298: sigsm:R2: sig_r2_send_digit digit 7

May 18 04:10:48.430: sigsm:R2: OUTGOING PROCESS-A Got Digit: 6

May 18 04:10:48.430: sigsm:R2: sig_r2_send_caller_c

May 18 04:10:48.430: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:48.514: sigsm:R2: OUTGOING PROCESS-C Got TONE_OFF

May 18 04:10:48.514: sigsm:R2: sig_r2_send_digit digit 2

May 18 04:10:48.618: sigsm:R2: OUTGOING PROCESS-C Got Digit: 1

May 18 04:10:48.618: sigsm:R2: sig_r2_send_caller

May 18 04:10:48.618: sigsm:R2: sig_r2_send_digit digit 16

May 18 04:10:48.698: sigsm:R2: OUTGOING PROCESS-C Got TONE_OFF

May 18 04:10:48.698: sigsm:R2: sig_r2_send_digit digit 10