[Home]

Summary:ASTERISK-19984: sip configuration with insecure
Reporter:Abhay Gupta (agupta)Labels:
Date Opened:2012-06-12 05:30:01Date Closed:2012-06-19 08:01:25
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/Messaging
Versions:10.5.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Linux all OSAttachments:
Description:while using SIP Invite with secret we have added insecure-invite,port , but for sip messaging it does not allow to send SIP messages .

We get Unauthorized back on SIP MESSAGE and on retransmitting with authentication it says 482 loop detected . If we give insecure=invite,port,message it works but this warning appears on CLI

[Jun 12 06:24:18] WARNING[26441]: chan_sip.c:27129 set_insecure_flags: Unknown insecure mode 'very' on line 0
Comments:By: David Woolley (davidw) 2012-06-12 05:50:08.738-0500

Thanks for your comments. This does not appear to be a bug report and I expect it to get closed. We appreciate the difficulties you are facing, but it would make more sense to raise your question in the support tracker, http://www.asterisk.org/support.

insecure only affects incoming methods, so is irrelevant to sending messages.

There is a lot of bad information around with respect to the use of insecure = port.  ITSPs seem to throw in every option because they don't want to think about what is the real minimum security compromise.

I find it difficult to believe that you don't have insecure=very somewhere, which I think was removed because it hid this misuse of insecure=port.
By: Abhay Gupta (agupta) 2012-06-12 07:03:39.057-0500

Below is the SIP log from a registered SIP user .

{noformat}
<--- SIP read from UDP:77.1.251.123:63301 ---> MESSAGE
sip:00491743188851@209.143.142.99:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.178.34:5060;rport;branch=z9hG4bKPj48e865bd418945bfbb9bac75ffce0cff
Max-Forwards: 70
From: "sib1000"
<sip:sib1000@209.143.142.99>;tag=520f745d2f9d426e8fef9c99597c5619
To: <sip:00491743188851@209.143.142.99>
Call-ID: 8ea9502faf7845ce9f4a168c921295b6
CSeq: 26647 MESSAGE
Content-Type: text/plain
Content-Length: 2

Hi
<------------->
--- (9 headers 1 lines) ---
Receiving message!
Found peer 'sib1000' for 'sib1000' from 77.1.251.123:63301

<--- Transmitting (NAT) to 77.1.251.123:63301 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
192.168.178.34:5060;branch=z9hG4bKPj48e865bd418945bfbb9bac75ffce0cff;receive
d=77.1.251.123;rport=63301
From: "sib1000"
<sip:sib1000@209.143.142.99>;tag=520f745d2f9d426e8fef9c99597c5619
To: <sip:00491743188851@209.143.142.99>;tag=as1afee3ee
Call-ID: 8ea9502faf7845ce9f4a168c921295b6
CSeq: 26647 MESSAGE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="51919d34"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '8ea9502faf7845ce9f4a168c921295b6' in
32000 ms (Method: MESSAGE) Scheduling destruction of SIP dialog
'8ea9502faf7845ce9f4a168c921295b6' in 32000 ms (Method: MESSAGE)

<--- SIP read from UDP:77.1.251.123:63301 ---> MESSAGE
sip:00491743188851@209.143.142.99:5060 SIP/2.0
Via: SIP/2.0/UDP
192.168.178.34:5060;rport;branch=z9hG4bKPj25c907a5e7bc4d4bb51faf04b0918298
Max-Forwards: 70
From: "sib1000"
<sip:sib1000@209.143.142.99>;tag=520f745d2f9d426e8fef9c99597c5619
To: <sip:00491743188851@209.143.142.99>
Call-ID: 8ea9502faf7845ce9f4a168c921295b6
CSeq: 26647 MESSAGE
Authorization: Digest username="sib1000", realm="asterisk",
nonce="51919d34", uri="sip:00491743188851@209.143.142.99:5060",
response="26afb8f20a369fc9c12d8be4d5240a58", algorithm=MD5
Content-Type: text/plain
Content-Length: 2

Hi
<------------->
--- (10 headers 1 lines) ---

<--- Transmitting (NAT) to 77.1.251.123:63301 --->
SIP/2.0 482 (Loop Detected)
Via: SIP/2.0/UDP
192.168.178.34:5060;branch=z9hG4bKPj25c907a5e7bc4d4bb51faf04b0918298;receive
d=77.1.251.123;rport=63301
From: "sib1000"
<sip:sib1000@209.143.142.99>;tag=520f745d2f9d426e8fef9c99597c5619
To: <sip:00491743188851@209.143.142.99>;tag=as6730f5d2
Call-ID: 8ea9502faf7845ce9f4a168c921295b6
CSeq: 26647 MESSAGE
Server: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
PUBLISH
Supported: replaces, timer
Content-Length: 0


<------------>
{noformat}

By: Abhay Gupta (agupta) 2012-06-12 07:10:57.067-0500

We are using Asterisk realtime and the user is a registered sip user and not any ITSP . Moreover we are using asterisk messaging feature released in asterisk 10 and this is equivalent to INVITE for incoming message .

{noformat}
mysql> select * from sippeers where name='sib1000';
+---------+-------------+--------+-----------+---------+--------------+---------+----------+---------+------+---------+----------+------------+--------------------------------------+-------------+-------------+----------+----------------+------------+--------------+-------+------------+--------------+--------+----------+-----------+--------------+-----------+
| name    | defaultuser | type   | secret    | host    | callerid     | context | dtmfmode | mailbox | nat  | qualify | authuser | fromdomain | fullcontact                          | insecure    | canreinvite | disallow | allow          | restrictid | ipaddr       | port  | regseconds | useragent    | lastms | username | regserver | videosupport | transport |
+---------+-------------+--------+-----------+---------+--------------+---------+----------+---------+------+---------+----------+------------+--------------------------------------+-------------+-------------+----------+----------------+------------+--------------+-------+------------+--------------+--------+----------+-----------+--------------+-----------+
| sib1000 | sib1000     | friend | 375590275 | dynamic | 496184591066 | sip-in  | rfc2833  | NULL    | yes  | no      | NULL     | NULL       | sip:sib1000@192.168.178.34:5060^3Bob | invite,port | no          | all      | g729;ulaw;h264 | NULL       | 77.1.251.123 | 63482 | 1339502834 | SIPLink v2.1 |      0 | sib1000  |           | yes          | udp       |
+---------+-------------+--------+-----------+---------+--------------+---------+----------+---------+------+---------+----------+------------+--------------------------------------+-------------+-------------+----------+----------------+------------+--------------+-------+------------+--------------+--------+----------+-----------+--------------+-----------+
1 row in set (0.00 sec)
{noformat}

By: David Woolley (davidw) 2012-06-13 05:10:20.915-0500

You are receiving a message, not sending it.

You do not need insecure in this context, or at least best practice would be to not use it.  There may be a problem with "realtime" use of insecure (I'm wondering if something in the realtime logic is mapping port,invite into the obsolete form), but it is not why your request is failing.  You definitely do not need port.

Your problem is "Loop Detected", but you need to follow this up on a support channel until you can convince someone that it is a bug, as loop detection is normally the result of a configuration error.

If you do confirm a bug, start a new issue, as the subject on the current issue appears to be misleading.  Also remember that all SIP related bugs should be accompanied by sip set debug and core set debug output for chan_sip.  These should be attached, rather than included inline.  I think you will also need core set verbose 3 or higher.