Matthew Gardiner wrote:
> Paul,
>
> Thanks for your reply on this. I tend you agree with you here: all
> dialogs should have similar usage rules irrespective of creation mechanism.
>
> Furthermore, would I be right in saying that INVITE and SUBSCRIBE are
> the only requests which are able to create dialogs?
REFER can also create a dialog.
Paul
> thanks again,
> Matt
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
> Sent: 24 January 2006 16:12
> To: Matthew Gardiner
> Cc: [email protected]
> Subject: Re: [Sip-implementors] Dialog creation by SUBSCRIBE
>
>
> 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
