Re: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt

[Paul Kyzivat <pkyzivat at cisco.com>]

Christer Holmberg (JO/LMF) wrote:
> Hi, 
>
> > > I will reply on your previuos mail later, but one issue I forgot to
> mention (I think I raised this issue on the list a 
> > > while ago also).
> > >
> > > TENTH: How are early dialogs affected? Assume a client initiates a
> invite usage, and receives 18x responses from 
> > > multiple locations. Then, the client will create subscribe usages on
> some of these early dialogs.
> > > Then, when 200 is received for the INVITE on one dialog, what happens
> to the other dialogs? Normally they would be 
> > > terminated, but now we have created subscribe usages on them...
> > >
> > > I think the easiest solution for this would be to say that multiple
> dialog usages are only allowed on fully established 
> > > dialogs.
> > Why is there even an issue here?
> >
> > In reality it isn't the dialog that is early - its the invite dialog
> usage that is early. (You shouldn't get early 
> > dialogs from other dialog establishing requests.)
>
> [CHH] A subscribe establishing request can be forked, can't it (assuming
> the request is for the first usage of a dialog, without a To tag)?

Yes, but the result will be multiple (non-early) subscribe dialog 
usages. The so called early dialog (usage) is a result of a 1xx response 
with a to-tag, which has been declared only appropriate for INVITE.

> > The establishment of an early invite dialog usage results in creating a
> dialog (not an early dialog), that has one usage. 
> > Like always, the dialog goes away when all the usages do.
>
> [CHH] Then one COULD ask why the forking proxy should terminate early
> invite dialogs when 200 OK (INVITE) is received on one early dialog,
> instead of just allow multiple invite dialogs to be created (and let the
> UAC terminate the ones it doesn't want). Why should proxies handle
> invite dialogs differently than subscribe dialogs? But, I won't ask
> that, because I don't want to re-write the whole forking mechanism,
> eventhough 3261 does allow a CLIENT to accept multiple 200 responses
> (from different legs) for an INVITE.

Yes I agree that there is question why that is done, and we don't want 
to revisit that.

But the above is another example of language that confuses dialog and 
dialog usage. The proxy does not terminate early dialogs. All it does is 
send CANCELs, with terminate transactions, which in turn may terminate 
an early invite dialog usage, which in turn may result in the 
termination of a dialog.

> > Making a rule that you can reuse a dialog with an early invite dialog
> usage is just an arbitrary added rule. It doesn't 
> > seem to simplify anything. Also, I'm not sure, but aren't there blind
> transfer scenarios that might actually use this? 
> > (REFER in an dialog with an early invite.)
>
> [CHH] Maybe you're correct. But, again, I think it would be worth to
> mention.

In this draft saying more is better than leaving something implied.

	Paul

> Regards,
>
> Christer

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP