Subject: [SIP] Caller receives responses

From: A Srinath <[email-masked]>
Date: Thu, 22 Jun 2000 12:22:51 +0530 (IST)

hi,
	I have a doubt regarding the number of responses that a caller may
receive after having sent an INVITE request. 

	Section 11.3 of RFC 2543 says 
	Multiple responses may arrive at a UAC for a single INVITE request 
due to a forking proxy. 

	But the algorithm outlined in section 12.4 ensures that only one
response is sent by the proxy upstream. 
	
	If this behavior is followed by the proxy then how does a UAC
receive multiple responses, or section 11.3 means all responses including 
provisional? 

Regards,

 Srinath A
 Silicon Automation Systems       Phone: 5276100, 5276108 extn 4220
 #1309, 10th Main, HAL III Stage   
 Bangalore 560 008, India                    

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

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 22 Jun 2000 10:25:50 +0100

> response is sent by the proxy upstream. 

Not quite.  The problem with the code in section 12.4 is that it
doesn't tell the whole story (else proxy-implementors would be
getting a free ride, eh? (:&).  It waits until either the request
is CANCELled, a 2xx response is received (on any branch), or non-2xx
final responses are received on all branches; you don't get to
see what happens after that.

If you read the text following the code, you'll see under the 2xx
entry that "The proxy MUST forward the response upstream towards
the client".  Now I would guess that most proxies CANCEL outstanding
branches once they've seen a 2xx (even though it's only a "MAY");
however, this does not preclude a 2xx and CANCEL "crossing on the
wire".

Furthermore, in certain conditions, a client may see multiple
non-2xx class responses to a request as the result of a downstream
forking proxy being naughty.  (This scenario is documented in section
4.2.2.)

Therefore, you cannot assume that a request will result in at
most one final response.  The multiple non-2xx class case may be
reasonably unlikely, but the multiple 2xx case is most definitely
a reality.

> receive multiple responses, or section 11.3 means all responses
> including provisional? 

My feeling that 11.3 is leaning more towards "Multiple final
responses".

Of course, multiple (in the sense that they're from different
servers) provisional (non-100) is also possible, and probably
desirable in the face of Session Progress.

Me -- I'm just glad I pulled the proxy straw. &:)

HTH,

 - Jo.

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 22 Jun 2000 10:32:58 -0400

While we are here, I would like to hear what proxy implementors think
about receiving multiple final respones on a single branch. Is it 
reasonable to simply drop final responses received after the first
one ?? I guess, dropping 200 response is not good, but it is very
unlikely that a 200 response is received on a branch after a non-200
final response. If the proxy decides to forward all 200 responses
upstream, regardless of the state of the branch and transaction, the
branch state gets kind of messy.

Also, it was suggested on this list that proxies should not drop 
final responses which do not append a tag to the To header. If a proxy
tries to be lenient and does this, it complicates matters even more.

Comments ??

Shail

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 22 Jun 2000 16:02:27 +0100

> one ??

If you have state, and the response is not 2xx, then maybe so.

The reason I say this is because I would guess that if this situation
has arisen, then it's probably due to some server responding in a
very tardy fashion; if this is the case, then it's not so unlikely
that any proxies along the route have dropped transaction state, and
thus they'll be forwarded the response statelessly.

One reason against this behaviour is that I guess you could still
be pending results on some branches when you receive a different
final response on a branch that was marked as done.  This probably
would tend to indicate that a downstream server is very ill, however.

Of course, if the response is to an INVITE, you really should ACK
if it's non-2xx class...

> I guess, dropping 200 response is not good, but it is very
> final response.

I don't see that it's any less likely than receiving any other
different response.

> If the proxy decides to forward all 200 responses

How so?  If the proxy still has state on the transaction, then the
branch will either be done or it won't.  Forwarding 2xx class
upstream in a stateless fashion doesn't really complicate this;
you just set the boolean unconditionally. &:)

> tries to be lenient and does this, it complicates matters even more.

I can see ambiguity arising with ACKs...is there anything else?

 - Jo.

---

From: Shail Bhatnagar <[email-masked]>
Date: Thu, 22 Jun 2000 12:16:54 -0400

I am not sure if a proxy should forward a retransmitted 200 OK to
a non-INVITE request. Request retransmission by the upstream ua/proxy
will take care of it. The first 200 OK may have already reached
the upstream guy.

---

From: "Jo Hornsby" <[email-masked]>
Date: Thu, 22 Jun 2000 17:34:36 +0100

> will take care of it. The first 200 OK may have already reached

Interesting point -- I'd missed that.  (Although I guess all it
implies is that there will be some extra message transmissions.)

So I guess we look to the tag to distinguish response retransmissions?
But if the tag is missing...

Oh dear.

 - Jo.

---

From: Igor Slepchin <[email-masked]>
Date: Thu, 22 Jun 2000 14:30:45 -0400

> will take care of it. The first 200 OK may have already reached

No, it should not. Responses to non-INVITEs are only retransmitted upon
request retransmissions. See 10.4.1 for details.

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 01:46:17 -0400

Igor is correct. Handling of non-INVITE is much simpler. You can (and
MUST) only ever return a single response upstream. This is in contrast
to INVITE where you can (and SHOULD/MUST (not sure which)) forward all
200 OKs you receive. Forwarding multiple 200 OK for non-INVITE doesn't
work because of the lack of ACK; reliability of responses for non-INVITE
is guaranteed by request retransmissions. So, when a request
retransmission arrives, which response do you send? No way to know, and
thus no way to guarantee reliability. For INVITE, each final response
has its own retransmissions and its own acknowledgement with ACK. As a
result, reliability for multiple 200 OK for INVITE works.

> branch state gets kind of messy.

Here is the scenario where you could get a 200 OK after a non-200 OK
response. Proxy A sends INVITE to B. B forks, and then times out, never
getting any responses. So, it sends CANCEL and also sends a 408 response
upstream. Now, after that CANCEL, a 200 OK arrives. Its then forwarded
upstream also. Voila. A now gets a 408 followed by 200 OK.

As Jo has pointed out, forwarding the additional 200 OK upstream is not
hard.

-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: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Jo Hornsby" <[email-masked]>
Date: Fri, 23 Jun 2000 10:45:34 +0100

> MUST) only ever return a single response upstream.

Is this explicitly documented anywhere -- have I missed it?  The
only forking documentation I'm aware of is 12.4, and that's specific
to INVITEs.

If you fork REGISTERs (I'm not sure why you'd do this -- perhaps
towards some sort of redundancy?), are there any potential
problems with only returning one 200?  The only other request
I can possibly see problems with (because you might get a response
from a UA that ultimately you wouldn't have been interested in)
is OPTIONS.  (Of course, unknown methods are forwarded like
OPTIONS.)

This has actually raised another point.  Upon re-reading of 12.4,
I note that 6xx MUST be forwarded if a 2xx has not been seen.  Is
this true regardless of whether-or-not a different 6xx has already
be forwarded?

 - Jo.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Jun 2000 10:15:34 -0400

> only forking documentation I'm aware of is 12.4, and that's specific

Hmmm; I somehow thought the code handled this case as well, but perhaps
not.

The behavior is more or less identical, excepting you forward only one
200 OK response upstream if more than one come.

> problems with only returning one 200?

If all registrars receiving the REGISTER are identical (in the sense
that they maintain a shared database of registrations), receiving only
one 200 OK is just fine, and the right thing. If they were different, it
would anyway be confusing... if the responses contained different
Contacts, which ones are actually in place in which servers?

> this true regardless of whether-or-not a different 6xx has already

No; you forward a single 600 only. 

-Jonathan R.