> 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
