[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Sipping] I-D ACTION:draft-ietf-sipping-dialogusage-02.txt
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)?
>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.
>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.
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