Good afternoon, I'm currently trying to implement dialog handling inside the UAC core and are struggling with some details on the creation/destruction of dialog states especially when the initial INVITE request is forked and mutliple 200 responses are returned. I hope you can help me shed some light on the following questions (and correct me if I got something wrong with the procedures), any replies are very much appreciated.
1) RFC 3261, sec. 13.2.2.1 states that only 1xx responses with a To-tag are subject to matching with existing dialogs and would spawn a new one when no match is found (except 100 responses, as stated in 12.1). However, sec. 12.1.2 allows responses to contain no To-tag in case they come from an "old client" (i. e., implemented according to RFC 2543) and that the tag should be treated as a null value (an empty string, I suppose?). How is the UAC core supposed to differentiate between illegal responses from "new clients" which do not include a To-tag (as they are declared invalid in sec. 8.2.6.2) and valid responses from old clients? Or is the rule in 13 supposed to overrule the general behaviour in 12 and any response without To-tag is simply ignored by the UAC core? 2) Suppose the initial INVITE is forked and the recipients return 200 responses with the first response arriving at the UAC containing an unacceptable offer/answer, forcing the UAC to create a dialog, send an ACK and terminate the dialog immediately with a BYE. Since both the transaction and dialog are gone, subsequent 200 responses would be treated as stray responses and create new dialogs because their is no match on the dialog ID in the UAC core. But what if the subsequent 200 responses are actually retransmissions of the first response (because ACK got lost or whatever) - wouldn't they, according to the rules in 13 lead to the creation of an unnecessary dialog because they do not match on an existing one? I think the same problem might also arise whenever a stray 200 response is received which does not match an existing dialog (e. g. call-id or from-tag has bogus values), even when no initial INVITE was actually sent (I couldn't find any rules in the RFC which require checking if their is actually a call establishment ongoing when a stray 200 is received - how would the UAC core match responses anyway to the call, by using the From-tag and call-ID?). I'm aware that these issues are addressed in the draft "Correct transaction handling for 200 responses to Session Initiation Protocol INVITE requests" but they do focus on the UAS and make no corrections to the respective parts in the RFC I mentioned above. Furthermore, I would like to know if these issues can be addressed with a "vanilla" SIP client without the need to implement the fix. 3) What is the best way to react on multiple dialogs created by responses on a forked INVITE? Let the user choose which dialog to keep or keep only the first one and automatically terminate subsequent dialogs with BYE? I guess, this is an implementation issue and not in the scope of the standard but I'd like to hear other opinions on this matter. 4) What exactly happens when there is no SDP offer or answer in any 1xx/200 response to an INVITE (or the SDP is invalid)? I couldn't find any hint on this in the RFC, but my guess is that for a missing answer an ACK is sent followed by termination with BYE (just like for an unacceptable answer) and for a missing offer, a dummy answer (with no m-Lines?) is sent in ACK followed with BYE. Best regards, Peter _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
