Matthew,
I have studied this, and posted on it in the past. IMO a dialog is a
dialog, and a dialog usage is a dialog usage. In theory you should be
able to create a dialog with SUBSCRIBE and then send an INVITE within
it, and/or send another SUBSCRIBE within it in either direction. You
could also send a REFER within it and get the implied subscribe dialog
usage to share the dialog.
You cannot have two INVITE dialog usages share the same dialog - at
least not concurrently. It is pretty unclear whether it would be ok to
do something like:
- establish dialog with INVITE
- do SUBSCRIBE that shares the dialog
- end the INVITE dialog usage with BYE
(dialog remains for subscribe)
- do another INVITE in the same dialog
(establishing a new invite dialog usage)
However, those who created the shared dialog now wish they hadn't. There
are recommendations to deprecate shared dialogs, and only allow deployed
use cases for backward compatibility.
In practice, I think many of the more esoteric cases are unlikely to
work in most UAs.
My personal opinion is that the horse is out of the barn, so there is
little reason to shut the door. A *proper* implementation that supports
the key use cases should support all the esoteric ones as well.
Paul
Matthew Gardiner wrote:
> Hi all,
>
> After reading RFC3265 I have discovered that in addition to INVITEs,
> SUBSCRIBEs can also create sip dialogs.
>
> What exactly can occur in these SUBSCRIBE-created dialogs? Are there any
> constraints on the types of other requests which may be sent using the
> callid created by the SUBSCRIBE? For example, given a SUBSCRIBE-created
> dialog, is it then possible for the communicating devices to partake in an
> INVITE transaction and negotiate a media session between themselves?
>
> thanks,
>
> Matthew Gardiner
> Software Enginneer
> Aculab
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
