02-04-2009 09:23 AM
I have 3845 Router with 3 E1s IDSN,
I have 2 DVPM2-64.
I have Dail peer using SIP with a carrier & in the same time have E1s IDSN.
my problem is the following:
The number of SIP call leg Number is much higher than Telephony call legs????
SIP reach 98 calls , & active calls around 38 calls ????? why?
below is the output of
show call active voice br
Telephony call-legs: 34
SIP call-legs: 98
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 132
show voice call status
38 active calls found
show voip rtp connection:
Found 37 active RTP connections
sh ver
Cisco 3845 (revision 1.0) with 225280K/36864K bytes of memory.
Processor board ID FCZ1020725E
2 Gigabit Ethernet interfaces
93 Serial interfaces
3 Channelized/Clear E1/PRI ports
DRAM configuration is 64 bits wide with parity enabled.
479K bytes of NVRAM.
c3845-ipvoicek9-mz.124-20.T1.bin
sh run
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
logging buffered 4096
!
no aaa new-model
network-clock-participate wic 0
network-clock-participate wic 1
!
dot11 syslog
ip source-route
ip cef
!
!
!
!
no ip domain lookup
multilink bundle-name authenticated
!
!
isdn switch-type primary-net5
!
voice-card 0
no dspfarm
!
!
!
voice service pots
!
voice service voip
sip
!
!
voice class codec 1
codec preference 1 g729br8 bytes 20
codec preference 2 g723r63 bytes 24
codec preference 3 g723r53 bytes 20
codec preference 4 g711alaw bytes 160
codec preference 5 g729r8 bytes 20
!
!
controller E1 0/0/0
framing NO-CRC4
pri-group timeslots 1-31
!
controller E1 0/1/0
framing NO-CRC4
pri-group timeslots 1-31
!
controller E1 0/1/1
framing NO-CRC4
pri-group timeslots 1-31
!
!
interface GigabitEthernet0/0
load-interval 30
duplex full
speed auto
media-type rj45
!
interface GigabitEthernet0/1
no ip address
shutdown
duplex auto
speed auto
media-type rj45
!
interface Serial0/0/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
isdn send-alerting
no cdp enable
!
interface Serial0/1/0:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
!
interface Serial0/1/1:15
no ip address
encapsulation hdlc
isdn switch-type primary-net5
isdn incoming-voice voice
no cdp enable
!
ip forward-protocol nd
!
no ip http server
no ip http secure-server
!
!
control-plane
!
!
!
voice-port 0/0/0:15
!
voice-port 0/1/0:15
!
voice-port 0/1/1:15
!
dial-peer voice 100 voip
huntstop
voice-class codec 1
session protocol sipv2
incoming called-number .T
dtmf-relay rtp-nte
no vad
!
dial-peer voice 3 pots
destination-pattern .T
direct-inward-dial
port 0/1/1:15
!
dial-peer voice 1 pots
destination-pattern .T
direct-inward-dial
port 0/0/0:15
!
dial-peer voice 2 pots
destination-pattern .T
direct-inward-dial
port 0/1/0:15
02-04-2009 10:29 AM
Sometime the voip calls become stale, you see long times with "show voice call active compact".
In latest IOS, the "clear voice call" started working again. In others, the only solution is to reload the box.
02-06-2009 11:13 AM
I need to add 2 things also
first:
My scenario is only one way.
Internet SIP server--->My Router--->E1
second:
I can not find this command clear voice call in Cisco site?
is it exist in the latest version 12.4(22)?
I need this command to clear calls instad of reload router each time.
02-04-2009 11:45 AM
There can be a few reasons:
Sometimes when you're faxing, the fax calls will show up under 'show call active fax brief'.
If you're using supplementary services, you may have a SIP-SIP transfer
You could have stuck calls as Paolo mentioned.
-nick
02-06-2009 10:52 AM
Thanks alot Nick & Paolo.
based on your reply I dont have FAX calls,
and when I put show call active voice compact , i got a lot of calls . whats that mean??
plus the active RTP connection more than the active calls??whats that mean?which one should take care?
and SIP calls legs is very high more both of them
below u will find some outputs
show voice call st:
CallID CID ccVdb Port DSP/Ch Called # Codec Dial-peers
0x327C0 1CDE 0x6820687C
25 active calls found
show voip rtp conn
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
Found 44 active RTP connections
show call active voice:
Telephony call-legs: 21
SIP call-legs: 177
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
Multicast call-legs: 0
Total call-legs: 198
02-06-2009 10:59 AM
Yes stuck calls, probably you cannot clear them, reload the box and since you're there you can upgrade IOS hoping for the problem not to repeat or at least a chance to clear them.
02-06-2009 01:36 PM
You may be hitting a bug.
It could be similar to this bug : CSCsl48427
You may want to try upgrading IOS to 12.4(22)T and see if you still get these errors.
Otherwise, you may want to open a TAC case to look into the stuck call legs.
hth,
nick
02-06-2009 01:50 PM
Hmm CSCsl48427 mentions SIP-to-H.323, but the OP doesn't have that.
I'm afraid cisco doesn't have a bug yet for many cases of stuck calls and less for the inability to clear calls.
02-06-2009 03:05 PM
Yes, which is why I said "similar to".
It seems as if there are a number of corner cases of stuck calls, many of which seem to come up out of highly irregular (but syntactically and logically complete) call flows and configuration.
Quite often the stuck calls can be prevented by using a more straightforward design, or removing unnecessary complexities.
To properly troubleshoot the issue, you would need to run the pertinent debugs, clear all the calls, and then log to a syslog server. When the issue reoccurs, you have to go through the entire syslog and determine what caused it. This is why a TAC case may be a better solution for this particular issue.
-nick
02-06-2009 03:12 PM
Yes, which is why I said "similar to".
It seems as if there are a number of corner cases of stuck calls, many of which seem to come up out of highly irregular (but syntactically and logically complete) call flows and configuration.
Quite often the stuck calls can be prevented by using a more straightforward design, or removing unnecessary complexities.
To properly troubleshoot the issue, you would need to run the pertinent debugs, clear all the calls, and then log to a syslog server. When the issue reoccurs, you have to go through the entire syslog and determine what caused it. This is why a TAC case may be a better solution for this particular issue.
-nick
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: