One real life scenario where concurrent transactions from UA makes sense.

1. UA has initiated a SUBSCRIBE transaction to refresh a subscription,
but it has not yet received the final response for that transaction.
2. UA is being shutdown, hence it initiates an UNSUBSCRIBE immediately
without waiting for the previous SUBSCRIBE transaction to complete.
This should be perfectly fine , since the UA's ultimate aim is to
unsubscribe (no issues due to out of order requests being received by
UAS)

If I am building a SIP stack, I will *not* assume that concurrent
transactions of same method are not allowed.

Thanks
Pandu

On Tue, May 5, 2009 at 4:45 PM, Iñaki Baz Castillo <i...@aliax.net> wrote:
> 2009/5/5 Stephen Paterson <stephen.pater...@aculab.com>:
>> OK, imagine UA1 establishes a dialog with UA2.
>> UA2 then sends two INFOs which arrive out of order. UA1's current remote 
>> CSeq will be 0. The CSeq in the first INFO it receives can be anything so 
>> how would the UAS know?
>
> This is exaclty the reason to avoid this behaviour *in the UAC* (and
> this is what I say).
>
>
>> Also, even when only a single request is sent and the UAS does have a remote 
>> CSeq a proxy may still attempt to authenticate the request in which case the 
>> UAC would re-submit the request with an incremented CSeq. The UAS would not 
>> have seen the original request, would not know that it had been 
>> authenticated and any UAS insisting on an increase of one and one only would 
>> reject a perfectly legitimate, in order, request.
>
> Initially I was wrong when said that UAS would reject a request since
> it expects "CSeq 101" but "CSeq 102" arrives, I was wrong on it.
>
>
>
>
> --
> Iñaki Baz Castillo
> <i...@aliax.net>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors@lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to