Jade,
When you send the request you can begin expecting a dialog(s) to be
established. But it is usually a response that actually establishes the
dialog. There shouldn't be any cases when a response establishes a
dialog you weren't expecting.
There are also some obscure cases where it isn't a response that
establishes a dialog. For instance, when you send a SUBSCRIBE, it is
possible for a NOTIFY triggered by the SUBSCRIBE to arrive before a
dialog as been established by a response to the SUBSCRIBE. In this case,
the NOTIFY itself can cause the dialog to be created. Of course you
should first figure out that the NOTIFY is a consequence of a SUBSCRIBE
you sent before you create a dialog for it.
So, from a coding perspective you probably want to build some data
structures in anticipation of dialogs at the time you send a request
that might establish a dialog, and then finish up the dialog creation
when subsequent events demand it. And of course don't forget that a
single request may lead to the creation of multiple dialogs because of
forking of the request.
Paul
Jade Chen Yan wrote:
> Hello, List,
>
> In the RFC 3261, 12.1.2,
> It says:
> "When a UAC sends a request that can establish a dialog."
>
> but it also says
> "When a UAC receives a response that establishes a dialog,it constructs
> the state of the dialog"
>
> I wonder when to create the dialog?Is either OK?
>
>
> Best Regards,
> Jade
_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
