I can understand how you might dislike the unusual way that forking of
subscribes is handled. It is a special case. It was done that way
because there was a desire to support forking of subscribe, and also a
desire not to institute a transaction state machine for subscribe (akin
to the one for INVITE). So it is what it is, like it or not. After a
subscribe, you are expected to recognize the half-matching dialog ids
and establish new dialogs for them.
Sorry,
Paul
Iñaki Baz Castillo wrote:
> 2009/7/20 Victor Pascual Avila <victor.pascual.av...@gmail.com>:
>> On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castillo<i...@aliax.net> wrote:
>>> Of course, the Contact in the NOTIFY from the server are equal.
>> Not really-- successful SUBSCRIBE requests will receive only one
>> 200-class response; however, due to forking, the subscription may have
>> been accepted by multiple nodes.
>
> As I explained in my other mail, those servers whose 200 didn't arrive
> to the susbcriber (since the proxy absorbed them) couldn't send
> in-dialog NOTIFY to the subscriber (the From-tag of those NOTIFY's
> wouldn't match the existing subscription dialog in the subscriber).
>
>
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
