First of all, many thanks for your answers. Regarding point 2: Keeping the transaction state would essentially emulate the Sparks-INVITE-fix, and keeping the data of terminated dialogs wouldn't help when stray/forking responses arrive even later than 64*T1 (or completely unconnected to a call) or am I missing something? In case there is really no clean solution without the fix, I think about following compromise: the UAC core never creates new dialogs when stray 200 responses are received but only sends an ACK for a matching dialog if one still exists (dialog data is cleaned after 64*T1 after termination via BYE). Could this approach have any unfortunate impact besides disabling dialogs for forking responses (which can be enabled again when using the Sparks fix)?
Best regards. Peter On Wed, Jan 12, 2011 at 2:21 PM, Kevin P. Fleming <[email protected]>wrote: > 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
