[prev in list] [next in list] [prev in thread] [next in thread]
List: asterisk-dev
Subject: [asterisk-dev] Failure on multiple malformed SIP URI: a case study,
From: "Kirill 'Big K' Katsnelson" <kkm () adaptiveai ! com>
Date: 2009-11-30 8:28:52
Message-ID: 4B138244.8070000 () adaptiveai ! com
[Download RAW message or body]
Recently had Asterisk run out of handles because a peer sent malformed
SIP packets.
We have set up a trunk with a peer. They use Avaya, other particulars
are unknown. The trunk was set up to match host address only, no
username= in the sip.conf trunk definition. We have a VPN connection
over to them, and they had trouble taming Avaya to send a consistent
username to us, so I thought that was fine. The setup worked initially.
Next day Asterisk suddenly came down with tons of "too many open files"
type errors marked with different .c file names, e. g.
tcptls.c:245 ast_tcptls_server_root: Accept failed: Too many open files
Here is my analysis of what has happened
1. The partner's PBX sent us malformed SIP INVITE packets. Specifically,
both From: and Contact: lines contained a space in the username part:
From: "Joe Schmoe" <sip:Joe Schmoe@10.20.0.104>;tag=as291c44bd
Contact: <sip:Joe Schmoe@10.20.0.104>
Lesson learned: Avaya is not less buggy that Asterisk. Yay!
2. Asterisk faithfully ACKed the call and placed it into a queue. Then
it tried to invite agents with that call. The From: and Contact: headers
forwarded unchanged.
The agent's stack (PJSIP 1.2) correctly refused to ACK the packet, so
INVITEs sent by Asterisk essentially never got any response from the UAC
end.
Problem: We likely have a bug here. Asterisk should have dropped the
INVITEs without ACKing them in the first place.
Now, RFC3261, Sec. 25.1. does not allow spaces in SIP URLs. I could not
find, however, any pointers as to how a stack should behave if it
receives incorrect packets.
3. After the stack has rejected the INVITE, the SIP dialog sits in
Asterisk server forever (~70 hours, and they are still there).
After each client's attempt to INVITE I got one more of these. 40
minutes ws enough to bring asterisk down, and I began to accrue thes
again after a restart:
> PBX4a*CLI> sip show channels
> Peer User/ANR Call ID Format Hold Last Message Expiry
> 10.20.0.115 dyn-foobar 0ba7ab641f55bc0 0x0 (nothing) No Init: INVITE
> 10.20.0.115 dyn-foobar 4f6716b9008c7c7 0x0 (nothing) No Init: INVITE
> 10.20.0.115 dyn-foobar 478db6477a4a5df 0x0 (nothing) No Init: INVITE
total 93 lines like these.
Every one of them looks like this (maybe somebody can spot what's worng
with them?):
> PBX4a*CLI> sip show channel 0ba7ab641f55bc096a3ae2772d528828@10.20.0.104
> * SIP Call
> Curr. trans. direction: Outgoing
> Call-ID: 0ba7ab641f55bc096a3ae2772d528828@10.20.0.104
> Owner channel ID: <none>
> Our Codec Capability: 4
> Non-Codec Capability (DTMF): 1
> Their Codec Capability: 0
> Joint Codec Capability: 4
> Format: 0x0 (nothing)
> T.38 support No
> Video support No
> MaxCallBR: 384 kbps
> Theoretical Address: 10.20.0.115:65349
> Received Address: 10.20.0.115:65349
> SIP Transfer mode: open
> NAT Support: RFC3581
> Audio IP: 10.20.0.104 (local)
> Our Tag: as5b802e66
> Their Tag:
> SIP User agent:
> Username: dyn-foobar-120
> Peername: dyn-foobar-120
> Original uri: sip:dyn-foobar-120@10.20.0.115:65349;transport=UDP
> Need Destroy: No
> Last Message: Init: INVITE
> Promiscuous Redir: No
> Route: N/A
> DTMF Mode: rfc2833
> SIP Options: (none)
> Session-Timer: Inactive
Each of these dialogs consumes 2 file handles, at least on the average:
> root@PBX4a:/etc/asterisk# ls -l /proc/`cat /var/run/asterisk.pid`/fd | wc -l
> 210
That looks like another bug to me.
So, what do you guys think? Are both (2) and (3) really bugs in
Asterisk, or one of them is just a misconfiguration? I know that
allowing unfiltered username from a peer is kind of a bold move, but my
point here is that Astersik should not allow to break itself that easily
even by bold moves on its admin part.
Have not opened any tickets yet. I am going to, or let me know pls if
you are opening any related to these issues, so we won't duplicate each
other's work.
-kkm
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic