< Previous by Date | Date Index | Next by Date > |
< Previous in Thread | Thread Index | Next in Thread > |
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 Sent: Wed 1/17/2007 4:27 PM To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx 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”
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 |