> 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 am assuming that you have read RFC 5407 "Example Call Flows of Race Conditions" (which gives much better state machines than RFC 3261) and RFC 6026 "Correct Transaction Handling for 2xx Responses". Of course, the way to deal with these is not to read them as algorithms to be copied literally but as discussions of the protocol and its intended operation. > 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? Presumably, a response without a to-tag is interpreted as a response from an 2543 client rather than as an error. But it practice, it does not matter, as there aren't any 2543 UAs in the wild any more. > 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. Clearly, the record of the dialog must be retained long enough that any retransmissions of responses will be seen as such. This stems from the principle that the detection and handling of retransmissions is "at a lower level" of the implementation than the creating and destruction of dialogs -- since the retransmission of the ACK in response to the retransmitted 200 is done entirely at the lower level, the upper level never sees the 200. You write later: > In case there is really no clean solution without the fix, Yes, there is really no clean solution without fixing the admitted problem in 3261. But why is that surprising? The error is 3261 is known, the fix is published, one assumes that any sane implementation would incorporate the fix -- and that any implementation that did not incorporate the fix would malfunction. > when stray/forking responses arrive even later than 64*T1 (or > completely unconnected to a call) I expect that a UA would discard such responses. In any case, they are unlikely and due to some severe problem elsewhere in the network. > 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. For ordinary phones, I think the usual choice is to give the user the first dialog that is established, or at least, the first one that doesn't have to be immediately terminated. Actually, this is a question of what provides the best user interface, not a protocol question. > 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. That's probably best -- maintain the transaction structure, but terminate the dialog as soon as possible. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
