Looks to me application logic rather than SIP transaction logic. I completely agree that at times, it does not make sense to have multiple outstanding transactions but then RFC does not stop doing this. Thanks for clarification Inaki.
-----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: Tuesday, May 05, 2009 3:57 PM Cc: sip-implementors@lists.cs.columbia.edu Subject: Re: [Sip-implementors] Multiple concurrent transactions 2009/5/5 Rastogi, Vipul (Vipul) <vrast...@avaya.com>: > That is correct but here we are mixing network behavior with UAC behavior. > UAC can send such MESSAGES, 3261 does not restrict UAC. Imagine a UAC wanting to send the following DTMF sequence to a GW (UAS): 1 2 (yes, I know that INFO is not estandarized for DTMF's... but you understand me). Imagine that the UAC sends INFO "1" (CSeq 101) and before receiving a reply it also sends INFO "2" (CSeq 102). Due to network congestion (or whatever) the first INFO is lost. INFO "2" arrives to GW (CSeq 102). UAC retransmists INFO "1". This arrives now to GW which rejects it due to invalid CSeq (101 < 102). So, finally UAC has sent DTMF 2 before 1, breaking the desired DTMF sequence. Does it make sense? Yes, maybe RFC 3261 doesn't prohibit it *explicitely*, but IMHO it makes a lot of sense to avoid such UAC behaviour, don't you agree? Regards. -- 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
