Dialog, as I understand, represents a call leg. Hence, multiple 2xx responses do represent multiple dialogs.
I am not clear, whether a 2xx response reaching back the uac will only form a dialog. I feel, any 2xx response whether or not it reaches the uac, represents a separate call-leg. Even if only reaching of 2xx at the uac constitutes a dialog, then also, multiple 2xx can reach the uac. How? Forking proxy in general, will forward only one 2x response. But suppose, after forking the INVITE, the proxy crashes and reboots, then what. In that case, the proxy will simply forward all the responses back to the uac(based on the via) Thus multiple 2xx end up at the uac. I need a clarification here. Is 2xx delivery at the uac must, to constitute a dialog. I feel, irrespective of its delivery, 2xx should constitute a dialog. After all it is representing a different call-leg. Regards, -Manish S. Jalan On Fri, 14 Dec 2001 Arun Patra wrote : > Hi, > I have following question.Just look into following > lines which are from > 2543bis.05 > > ----page-45, section 13.1, last paragraph--- > A 2xx response to an INVITE establishes a session, and > it also creates a > dialog between the UA that issued the INVITE and the UA > that generated the > 2xx response. Therefore, when > multiple 2xx responses are > received from different remote UAs (because the INVITE > forked), each 2xx > establishes a > different dialog. > All these dialogs are part of the same call. > ----------------------- > > In above why different dialogs for forking case. After > proxy fork a request > received from a UAC, the first 2xx response it got from > any of those forked > endpoints is the valid one. Other 2xx responses > received later than first > 2xx assumed to be in-valid and proxy sends a CANCEL to > each forked endpoint > other than the first one. If proxy is call-statefull > all the dialogs created > for that call are maintained in proxy level. > So multiple 2xx will never reach to or tor UAC. > Then why different > dialogs for same call at UAC in a forking scenario? > Ofcourse if UAC forked the request, then it has to. But > should UAC fork a > message? > > p.s. Apologies if this topic already discussed. > > regards > Arun > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implem- > entors _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
