Subject: [SIP] Clarification of 302 handling

From: Sean Olson <[email-masked]>
Date: Fri, 19 May 2000 12:00:30 -0500 (CDT)

I thought this was pretty cut and dry, but I noticed some odd
behaviour in a SIP client today and after looking through the RFC2543bis
draft, I didn't see this spelled out anywhere.

Is it legal to rewrite the To: field in a subsequent request that resulted
from a 302 response? (Can you replace the To: field with the Contact: 
information from the 302 response?)

In section 7.3.3 (302 Moved Temporarily), it states

"The requesting client SHOULD retry the request at the new address(es)
 given by the Contact: header field."

I interpret this to mean take the same request (To/From/etc. unchanged),
replace the Request-URI with the Contact: in the 302, and re-issue 
the request to the new address specified in the Request-URI.

I can understand changing the From: perhaps, but changing the To: seems 
a bit odd. If you can't count on the To: header being immutable to an
extent, it makes service creation a little more difficult.

Comments?
Sean

--
Sean Olson <[email-masked]>

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2000 13:39:19 -0400

There is presumably nothing that can keep a user from
cutting-and-pasting the Contact information into a new call To field
(particularly if the UA supports ask-me-before-redirection), but that
would seem to be unusual behavior.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 14:17:10 -0400

Right. Any one of several possible behaviors are allowed and will work:

1. The UA basically changes the request URI and uses a different branch
ID in the top Via, but the CSeq, To, From and Call-ID are the same.
2. The UA uses a new To field, request URI, but the Call-ID is unchanged
(doesn't matter if the CSeq changes, since its defined within the
To/From/Call-ID space)
3. The UA uses a brand new To, From, Call-ID, CSeq, etc. as if it were a
totally new request.

Probably (1) is best, since it will be noted by proxies as being the
same request transaction, and thus avoid contacting locations already
tried. All three work, but I wouldn't recommend (2), since this might
introduce interactions with multiparty conferencing stuff.

-Jonathan R.

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 19 May 2000 14:12:55 -0400

> introduce interactions with multiparty conferencing stuff.
Wording added:

The new request can take two different forms.  In the first approach,   
the \header{To}, \header{From}, \header{CSeq} and \header{Call-ID}      
header fields in the new request are the same as in the original        
request, with a new \header{branch} identifier in the \header{Via}      
header field.  Proxies {\SHOULD} follow this behavior and UACs {\MAY}.  
UAs {\MAY} also use the \header{Contact} information for the \header{To}
header field, as well as a new \header{Call-ID} value.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 19 May 2000 14:44:44 -0400

I believe UAC should increase CSeq if it decides to keep the original
To, From and Call-ID in the new request.

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 16:34:33 -0400

Henning Schulzrinne wrote:
> header field. 

, and the new address in the \header{Request-URI}.

> Proxies {\SHOULD} follow this behavior and UACs {\MAY}.

\MUST follow this behavior (they can't change the Call-ID, To, From or
CSeq, not any other choice then)

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 16:35:43 -0400

Not neccesarily. No reason that the UA can't do exactly the same as a
proxy does. I argued in a previous email that there are advantages to
this, since it means as the new request is forwarded, proxies can
recognize this as the same transaction and not forward to addresses they
already tried.

-Jonathan R.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 19 May 2000 16:50:09 -0400

If a UA does this, any proxy compliant to RFC2543 will consider the new
request a retransmission of the old one. Top Via is not part of the call
leg (aka transaction) id according to the RFC. Besides, I see absolutely
no point in making the UAC keep the Cseq the same: any proxy interested
in following call progress should be able to match the re-INVITEs with
increased CSeq anyway so why not increase the CSeq and make everything
consistent?

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 19 May 2000 17:17:29 -0400

Igor Slepchin wrote:
> leg (aka transaction) id according to the RFC.

Its only consider a retransmission if the request URI is the same
(recall the new rules for loop detection). If the request URI is the
same, then you get exactly what you want - the proxy treats this as a
retransmission  or rejects it as a merged request. We've already tried
that address.

 Besides, I see absolutely
> increased CSeq anyway so why not increase the CSeq and make everything

I am not advocating using the same CSeq for purposes of tracking calls,
but for purposes of unifying the way a proxy does recursion and the way
a UAC does recursion. You get the benefit of not trying places again
you've already tried.

-Jonathan R.