The proxy is required to forward all 1xx & 2xx responses from the UAS to the
UAC. The proxy is required to pick the "best" 3xx/4xx/5xx/6xx response
(non-2xx final response). However, if the proxy has already sent a 2xx, it
just eats any non-2xx final response it gets (after sending an ACK to UAS
the response came from). The proxy is required to send CANCEL on all the
other branches when it gets a 2xx, but the CANCEL and the final response
from the UAS may cross on the wire, so the proxy needs to be ready to
receive and ACK the non-2xx ones (It must forward the 2xx ones to the UAC).

Multiple dialogs may be established at the UAC if 1xx responses (with
To-tags) are received from multiple UASs. Multiple dialogs may also be
established if multiple 2xx responses are received. The UAC is free to
continue those (2xx) dialogs or send BYE on the ones it does not want.

If the UAC has multiple dialogs established by 1xx responses when it
receives a non-2xx final response, it must consider the transaction
completed (i.e. Completed state of the INVITE client transaction FSM) and
all of the dialogs terminated. The non-2xx final response may have a To-tag
identifying a specific dialog, but UAC will not receive another response for
the other dialogs because the proxy waited for all of the branches to
respond (with a non-2xx final response) before sending the best non-2xx
final response.

Based on table 3 (Summary of Header fields), and on the text in section
16.6, the proxy is not allowed to modify the To header in the "best" non-2xx
final response it sends to the UAC. Therefore, the proxy is not allowed to
add a tag, or change the tag in the response.

As far as identifying ACKs, since in this case, the proxy sent only one
final response, it will get back only one ACK from the UAC, whose To header
will be identical to that in the response sent to the UAC.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[EMAIL PROTECTED]

----- Original Message -----
From: "Wei BJ Lu" <[EMAIL PROTECTED]>
To: "Arunachalam Venkatraman" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, November 16, 2001 12:27 AM
Subject: Re: [Sip-implementors] How does forking proxy handle To Tag in
errorresponse selection?


>
> I do agree with you that the proxy should forward all 2xx responses and
> forward the best one of other final responses according to bis05.
> But I didn't find the UAC should establish only one connection on
receiving
> multiple 2xx responses. Although I know the behaviour of proxy should have
> nothing related to the configuration of UA (whether it enable multiple
> dialogs or not), I still have the doubt.
>
> Or it's wrong for me to think that the UAC could establish connections to
> all answered parties? Although forking can help caller to reach callee
> on multiple contact addresses, only one should be picked establish the
> final communication channel?
>
>
>
>
>
>                     "Arunachalam Venkatraman"
>                     <[EMAIL PROTECTED]>               To:     Wei BJ
Lu/China/IBM@IBMCN
>                     Sent by:                           cc:
<[EMAIL PROTECTED]>
>                     [EMAIL PROTECTED]       Subject:     Re:
[Sip-implementors] How does forking proxy handle To Tag
>                     lumbia.edu                          in errorresponse
selection?
>
>

>                     2001-11-16 12:11
>                     Please respond to
>                     "Arunachalam Venkatraman"
>
>
>
>
>
> That depends on the UAC implementation.
> The UAC may use a user interface to let the caller decide, if it is
capable
> of handling multiple appearances. Otherwise, it can set up the call after
> the first 200 Ok and when a second 200 OK is received it can send BYE
after
> ACKing it.
> I don't understand your reference to the proxy behavior based on UAC
> enabling multiple dialogs. Where is this mentioned?
>
>
> ----- Original Message -----
> From: "Wei BJ Lu" <[EMAIL PROTECTED]>
> To: "A Venkatraman" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Thursday, November 15, 2001 8:37 PM
> Subject: RE: [Sip-implementors] How does forking proxy handle To Tag in
> errorresponse selection?
>
>
> >
> > I have noticed the bis says proxy only forwards 2xx responses. But I
> still
> > have the doubt: If the UAC does not enable multiple dialogs, then what
> > should
> > it do on the arrival of multiple 200 responses?
> >
> > -Lu Wei
> >
> >
> >
> >
> >                     "A Venkatraman"
> >                     <[EMAIL PROTECTED]>               To:     Wei BJ
> Lu/China/IBM@IBMCN, "McMurry, Kathleen"
> >                     Sent by:
> <[EMAIL PROTECTED]>
> >                     [EMAIL PROTECTED]       cc:
> <[EMAIL PROTECTED]>
> >                     lumbia.edu                         Subject:     RE:
> [Sip-implementors] How does forking proxy handle To Tag
> >                                                         in er
> rorresponse
> selection?
> >
> >                     2001-11-16 09:20
> >                     Please respond to "A
> >                     Venkatraman"
> >
> >
> >
> >
> >
> > a. How does a UAC enable multiple dialogs?
> > b. The proxy only forwards all 200 class final responses. See line 2345
> of
> > bis-05 pdf.
> >    Also, see line 2423 which specifies that a proxy should send CANCEL
on
> > all legs that sent a provisonal but no final response.
> >
> > -----Original Message-----
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]]On Behalf Of Wei BJ Lu
> > Sent: Thursday, November 15, 2001 6:58 PM
> > To: McMurry, Kathleen
> > Cc: [EMAIL PROTECTED]
> > Subject: RE: [Sip-implementors] How does forking proxy handle To Tag in
> > er rorresponse selection?
> >
> >
> >
> > I have some doubt on "the proxy should select the best response from the
> > ones it has
> > received and send it to the OUA". I think it it not always true. To my
> > understanding,
> > the behaviour of a forking proxy on receiving final responses should be
> > different
> > under two circumstances:
> >
> >   a. If the UAC does not enable multiple dialogs(call-legs), the proxy
> > should forward
> > the best final response upstream and cancel all the unfinished forking
> > branches.
> >
> >   b. If the UAC enable multiple dialogs, the proxy should forward all
the
> > final
> > responses to the UAC. Since on the UAC's side, different To tag means
> > different dialog.
> > When 180 with To tag u1 and u2 comes, the UAC will create two dialogs.
If
> > the proxy
> > only forward 486(this tag u1) to the UAC, the UAC will only terminate
one
> > dialog and
> > the other dialog will keep ringing.
> >
> > -Lu Wei
> >
> >
> >
> >
> >
> >                     "McMurry, Kathleen"
> >                     <[EMAIL PROTECTED]>        To:     "'Bob
> > Penfield'" <[EMAIL PROTECTED]>, A Venkatraman
> >                     Sent by:
> > <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
> >                     [EMAIL PROTECTED]       cc:
> >                     lumbia.edu                         Subject:     RE:
> > [Sip-implementors] How does forking proxy handle To Tag
> >                                                         in er  ror
> response
> > selection?
> >
> >                     2001-11-16 04:02
> >                     Please respond to "McMurry,
> >                     Kathleen"
> >
> >
> >
> >
> >
> >
> >
> > >-----Original Message-----
> > >From: Bob Penfield [mailto:[EMAIL PROTECTED]]
> > >Sent: Thursday, November 15, 2001 1:19 PM
> > >To: McMurry, Kathleen; A Venkatraman; [EMAIL PROTECTED]
> > >Subject: Re: [Sip-implementors] How does forking proxy handle To Tag in
> > >er ror response selection?
> >
> >
> > >>
> > >> >> Suppose a proxy forks a request from UAC to uas1, uas2,
> > >> >> and each returns a 18x, with tag u1 and u2 respectively, which are
> > >> >> forwarded, as is, to UAC,
> > >> >> and then uas1 returns a 486 with tag u1 and uas2 returns 500 with
> tag
> > u2
> > >> >> Proxy picks best response 486 to return to UAC.
> > >> >>
> > >> >> Question:
> > >> >> Will the TO tag in the 486 reponse be u1? Or, will there be no TO
> > tag.
> > >> >> Is this implementation specific or does the protocol specify this
> > >> >anywhere?
> > >> >>
> > >> >Based on section 16.6 on bis-05, the tag received in the response is
> > >> >preserved when the selected response is forwarded to the UAC.
> > Therefore,
> > it
> > >> >would be u1 for your example. The proxy is not allowed to modify the
> To
> > >> >header in the forwarded response.
> > >>
> > >> A 2xx response is the only type of response that is truly "forwarded"
> by
> > >the
> > >> proxy.  Any non-2xx response is really hop by hop.  Therefore, in
your
> > >> example, the proxy will add its own To tag when it responds to the
> UAC.
> > >> Niether u1 or u2 would be used.
> >
> > >Section 16.6 of bis-05 explicitly forbids the proxy from adding its own
> > tag.
> > >It is not a UAS in this case. The proxy is suppose to select the best
> > >response from the ones it has received and forward that response to the
> > UAC.
> >
> >
> > I agree that the proxy should select the best response from the ones it
> has
> > received and send it to the OUA.  I also agree that the spec. does not
> > clarify the two different cases well.
> >
> > In the case of a 2xx response, the proxy forwards the response to the
OUA
> > leaving the To tag alone.  For a non-2xx response however, the To tag is
> > used to match the corresponding ACK for each hop.  Therefore, when the
> > non-2xx response is received by the proxy, it should ACK the UAS with
the
> > To
> > tag that was added by the UAS.  But when the proxy sends the response to
> > the
> > UAC, the proxy should use a To tag that it generates so that it can
> > determine that the corresponding ACK is meant for the proxy and should
> not
> > be forwarded.
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> >
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
> >
> >
> >
> > _______________________________________________
> > Sip-implementors mailing list
> > [EMAIL PROTECTED]
> > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
> >
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
>
> _______________________________________________
> Sip-implementors mailing list
> [EMAIL PROTECTED]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to