>> If it didn't arrive, then the UAS would discard the new >> request since CSeq is incorrect (UAS expects 101 instead of 102).
I think UAS expects a Cseq that is simply greater (not next number) than the Cseq received in a previous request from UAC. So it will accept 102, 103 etc.. On Tue, May 5, 2009 at 3:13 PM, Iñaki Baz Castillo <i...@aliax.net> wrote: > 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
