Subject: RE: [SIP] multiple responses ??

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 7 Nov 2000 03:48:01 -0500

Hisham is correct on both counts.

-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

> -----Original Message-----
> From: Hisham Khartabil [mailto:[email-masked]]
> Sent: Wednesday, October 25, 2000 2:10 AM
> To: Bertil Engelholm; [email-masked]
> Cc: Jonathan Rosenberg
> Subject: RE: [SIP] multiple responses ??
> 
> 
> 
> 
> > -----Original Message-----
> > 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 ??
> >
> >
> > 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).
> 
> 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)
> 
> >
> >
> > >
> > > > 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.
> 
> This can happen.  You do exactly what i described above.
> 
> Regards,
> Hisham
> 
> >
> > >
> > > -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
> 

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