Brett Tate wrote:
Another interesting case that I haven't seen discussed is reusing a dialog for a second INVITE. In theory this is possible. After a first INVITE completes with a BYE, if the dialog is being kept open by some other usage, then you should be able to send another INVITE (which would I guess not be considered a reINVITE) and establish a new call with the same endpoint. It should alert again, negotiate new media unrelated to the old call, etc.
But I don't think it is very likely that this would work with many UAs if you tried it.
Hi Paul,
We discussed this a little around a year ago during the following GRUU thread.
http://www1.ietf.org/mail-archive/web/sip/current/msg08961.html
http://www1.ietf.org/mail-archive/web/sip/current/msg08966.html
However because of GRUU, I don't recall anyone resolving the following two issues associated dialog re-use.
1) Concerning the above example of an invite after bye over a subscription's dialog, how can a re-invite audit
What is a reinvite *audit*?
> be distinguished from a request to
originate a new call? This is likely only a problem during race conditions and failure situations.
There may well be race conditions whereby one side thinks this is a reinvite while the other side thinks it is an invite.
Presumably we could clarify the ambiguities if we thought it was important. But I don't think this is considered a desirable use case, so it probably won't be worked on.
2) How can the subscriber indicate within a notify response that the subscription is unknown/terminated but the dialog is active and should remain active? (i.e. a 481 can't be sent)
Good question. I don't know.
But would this ever come up? If this was detected during what the sender thought was a resubscribe, then the UAS would just consider it a new subscribe and it would succeed or fail on its own merits. I guess you could imagine it happening on a NOTIFY - the notifier thinks there is a subscription, while the notifyee agrees there is a dialog but not a subscription.
Fundamentally we have a problem because the meaning of 481 is ambiguous. Once (2543) it was defined as "Call Leg/Transaction Does Not Exist", now (3261) it is formally called "Call/Transaction Does Not Exist", but has been redefined to mean "the UAS received a request that does not match any existing dialog or transaction". (And in 3265 it is defined as "Subscriptin does not exist".) But clearly there is still a notion of dialog usages (invite and subscribe) that can exist or not within a dialog, so it is really overloaded three ways:
- dialog does not exist
- invite usage does not exist
- subscribe usage does not exist
- transaction does not exist
The case where it means "transaction does not exist" can be deduced from context (cancel response). And the distinction between invite usage and subscribe usage can also be deduced from context. But the distinction between {invite/subscribe} usage does not exist, and dialog does not exist cannot be deduced from context.
This *ought* to be fixed. But I sense that people will continue to just consider multiple usages in a dialog to be deprecated and consider that to be a sufficient solution.
Paul _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
