[asterisk-dev] Failure on multiple malformed SIP URI: a case study, likely bugs

[Kirill 'Big K' Katsnelson]

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 at 10.20.0.104>;tag=as291c44bd
Contact: <sip:Joe Schmoe at 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 at 10.20.0.104
>   * SIP Call
>   Curr. trans. direction:  Outgoing
>   Call-ID:                0ba7ab641f55bc096a3ae2772d528828 at 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 at 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 at 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