SIP Dialog is not destroying

core show channels is zero but however, sip dialog is still exist for which RTP port get occupied and its not get auto cleanup. 100 5647eda61c30dc5 (nothing) No Rx: INVITE 100 100 3daf75f09ffd306 (nothing) No Rx: INVITE 100 100 0f3034aa42577ad (nothing) No Rx: INVITE 100 100 bf7051de7b76375 (nothing) No Rx: INVITE 100 100 af092cdb52fe518 (nothing) No Rx: INVITE 100 905 a325d215e41b734 (nothing) No Rx: INVITE 905 805 22f163e5085278c (nothing) No Rx: INVITE 805 100 5e952633f76fd48 (nothing) No Rx: INVITE 100 100 70bf9e933f65d43 (nothing) No Rx: INVITE 100 100 3ae052804385d2b (nothing) No Rx: INVITE 100 100 aac452c42aaef65 (nothing) No Rx: INVITE 100 100 00395098b2650b8 (nothing) No Rx: INVITE 100 100 44b576a6f894e5e (nothing) No Rx: INVITE 100 100 1dea806e156c5e2 (nothing) No Rx: INVITE 100 100 7dd7fdc6ab6171c (nothing) No Rx: INVITE 100 100 4d755cd306f2437 (nothing) No Rx: INVITE 100 905 f9305597b5306fc (nothing) No Rx: INVITE 905 100 2a9891dfe06dd9e (nothing) No Rx: INVITE 100

however if i check sip show channel <call_id>

Curr. trans. direction: Incoming
Call-ID: 1dea806e156c5e2773d0582549d3c62e
Owner channel ID:
Our Codec Capability: (ulaw|alaw|gsm|h263)
Non-Codec Capability (DTMF): 1
Their Codec Capability: (ulaw|gsm|g723|adpcm|alaw|g729|g726)
Joint Codec Capability: (ulaw|alaw|gsm)
Format: (nothing)
T.38 support No
Video support No
MaxCallBR: 384 kbps
Theoretical Address:
Received Address:
SIP Transfer mode: open
Force rport: Yes
Audio IP: (local)
Our Tag: as32e79285
Their Tag: 0c26cd11
SIP User agent: PBX
Username: 100
Peername: 100
Original uri: sip:100@
Caller-ID: 100
Need Destroy: No
Last Message: Rx: INVITE
Promiscuous Redir: No
Route: sip:100@;transport=udp
DTMF Mode: rfc2833
SIP Options: (none)
Session-Timer: Inactive
Transport: UDP

then session-timers is showing inacive. although session-expires is configured for 600 secs. with default uas mode.

How can we prevent it?

What change did you make recently? chan_sip shouldn’t be used in new systems and is, effectively unsupported, so I assume this is an old system that used to work.

we are using asterisk 13 and have not made any changes recently , Currently we are getting anonymous invite traffic very frequently,
we are thinking to use fail2ban but we have still doubt that why port allocation issue is coming however we have configured session expire to 600.
is there any attack could make DoS for port allocation in asterisk by sub dialogues like hold forwarding etc. ?
if chan_sip is not stable for SIP dialog life cycle ( which could cause port allocation) then we could move to pj_sip.
we really appreciate your response.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.