Hi Vijay,
But why would the two responses clash in a normal scenario, they would be
queued. so UA may not get another 2xx response.
Also UA0 sends the INVITE message to PS and it expects PS to fork the
requests. So why would you say that UA0 will not know what PS is going to
do?
and since UA2 has sent a final response to UA0, we need not even consider
media capabilites.
Regards
Ranjit
Mascon Communication Technologies
http://www.masconit.com
----- Original Message -----
From: Vijay Gurbani <[EMAIL PROTECTED]>
To: Shan Lu <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, May 04, 2001 3:35 PM
Subject: Re: [Sip-implementors] Forking question
Shan Lu wrote:
>
> Hi,
>
> Have the following question on forking. The configuration is simple: UA0
> sends INVITE which is forked by proxy server PS to two different UAs:
> UA1 and UA2. The message flow is like this:
>
> 1. UA0 initiates INVITE
> 2. PS forks INVITE to UA1 and UA2
> 3. Both UA1 and UA2 responds with 180. UA1 has To tag=1 and UA2 has To
> tag=2. These two responses are forwarded by PS back to UA0
> 4. UA1 sends 4xx or 6xx response. PS ACKs the response.
> 5. UA2 sends 200 response. PS forwards 200 to UA0.
> 6. UA0 ACKs the 200 response. The ACK is forwarded by PS to UA2.
> 7. UA0 CANCELs 180 to UA1. Because UA0 doesn't know UA1 has already sent
> final response. And let's further assume that PS does not record-route
> and hence does not see the CANCEL.
> 8. UA1 responds with 481 Transaction Does Not Exist to the CANCEL from
> UA0.
>
> Question: what is UA0 supposed to do? It still hasn't received final
> response for tag=1. Does it wait for the transaction to time out? What
> should be the right behavior?
Shan Lu:
The crucial distinction here is drawing a line between a transaction and
call legs. UA0 has one transaction outstanding -- the INVITE. The fact
that PS forked is limited significance to UA0's processing of its INVITE
transaction (in fact, UA0 does not even know if the downstream server will
fork or not). If UA0 gets multiple 1xx responses, each of which has a
different tag in the To, it should not create a new transaction for each;
all of these call legs belong to the same INVITE transaction.
As to what is UA0 supposed to do when it gets a 2xx for one call leg and
has another call leg outstanding -- it should do its normal processing,
namely, the 2xx it got balanced out the INVITE transaction, so it will send
an ACK to the proxy (if PS R-R) or the UAS.
It could very well be that UA0 gets another 2xx (if the CANCEL from the
proxy and the 2xx from UA2 crossed each other on the wire). In that case,
the 2xx is yet another call leg belonging to the same transaction and MUST
be ACK'ed. Further processing of that call leg depends on the media
capabilities of the UAC; for instance, if it cannot support simultaneous
calls, it should send out a BYE to the second call leg.
Note that in this particular case, UA0 will never get a non-2xx on the
second call leg; that is because its downstream proxy will handle a non-2xx
response with an ACK. In this particular example, the downstream proxy
had already send a 2xx upstream, so it will not send another non-2xx up-
stream.
"Ranjit Avasarala" <[EMAIL PROTECTED]> wrote:
> Hi Shan,
>
> Since UA0 has not yet received the final response from UA1 , it should
> wait for certain time before timing out. Also when
I believe that this is the proxy's job, since it forked the request to UA1.
> Also since UA1 has sent the final response for UA0 it will no longer store
> that transaction. So it will respond with 481 .
>
> But I feel PS should record - route and foward the final response of UA1
> to UA0 . so that UA0 knows about the failure.
I don't quite understand how R-R helps in forwarding responses? Responses
follow the Via list, not R-R.
Gratituous R-R on behalf of proxies should be minimized. R-R, in general,
should only be used when absolutely needed (a proxy may reserve some
resources that have to be freed, or a proxy may be providing services
triggered off getting a BYE, for instance).
Best regards,
- vijay
--
Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org}
Internet Software and eServices Group
Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413
Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
