Subject: Re: [SIP] multiple responses ??

From: Bertil Engelholm <[email-masked]>
Date: Tue, 24 Oct 2000 12:40:44 +0200

Jonathan Rosenberg wrote:
> 
> 
> 
> > -----Original Message-----
> > From: Bertil Engelholm [mailto:[email-masked]]
> > Sent: Monday, October 23, 2000 12:20 PM
> > To: [email-masked]
> > Subject: [SIP] multiple responses ??
> >
> >
> > Hi,
> >
> > I have some questions regarding the possibility to forward
> > best vs. forward all responses.
> 
> Forward all simply does not work.
> 
> A proxy can forward one or more 200 responses (and indeed, really must
> forward all of them), since those are ACKed end to end. Non-200s are ACKed
> hop by hop. A proxy or client receiving multiple non-200 responses to the
> same request will have no way to distinguish them, and the state machines
> currently defined would not work.

OK, that simplifies things a bit.

> 
> >
> > First of all I wonder if this is not a function that should
> > be decided by the UA e.g. by setting a special header ?
> 
> Caller preferences addresses some simple cases where a UAC can request
> specific service from proxies. But, since forward-all-responses doesn't
> work, having a caller prefs value for it doesn't seem that useful.

Maybe I used the wrong term here. Forward all seems not allowed
as you explained above. But there are still two different behaviours.
Either the proxy only forwards the best response or it forwards
all 200 responses. The problem I see is that a UA don't know if
it's going to receive one or several 200 responses. So it has
to be prepared to always receive several 200 responses. If you
MUST set a header to get all 200 responses instead of only the
best a UA can decide that it will not handle that case (by not 
setting the header).

> 
> > It's the UA (the User) that knows if he like to get all
> > responses and choose himself or let the network choose the
> > best response. Why should each server take this decision ?
> 
> We did it this way (forwarding only the best response) so that it would
> scale and work in a reasonable fashion.
> 
> >
> > Secondly I have a question regarding the proxy behaviour in
> > the following case.
> >
> >             ------      ------
> >             |    |----->| P2 |---->????
> > ------      |    |      ------
> > | Ca |----->| P1 |
> > ------      |    |      ------
> >             |    |----->| P3 |---->????
> >             ------      ------
> >
> > If Ca calls someone at P1 which forks the call to P2 and P3 how
> > should P1 behave in the following cases if it has the policy to
> > fork the best response.
> >
> > If P2 (or someone behind P2) have the policy to fork all responses
> > it means that P1 can get several final responses.
> 
> Only multiple 200.
> 
> > Which of these
> > reponses should be used in the best choice by P1 ?
> > Only the first one that happens to arrive ?
> > Everyone that arrives before you get a response from P3 ?
> 
> Beyond 200s, picking which is the best of the non-200 responses is defined
> by the spec (600, then 300, then 400, then 500 in that order). However, a
> proxy could choose an alternate definition of best amongst the non-200 final
> responses it gets, since there are no interoperability issues which choosing
> an alternate algorithm.
> 
> >
> > What should be done with the rest of the responses that might drop
> > in after you have sent your best response back ?
> 
> There should only ever be 200s, which are forwarded upstream. Anything else
> would be an error.
> 
> >
> > You could actually have received an ACK back from Ca when another
> > response drops in from P2. What to do in this case ?
> 
> Won't happen under correct operating conditions.

I'm not shure I understand why this can't happen. If P2
can send several 200 responses back to P1 I guess they can
come at any time (depending on when someone answers at the
other end). So lets say that the first 200 that is received
from P2 is choosen as the best result and sent back to Ca.
Ca now ACK this OK to P1 because Ca don't know it will
get more 200 responses later on. P1 sends the ACK to P2. Another
UA behind P2 somewhere now answers the same call which leads
to a second 200 response from P2 to P1. And this second 
200 response will belong to another CALL-LEG since the TO-tag 
is different. Maybe I have misunderstood something completly
but this is how we have read the specification. If this
can't happen it would simplify things but I don't understand
why it can't happen.

> 
> -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
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Bertil Engelholm
AXE Research and Development        voice : +46 8 727 3499
SIP Security                        Fax   : +46 8 647 8276
S-126 25 Stockholm Sweden           E-mail:
[email-masked]

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

---

From: "Hisham Khartabil" <[email-masked]>
Date: Wed, 25 Oct 2000 09:09:39 +0300

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Bertil Engelholm
> Sent: 24. lokakuuta 2000 13:41
> To: [email-masked]
> Cc: Jonathan Rosenberg
> Subject: Re: [SIP] multiple responses ??
>
>

You must not set any header. You will get all 200 responses.  If you don't
want to accept the second one, ACK it then send a BYE (then wait for 200OK
for BYE)

> can't happen it would simplify things but I don't understand

This can happen.  You do exactly what i described above.

Regards,
Hisham