| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index |
|
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@xxxxxxxxxxxx] 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@xxxxxxxxxxxxxxxxxxxx on behalf of Justin Matthews Are there at least any
objections to adding this functionality to DUM? “Anyone….Anyone……………..Bueller……Bueller” J Thanks, -justin From: Justin Matthews
[mailto:jmatthewsr@xxxxxxxxx] 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@xxxxxxxxx] 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 |