[Home]

Summary:ASTERISK-02827: sip invite retry with wrong password
Reporter:mack_jpn (mack_jpn)Labels:
Date Opened:2004-11-16 01:24:37.000-0600Date Closed:2011-06-07 14:10:17
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) siplog.txt
Description:Now asterisk uac function try to send invite 3 times with wrong password setting.
and on-hook,it also send a CANCEL.

I think that is not good for UAS.

make a call to outside UAS by asterisk UAC function.
 :
 :
SIP/SDP Request: INVITE sip:20004240@tbc.nextdenden.com,with session description
SIP Status: 100 Trying
SIP Status: 407 Proxy Authentication Required
SIP Request: ACK sip:20004240@tbc.nextdenden.com
SIP/SDP Request: INVITE sip:20004240@tbc.nextdenden.com,with session description
SIP Status: 100 Trying
SIP Status: 407 Proxy Authentication Required
SIP Request: ACK sip:20004240@tbc.nextdenden.com
SIP/SDP Request: INVITE sip:20004240@tbc.nextdenden.com,with session description
SIP Status: 100 Trying
SIP Status: 407 Proxy Authentication Required
SIP Request: ACK sip:20004240@tbc.nextdenden.com
 :
 :
and on hook
 :
 :
SIP Request: CANCEL sip:20004240@tbc.nextdenden.com
SIP Status: 200 OK

send INVITE 1 time and do not send CANCEL is better.
What about that?
Comments:By: Brian West (bkw918) 2004-11-16 01:39:18.000-0600

Its not what you think.. its what the RFC says... can you please point out the part of the RFC we are not following and post your sip.conf and a "sip debug" please.  Also what devices you are using and if you have tried insecure=very on your sip entry.

bkw
By: Olle Johansson (oej) 2004-11-16 11:28:30.000-0600

And post SIP bugs in the SIP category, not in APPLICATIONS
By: mack_jpn (mack_jpn) 2004-11-16 11:43:26.000-0600

Sorry.>oej

This situation.
UAC is asterisk and UAS is ITSP service like a FWD and so on.

When the passowrd is wrong. a couple trying messege isn't grad for UAS.
That is looks like a brute force for UAS.

Some Japanese Carriers says so :-(
By: Olle Johansson (oej) 2004-11-16 12:03:52.000-0600

"When the passowrd is wrong. a couple trying messege isn't grad for UAS.
That is looks like a brute force for UAS."

I still don't understand you. Please add a SIP debug output in a text file attached to this bug report, otherwise I can't see what happens in your network and what you want to fix.

We *have* to send a cancel if an invite doesn't succeed. THe problem seems to be the password - why don't you set the correct password so we succeed with the first invite?
By: mack_jpn (mack_jpn) 2004-11-16 12:41:56.000-0600

yes. almostly right > oej

but japanese carrier says.
'We change the password at UAS side for secure reason and another.'

I think
If the password change at UAS side and/or server application cannot query password from user DB,
So many clients will make brute force packet.

Maybe they afraid like a this situation. :-(

Now Japanese carriers have huge subscribers each carrier.
because quite sensitive.

they are making quality control guidelines at first.
and clients must agree this guidelines. X-(
By: mack_jpn (mack_jpn) 2004-11-16 12:45:19.000-0600

yes. almostly right > oej

but japanese carrier says.
'We change the password at UAS side for secure reason and another.'

I think
If the password change at UAS side and/or server application cannot query password from user DB,
So many clients will make brute force packet.

Maybe they afraid like a this situation. :-(

Now Japanese carriers have huge subscribers each carrier.
because quite sensitive.

they are making quality control guidelines at first.
and clients must agree this guidelines. X-(
By: Mark Spencer (markster) 2004-11-16 16:59:32.000-0600

Where is the real "sip debug"?  The bug guidelines clearly ask you to post the result of "sip debug" none of which is attached here.
By: mack_jpn (mack_jpn) 2004-11-16 23:01:31.000-0600

thanks mark.

I attached a log
but I'm sorry to change that log file.because now is in NDA.
I cannot disclose some information about server side...

edited on: 11-16-04 23:02
By: Mark Spencer (markster) 2004-11-16 23:08:07.000-0600

They keep sending proxy auth to our INVITE and neither reject it nor accept it.  What exactly would you expect us to do?
By: mack_jpn (mack_jpn) 2004-11-16 23:56:51.000-0600

ok.

I think that is good for local policy.
I wish to try to quick hack about this order. :-)

thanks.
By: mack_jpn (mack_jpn) 2004-11-17 18:34:36.000-0600

Hi again.

I think the last CANCEL donot send is better than this situation.

RFC says.

RFC3261
9 Canceling a Request
  CANCEL has no effect on a request to which a UAS has
  already given a final response.

9.1 Client Behavior (Page 53)
  If the original
  request has generated a final response, the CANCEL SHOULD NOT be
  sent, as it is an effective no-op, since CANCEL has no effect on
  requests that have already generated a final response.

Any idea?
By: Mark Spencer (markster) 2004-12-04 19:11:50.000-0600

The cancel is for a different transaction (even a different number) and did not receive a response.
By: twisted (twisted) 2004-12-15 20:56:37.000-0600

Still an issue?

--Housekeeping
By: mack_jpn (mack_jpn) 2004-12-15 20:58:48.000-0600

thanks all.

I was fixed this problem by myself :)

please close.
By: twisted (twisted) 2004-12-15 21:21:18.000-0600

closed per poster