Thanks for the response. See comments below.
Vijay Gurbani wrote:
> 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
According to bis-02, "A transaction is identified by the CSeq sequence
number within a single call leg" (Section 1.4). In view of Jonathan's
recent comments, this sentence will be modified to include Request-URI
and top Via. Nevertheless, I take it to mean that different call legs
can not share same transaction. And if you further follow the rule that
all transactions must be completed independently, the transaction
related to tag=1 in my example must be allowed to complete.
I am not disagreeing with your proposed solution to my question, i.e.,
UA0 does nothing regarding the 180 with tag=1. But I can't find any text
to support it.
> 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.
Regards,
Shan Lu
NexTone Communications
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
