Subject: [Sip] Re: Dialog usage: Forking impacts

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Mar 2006 00:19:06 +0200

Hi Robert,

It is true that 1-2 has two dialog usages, and the CANCEL should cause 2 to terminate one of them (but keep the subscribe dialog alive).

The problem is that 1 may, when receiving 200 OK from 3, terminate the dialog - not only a specific dialog usage - with 2.

Regards,

Christer

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Mar 2006 16:38:22 +0200

Hi Paul,

Yes, the issue is that UA_1 would terminate the whole dialog - including all usages.

However, 3261 does not mandate the termination of dialogs - it simply says that there are currently no applications defined where multiple fully established dialogs would be kept alive within a session. And, that of course makes the whole thing even more interesting :)

Regards,

Christer

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 8 Mar 2006 09:21:50 +0200

Hi,

I agree with the issue you bring up.

However, the "problem" already exist when subscription dialog usages are created, because it is said that a NOTIFY may arrive before the 200 response to the SUBSCRIBE/REFER...

Regards,

Christer

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 14 Mar 2006 16:07:48 +0100

Hi, 

>>I think that reuse early dialog may be risk. Because SUBSCRIBE may
arrive
>>at UA1 before 1xx or 2xx for the reason of net delay or lose, so UA1
>>doesn't find out a match dialog for SUBSCRIBE, finally the SUBSCRIBE
will be 
>>dropped, and return 400.
> 
>If UA2 sends an *confirmed* 1xx to establish the early dialog, and 
>then sends the subscribe after receiving confirmation (via prack) then 
>there is no risk.

[Xiao]Right. 

[CHH] I also agree. However, at the same time it is allowed to send
NOTIFY before a 200 OK has been received for a SUBSCRIBE/REFER request,
i.e. before the dialog (or dialog usage) has been established.

Regards,

Christer

> >
> >
> >>-----Original Message-----
> >>From: Paul Kyzivat [mailto:[email-masked]]
> >>Sent: Friday, March 03, 2006 11:26 PM
> >>To: Christer Holmberg (JO/LMF)
> >>Cc: IETF SIP List
> >>Subject: [Sip] Re: Dialog usage: Forking impacts
> >>
> >>
> >>
> >>Christer Holmberg (JO/LMF) wrote:
> >>
> >>>Hi,
> >>>
> >>>Another scenario related to the dialog usage issue:
> >>>
> >>>1.      UA_1 sends an INVITE, which gets forked to UA_2 and UA_3.
> >>>
> >>>2.      UA_2 establish an early dialog with UA_1 and sends a
SUBSCRIBE
> >>>(or any other request establishing a new dialog usage) to UA_1, 
> >>>establishing a dialog usage (subscribe dialog usage in case of
> >
> > SUBSCRIBE).
> >
> >>>3.      UA_3 acceptes the session for the INVITE and sends 200 OK
> >
> > (INVITE)
> >
> >>>4.      The forking proxy sends a CANCEL to UA_2, and forwards the
200
> >>>OK (INVITE) to UA_1.
> >>>
> >>>5.      UA_1, when receiving the 200 OK, would normally terminate
the
> >>>early dialog between itself and UA_2. BUT, in this case it can't do

> >>>it, because it still has an active subscription dialog usage 
> >>>association with UA_2, and the CANCEL sent by the proxy didn't 
> >>>terminate that
dialog
> >>>usage in UA_2 either.
> >>
> >>This does point up some issues with language in the RFCs. I doubt 
> >>there really is any such thing as an "early dialog". In reality 
> >>there is only one kind of dialog, but there is an "early invite
dialog usage".
> >>
> >>
> >>>Now, the dialog usages still share the same dialog, but from the 
> >>>UA_1 perspective each dialog usage has DIFFERENT route sets and 
> >>>remote
> >
> > targets...
> >
> >>Don't think I agree. Following step 3, or maybe sooner, UA1 knows 
> >>there are two dialogs, because it has received responses with 
> >>different to-tags. The early invite dialog usage with UA2 and the 
> >>subscribe from
> >>UA2 share one dialog, and the invite dialog usage with UA3 uses the 
> >>other dialog.
> >>
> >>There isn't anything new here due to sharing. UA2 and UA3 could have

> >>both established early invite dialog usages. UA1 has to deal with 
> >>two dialogs in that case as well.
> >>
> >>The key thing in all this is that the lifetime of dialogs is not 
> >>explicitly managed. Rather it is reference counted based on the 
> >>usages that share it.
> >>
> >>
> >>>Saying that dialog re-usage is only allowed for FULLY ESTABLISHED 
> >>>dialogs would of course solve this, but currentely I think it's 
> >>>legal from a pure SIP perspective. Or?
> >>
> >>This is one of the reasons why I think it is a bad idea to start 
> >>putting restrictions on the use of shared dialogs. As things stand, 
> >>the whole ediface does tie together using just a few basic 
> >>principles. If you support those principles, then all the different 
> >>possible combinations of usages will work. If you impose 
> >>restrictions on the kinds of usages that are allowed, you encourage 
> >>implementations that implement all sorts of special case logic. 
> >>Figuring out what special case logic is sufficient is harder than
implementing the general case.
> >>	Paul
> >>This list is for NEW development of the core SIP Protocol Use 
> >>[email-masked] for questions on current sip Use 
> >>[email-masked] for new developments on the application of sip
> >
> >
> >
> >
> > This list is for NEW development of the core SIP Protocol Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> >

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[email-masked] for questions on current sip Use
[email-masked] for new developments on the application of sip