Cseq is for sequencing of Requests in existing dialog. So as along as new transaction follows this, I don't see any issue in UAC. UAS may have policy to limit number of outstanding transaction but that is out of SIP. Any comment ?
-----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Stephen Paterson Sent: Tuesday, May 05, 2009 3:22 PM To: Iñaki Baz Castillo Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Multiple concurrent transactions But hidden away in 12.2.2 is: If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. So, if the first hadn't arrived yet, the second should be accepted (admittedly the first would then be out of order when it did arrive but that's a different matter). Steve > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu > [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of > Iñaki Baz Castillo > Sent: 05 May 2009 10:43 > Cc: sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] Multiple concurrent transactions > > 2009/5/5 Iñaki Baz Castillo <i...@aliax.net>: > > 2009/5/5 Stephen Paterson <stephen.pater...@aculab.com>: > >> Hi all, > >> > >> Just a quick one to confirm something. > >> Is it perfectly reasonable to have multiple concurrent > transactions > >> of the same method on a single dialog? I.e. can you send a second > >> INFO (for example, could be any non-INVITE) before receipt of a > >> response for a previous INFO on the same dialog? I'm talking about > >> separate transactions, not retransmissions. > >> > >> I'm fairly sure you can, I just can't find any text to support it. > > > > No, it's no tpossible and the UAS shoule reply "491 Request > Pending": > > http://tools.ietf.org/html/rfc3261#section-21.4.27 > > To extend it, imagine UAC sends an INFO (in-dialog request) with CSeq > 101. > Before receiving a reply for that INFO, the UAC sends a new one INFO > (or any request) with CSeq 102. How can know the UAC that the previous > INFO arrived? If it didn't arrive, then the UAS would discard the new > request since CSeq is incorrect (UAS expects 101 instead of 102). > > -- > 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 > Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales) P Please consider the environment and don't print this e-mail unless you really need to _______________________________________________ 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
