> > 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... John Hearty Level3 > -----Original Message----- > From: Adam Roach [mailto:adam@;dynamicsoft.com] > Sent: Tuesday, November 05, 2002 12:16 PM > To: '[EMAIL PROTECTED]'; Adam Roach; sip-implementors (E-mail) > Subject: RE: [Sip-implementors] Questions about Dialogs > > > > 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. > > > 1b) How does a 481 response to an INVITE > > over a subscription dialog effect the > > subscription dialog? > > Consistency dictates that it would remove the subscription. > This should be clarified. I've opened a bug. > > > Can the targets also be refreshed by a > > new Contact supplied during the following: > > a) SUBSCRIBE's 2xx response? > > Yes > > > b) NOTIFY? > > Yes > > > c) NOTIFY's 2xx response? > > Yes > > > d) Future extension drafts which define > > target-refreshing-requests for a > > subscription-dialog? > > Yes > > > Over an invite-dialog, can two SUBSCRIBE's > > successfully occur in opposite directions > > at the same time? > > Yes. > > > Should the Contact of > > the 2xx or SUBSCRIBE be used for the > > target refresh? > > Whichever you receive last. > > > Should a 2xx invite response Contact take > > precedence over a just received SUBSCRIBE? > > Depends on which you receive last. > > > How do we know which was actually sent > > first by the called party? > > Should a 2xx INVITE response Contact take > precedence over a just received INVITE? > How do we know which was actually sent > first by the called party? > It's the same question. > > > Without timestamping all requests and > > responses, one solution for all > > these race conditions is to immediately > > try multiple locations to resolve the > > ambiguity. > > Or you could just refrain from retargeting > ever few milliseconds like you're hopped up on > PCP. :) > > To be fair, there are some corner cases that > can pop up. As I point out above with the > INVITE/INVITE response problem above, though, > these dialog handling problems are problems > with the base spec, not the extensions. We should > probably have a discussion about this particular > race condition on the SIP list. > > /a > _______________________________________________ > 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
