> > > > 1a) It makes the presence of a To-tag no > > > > longer sufficient enough to distinguish > > > > an invite from re-invite. > > > > > > In my experience, that's never really been all that useful. > > > You always have session state for ongoing sessions; you can > > > use its absence or presence to determine whether an INVITE > > > is a re-INVITE. > > > > This statement sounds like it might cause problems for the > > case of the > > crashed and restarted UA using the presence of a To tag and > > any Record-Route > > header included to reconstitute state from a re-Invite... > > How? If it's crashed, it will have no dialog in addition to having > no session state. It's trivially distinguishable. > > Can you outline a failure scenario? > > /a >
For example, say there is an MGC talking SIP on one side and MGCP or megaco to some MGs. With the To tag, it would know it has some session already up at a MG, so it won't go through the normal steps to select a MG and send it setup messages. Otherwise there could be two MGs streaming RTP to the UA at the other end which often causes major media quality problems at the receiving UA. Using the To tag, the MGC would simply reconstitute the state and leave the existing MG to continue handling the session. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
