Subject: RE: [SIP] Announcements in SIP (401 & 407 contact)

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 29 Jan 2001 03:03:14 -0500

> -----Original Message-----
> From: Rick Dean [mailto:[email-masked]]
> Sent: Wednesday, January 24, 2001 12:34 PM
> To: Bryan Byerly
> Cc: [email-masked]; [email-masked]
> Subject: Re: [SIP] Announcements in SIP (401 & 407 contact)
> 
> 
> 
> Sadly, I just discovered the hard way that the contact
> header of a 407 and 401 (authentication required) response
> is like 3xx not 200.  
> 
> From: draft-ietf-sip-rfc2543bis-02.txt
> >        4xx, 5xx and 6xx responses: The Contact response-header field
> >             can be used with a 4xx, 5xx or 6xx response to 
> indicate the
> >             location where additional information about the 
> error can
> >             be found.
> 
> I suppose this also means these response cannot form a route.
> 
> Does anyone use them in this fashon for 401 and 407?  
> 
> --
> Rick
> 

There is a general issue here of whether record-routing makes sense for
non-200 responses (since Contact in a 200 has a record-route type of
semantic). I have come to the conclusion that usage of record-route, and
thus of a 200-style semantic to contact, does NOT make sense anywhere but
200 class responses. The reason is that the notion of a route is tied to the
notion of a session over which the route is used. Only 200 sets up a
session. Even things like 401/407, which look like a session is there of
sorts, don't have one. Authorization in sip is stateless. Its perfectly fine
for a request to go to one server, for it to get a challenge in response,
and for a resubmitted request (now with credentials) to go to a different
server in that same realm. Works quite fine; better, in fact, than if you
record-route.

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.

---

From: Patrice Calhoun <[email-masked]>
Date: Mon, 29 Jan 2001 05:48:34 -0800 (PST)

> server in that same realm. Works quite fine; better, in fact, than if you

I appologize if this is obvious, and just a misunderstanding on my part on how
SIP works, but how would stateless challenges be issued, and the response be
returned to a different server. I would assume that a challenge has to be
non-replayable, and therefore the server generating the challenge wants to be
sure that the response corresponds to a challenge that was recently issued.

How is this guaranteed, if servers are stateless (meaning, I guess, they do
not keep track of challenges issued), and the response is not guaranteed to
hit the same server that issued the challenge.

One way, I suppose, is to define the format of the challenge to include a
timestamp.

PatC