cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3593
Views
0
Helpful
9
Replies

SIP calls legs are more than Telephony call legs

loaiarnous
Level 1
Level 1

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

9 Replies 9

paolo bevilacqua
Hall of Fame
Hall of Fame

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.

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.

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

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

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.

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

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.

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

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

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: