RE: [SIP] DNS SRV and authentication challenges

[Jonathan Rosenberg <jdrosen@dynamicsoft.com>]

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se]
> Sent: Monday, June 18, 2001 2:37 PM
> To: Jonathan Rosenberg
> Cc: 'Bob Penfield'; adam.roach@ericsson.com; 'Rich Schaaf'; 
> sip@ietf.org
> Subject: Re: [SIP] DNS SRV and authentication challenges
> 
> > One of the nice things about the current SRV mechanism is 
> that its nicely
> > layered. To properly implement it, I don't need to know the 
> conditions under
> > which the transaction is being initiated. If, all of a 
> sudden, I need to
> > know call level or header-level semantics in order to do 
> the right thing
> > with SRV, we get a code nightmare. Therefore, requiring 
> that the request for
> > the INVITE after a challenge result in the same SRV 
> decision as the previous
> > INVITE is a big mistake, IMHO.
> 
> I agree with you that the protocol should ONLY ensure that
> 1) retransmissions of a request
> 2) ACKs for non 2xx reponses
> 3) CANCELs
> are sent to the same network address than the initial request.
> 
> Since a second INVITE with authentication stuff is not any of these 3
> cases, we should use the randomization algorithm used for choosing one
> network address among all the SRV records provided.
> 
> 
> However, I do not agree that we run into a code nightmare. I believe
> that the code would be even simpler. Right now, in order to send
> retransmissions, CANCELs and ACKs to the same network address we
> typically use a hash of some fields, such as To, From, the 
> numeric part
> of the Cseq and the Call-ID. If intead of using all these variables we
> just use the Call-ID, all the requests within a call will be 
> sent to the
> same network address.

What I was objecting to was making the SRV process dependent on the
particular request scenario (i.e., special treatment for requests that are a
result of a 401/407). 

I have no issues with just using the Call-ID to generate the pseudo-random
number for SRV, as opposed to the transaction ID. As you have pointed out,
it seems to solve a few problems. Can anyone think of any difficulties this
change would introduce?

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip