[reSIProcate] build challenge (407) after requiresChallenge()in DUM

[Justin Matthews]

Thanks for the response Scott.

 

The need for this behavior is based on efficiency as well as some
limitations with another subsystem in our application.  In the normal
scenario there are very few inbound INVITE's that will be challenged.  It is
therefore inefficient for our DUM subsystem to send an event for every
INVITE to the system that will decide if the INVITE should be challenged
(this decision making process also starts other time consuming processing).


 

Response to your points (assuming that you now believe there is a need for
our proposal)

 

1)       Yes, this is possible but will destroy the dialogset.on to Point 2:

2)       There is a real potential that under load the new INVITE with auth
info in it is processed while the dialogset/dialog/inviteSession is
terminating, which will result in an incorrect 4xx response.  I cannot take
the chance that this can occur.

 

With my limited understanding of DUM, I believe that this can be done with a
new state, logic for the new state to handle the ACK to the 407 and the
retried INVITE and a 32(s) timer.  Maybe I can implement the 32(s) timer for
all sessions?

 

Thanks again,

 

-Justin

 

  _____  

From: Scott Godin [mailto:slgodin at icescape.com] 
Sent: Wednesday, January 17, 2007 5:32 PM
To: Justin Matthews; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] build challenge (407) after requiresChallenge()in
DUM

 

I don't think I fully understand why you need these changes in the first
place, and what's missing from the current framework.  You can override the
ClientAuthManager and add customer behaviour.

 

Some other points (assuming the need for your proposal makes sense):

1.  Can't you override onReadyToSend to add auth headers to a reject(407)
message?

2.  Do you really need to reuse the same dialogset after issuing a 407?
Currently the dialogset will be destroyed immediately after sending the 407.
There are some other good reasons for keeping it around for 32 seconds,
related to absorbing 200 restransmissions - but that hasn't been implemented
yet.

 

 

Scott

 

  _____  

From: resiprocate-devel-bounces at list.resiprocate.org on behalf of Justin
Matthews
Sent: Wed 1/17/2007 4:27 PM
To: resiprocate-devel at list.sipfoundry.org
Subject: Re: [reSIProcate] build challenge (407) after requiresChallenge()in
DUM

Are there at least any objections to adding this functionality to DUM?

 

"Anyone..Anyone.......Bueller..Bueller"

 

:-)

 

Thanks,

-justin

 

  _____  

From: Justin Matthews [mailto:jmatthewsr at gmail.com] 
Sent: Tuesday, January 16, 2007 10:58 AM
To: 'resiprocate-devel at list.sipfoundry.org'
Subject: RE: build challenge (407) after requiresChallenge() in DUM

 

Doing this would require DUM ServerInviteSession->Reject() to be able to
recognize the 407/401 and do special handling to create the challenge and
then handle the subsequent re-tried INVITE correct?  What happens to the
DialogSet, Dialog, InviteSession in this case?  If all were destroyed when
sending the 407/401, which is what normally happens when a
ServerInvitesession->Reject(4xx) is sent, is there a timing problem if the
dset, dialog, invitesession are not torn down completely and the retried
INVITE w/auth comes in?  To solve this would a new state need to be added to
ServerInviteSession to wait for the ACK to 401/407 and then hang around for
a bit (32s) to see if a retried INVITE w/auth is coming?  

 

Thanks!

 

-justin

 

  _____  

From: Justin Matthews [mailto:jmatthewsr at gmail.com] 
Sent: Monday, January 15, 2007 4:06 PM
To: 'resiprocate-devel at list.sipfoundry.org'
Subject: build challenge (407) after requiresChallenge() in DUM

 

Is it possible to build a 407 (with challenge info) after returning False to
requiresChallenge() in DUM?  The reason for this is that invite requests are
shipped as events somewhere else in the system and challenges to invites are
the exception not the general rule.  It would save time to just allow the
other portion of our system to end these particular calls with 407 rather
than asking if a challenge is required for every invite.

 

Thanks,

-justin

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070117/8d2c58ca/attachment.htm>