On 01/12/2011 05:31 AM, Peter Krebs wrote: > 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.
When your UAC terminates a transaction or a dialog, it needs to keep the information about that around in memory for reasonable period of time so that it can properly handle receipt of retransmitted responses or late requests. Many implementations will keep this information around for 64*T1, since that is the amount of time that UAs are supposed to allow for critical messages to receive responses. > 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. It is indeed very implementation specific; in Asterisk, the second (and further) dialogs are treated as you suggest... the 200 OK is ACKed, and then a BYE is immediately sent. > 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 seems reasonable to me, although you will likely not see these situations very often... it's good to be prepared though :-) -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: [email protected] Check us out at www.digium.com & www.asterisk.org _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
