[EMAIL PROTECTED] wrote:
> I'm actually implementing this right now so it caught my eye...
>
> Comments inline...
>
> FM
>
>
> ------------------------------------------------
> On Mon, 07 Aug 2006 10:13:50 -0400, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>> One thing was not mentioned by other responders:
>>
>> when you send a SUBSCRIBE, it may be forked. If one fork returns a 2xx,
>> then other 2xx responses will be dropped by the forking proxy. However,
>> for other forks that did respond with a 2xx, a NOTIFY may arrive. It
>> will be in the context of a dialog known to the sender but not to the
>> receiver. The recipient of such a NOTIFY is expected to establish a
>> dialog as a result. Subsequent NOTIFYs by the same sender will be within
>> that dialog.
>>
>
> If I read 3265 correctly, it says that the specific event package must
> specify whether forking results in multiple dialogs or not.
>
> If I further read 3856 (Presence Event Package), it says that only a single
> dialog can be established for presence. I assume this means that for this
> event package, the 481 responses would be sent to any other NOTIFYs that make
> it through. Am I correct?
That seems correct.
> Also, Presence is the only event package that I've read through in detail.
> Are you aware of an event package that does allow for forking?
The dialog event package (RFC 4235) allows forking.
> Thinking about this a little more, I understand why only a single 200 OK
> makes it back to the subscriber. Is the subsequent NOTIFY then being used
> essentially to get around the fact that the forking proxy terminating any
> other 200 OKs to establish a dialog anyway? ICK!!
Yes.
Paul
> Thanks,
> FM
>
>
>>> I have a doubt regarding the SIP NOTIFY msgs.
>>>
>>> My idea about NOTIFY msg is, in general when a party SUBSCRIBE for some
>>> event and he's notified by the Notifier that NOTIFY msg would be an
>>> in-dialog msg i.e would have the same dialog id as that of the SUBSCRIBE.
>>>
>>> But is there a case in which the NOTIFY msg can be a out of dialog one as
>>> well?
>>>
>>>
>>>
>>> Regds.
>>>
>>> Tatha
>>>
>>> _______________________________________________
>>> 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
>>
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
