Affects Version/s: None
Target Release Version/s: None
We at snom have problems with Asterisk when we receive calls without the
line indication. When we register we place a contact like this:
REGISTER sip:asterisk SIP/2.0
When we receive the 200 Ok, we search for the "h35h345". If we don&
it, we try to guess which line is affected. This is relatively easy on a
REGISTER response, but on an incoming INVITE we have serious problems. I
think some of the challenging and line-assignment problems are related to
Strictly speaking, we register the contact
"sip:email@example.com;line=h35h345", NOT "sip:firstname.lastname@example.org"! Parameters
are an essential part of a URI which must not be discarded.
- ADDITIONAL INFORMATION ******
BTW the line-id has also the function of increasing the security
significantly. Just imaging a network script that sprays INVITE packets
through the network - the whole office would start ringing.
- Give the colleagues a wake-up call!
while [ $i -lt 256 ]; do
echo INVITE sip:192.168.0.$i SIP/2.0^M >junk.txt
echo f: sip:email@example.com^M >>junk.txt
echo t: sip:firstname.lastname@example.org^M >>junk.txt
echo i: this@junk^M >>junk.txt
echo l: 0^M >>junk.txt
echo CSeq: 1 INVITE^M >>junk.txt
cat junk.txt >/dev/udp/192.168.0.$i/5060
Unfortunately, the snom phones are not able to pick the right line on these
By requiring the line id, the phone would reject the INVITE as it can not
match the request URI with any valid line on the phone! BTW that&
ASTERISK-7996;s why I
hate "direct IP calls" - it gives you zero security against such attacks.
Our latest image is 2.03e (http://snom.com/download/share), it does strict
line id comparison and tries to deal with "junk" line identifications as
good as possible.