search for: determine_firstline_parts

Anything to do about portscans? Is there any way (should I) to see if the connection is a legit (only SIP currently) connection BEFORE my * answers? [2007-10-17 19:23:46] WARNING[4191]: chan_sip.c:6624 determine_firstline_parts: Bad request protocol 01@<ASTERISK_IP> SIP/2.0 -- Executing [s at default:1] Answer("SIP/sip.jmg.se-081dd730", "") in new stack [2007-10-17 19:23:46] WARNING[4191]: chan_sip.c:6624 determine_firstline_parts: Bad request protocol 01@<ASTERISK_IP> SIP/2.0 [2007-10-...

...I have a really weird problem. I upgraded 2 Asterisk 1.2 boxes to Asterisk 1.4.18. Both are home PBX's and both boxes register to a SIP DID at exactly same provider. One box runs without errors on the console, the other box keeps repeating : [Feb 11 23:40:29] WARNING[11292]: chan_sip.c:6705 determine_firstline_parts: Bad request protocol Packet When i set debug on, it seems to come from that SIP DID. <--- SIP read from 82.101.62.99:5060 ---> Cirpack KeepAlive Packet <-------------> [Feb 11 23:37:59] WARNING[11292]: chan_sip.c:6705 determine_firstline_parts: Bad request protocol Packet --- (1 head...

Hi list, After a recent upgrade to Asterisk v1.4.14, my message log is now filling up with the following error messages: <-------------> [Dec 29 17:24:52] WARNING[10655]: chan_sip.c:6645 determine_firstline_parts: Bad request protocol Packet --- (1 headers 0 lines) --- bitis*CLI> <--- SIP read from 82.101.62.99:5060 ---> Cirpack KeepAlive Packet <-------------> Seeing as these packets are being sent by one of my service providers, I can't just turn them off. What's the best solutio...

Friends in the Asterisk community, I'm kind of interested in the slow uptake of Asterisk 1.4. Between 1.2 and 1.4 there's been a lot of important development. New code cleanups, optimization, new functions. I realize that 1.4 at release time wasn't ready for release, but we've spent one year polishing it, working hard with bug fixes. The 1.4 that is in distribution now is