Balu,
While reusing dialogs is now unpopular, there is no reason why you could not establish a 2nd subscription within an existing dialog, using a new event id if the event type is the same as a prior subscription.
You can do this *before* the old subscription is terminated, though there likely is no good reason why you would want to. (Well, you might be able to cook up a reason to have two subscriptions to the same event package with different filters. But that seems like a stretch.)
You can of course also do it *after* the first subscription is terminated. BUT that will only work if the dialog still exists. Dialogs are supposed to be reference counted, so that they go away when the last usage terminates. So if the old subscription was the only usage of the dialog, then once you get a notification that the subscription is gone, it is probably too late to reuse the dialog. OTOH, if the dialog was being kept active by some other usage (e.g. an INVITE) then you can go ahead and establish the replacement subscription.
However, note that if you got a 481 response to a refresh attempt on the old subscription, then that indicates the dialog is gone, so you can't establish a new subscription in the same dialog. The case where you could would be if you received a NOTIFY containing an indication that the subscription has been terminated.
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.
Paul
[EMAIL PROTECTED] wrote:
Balu,
When reading your posting I couldn't think of a scenario that creates a subscription within an existing dialog (I have a long way to go trying to learn this stuff). It occured to me that perhaps this section has been written with the premise that the SUBSCRIBE created the dialog - which is why the resubscription in response to the 481 is written to create a new dialog ?. If you are creating a subscription within an existing dialog perhaps it is sufficient to just generate a new request(and not a new dialog ?).
- Wayne.
Balu said:
RFC 3265 section 3.1.4.2 states If a SUBSCRIBE request to refresh
a subscription receives a "481" >response, this indicates that the subscription has been terminated and that the subscriber did not receive
notification of this fact.
In this case, the subscriber should consider the subscription invalid.
If the subscriber wishes to re-subscribe
to the state, he does so by composing an unrelated initial SUBSCRIBE
request with a freshly-generated Call-ID and a >new, unique "From" tag -- Does this means once a subscribtion for a event is terminated in a dialog, >resubscribtion for that event cannot be done in the same dialog later on, if s why can't i resubcribe for that >event in same dialog ( with different value for id in Event header).
Thanks
Balu
________________________________________________________________________ Yahoo! India Matrimony: Find your life partner online Go to: http://yahoo.shaadi.com/india-matrimony _______________________________________________ Sip-implementors mailing list [email protected] http://lists.cs.columbia.edu/mailman/listinfo/sip-implemento _______________________________________________ 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
