> 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?
Since you mentioned INFO, see section 4.7 of draft-ietf-sip-info-events-03 since it discusses your question. It is permitted unless there is something forbidding it. However it can trigger failure responses and potential race condition ambiguities. RFC 3261 section 12.2.2 indicates to return 500 upon receiving a request with lower cseq. This helps indentify when requests potentially received out of order; unfortunately the 500 can also be used for other things. Concerning requests, the specifications (such as RFC 3311) allow UAS to return failure responses such as 500 with Retry-After or 491 when needed and/or appropriate. Concerning responses, RFC 3262 has special consideration concerning 100rel to allow dropping misordered 1xx responses and require queuing INVITE 2xx at UAS when appropriate. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
