----- Original Message ----- From: "Manish S. Jalan" <[EMAIL PROTECTED]>
> > 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. > A call-leg is a dialog. The reason the term was changed is that dialog is more generic and can be used for other scenarios like subscription. The relationship between a client using SUBSCRIBE and the server that receives it is not a call, so call-leg is not the right term. Thus we now have the term dialog which represents the relationship/connect between a UAC and a UAS. > 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. A proxy is required to forward all 2xx responses it receives. This will occur if the second 2xx is sent from the UAC before it receives the CANCEL from the proxy. > 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 > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
