2009/7/22 Dale Worley :
> On Tue, 2009-07-21 at 22:50 +0200, Iñaki Baz Castillo wrote:
>> > And it is implemented
>> > correctly in the sipXecs proxy system (and most likely all other
>> > high-quality SIP implementations).
>>
>> I don't understand what you mean, a proxy has nothing to do here:
>
>
On Tue, 2009-07-21 at 22:50 +0200, Iñaki Baz Castillo wrote:
> > And it is implemented
> > correctly in the sipXecs proxy system (and most likely all other
> > high-quality SIP implementations).
>
> I don't understand what you mean, a proxy has nothing to do here:
sipXecs also includes a consider
El Martes, 21 de Julio de 2009, Dale Worley escribió:
> On Tue, 2009-07-21 at 01:54 +0200, Iñaki Baz Castillo wrote:
> > As I explained in my other mail, parallel forking in subscription is
> > really a corner case. But the logic and code to implement it in the
> > client is really complex. I expec
On Tue, 2009-07-21 at 01:54 +0200, Iñaki Baz Castillo wrote:
> As I explained in my other mail, parallel forking in subscription is really a
> corner case. But the logic and code to implement it in the client is really
> complex. I expect that a vendor cannot spend so much time to implement such
El Martes, 21 de Julio de 2009, Paul Kyzivat escribió:
> I can understand how you might dislike the unusual way that forking of
> subscribes is handled. It is a special case.
Yes, I understand.
However, IMHO it's a very bad design and most probably it will never be well
implemented.
As I explai
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
On Mon, 2009-07-20 at 16:37 +0200, Iñaki Baz Castillo wrote:
> 2009/7/20 Michael Procter :
> >> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
> >> OK to the initial SUBSCRIBE, that's all.
> >> Of course, the Contact in the NOTIFY from the server are equal.
> >
> > Not exact
2009/7/20 Michael Procter :
>> Sorry, but those other NOTIFY will have a different From-tag so they
>> will discarded with 481 by the subscriber as they don't match the
>> dialog (From-tag, To-tag and Call-ID) established by the subscriber
>> and the server whose 200 arrived to the subscriber.
>
>
Ahem:
2009/7/20 Iñaki Baz Castillo :
> 2009/7/20 Michael Procter :
>>> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
>>> OK to the initial SUBSCRIBE, that's all.
>>> Of course, the Contact in the NOTIFY from the server are equal.
>>
>> Not exactly. The contact in the noti
2009/7/20 Victor Pascual Avila :
> On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castillo 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 h
2009/7/20 Michael Procter :
>> No. The RURI of re-SUBSCRIBE should be the Contact received in the 200
>> OK to the initial SUBSCRIBE, that's all.
>> Of course, the Contact in the NOTIFY from the server are equal.
>
> Not exactly. The contact in the notify will not necessarily be the
> same as the
On Mon, Jul 20, 2009 at 2:41 PM, Iñaki Baz Castillo 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.
Che
Some corrections inline:
2009/7/20 Iñaki Baz Castillo :
> 2009/7/20 Dushyant Dhalia :
>> In NOTIFY the notifier sends its
>> contact. Now my question is - is it okay for the subscriber to send
>> re-subscribe with RequestURI set to the contact it received in NOTIFY?
>
> No. The RURI of re-SUBSCRIB
2009/7/20 Dushyant Dhalia :
> I need to know what should be the request-uri for re-subscription?
Is it a question? :)
> The RequestURI in initial/first SUBSCRIBE is set to the resource to which
> the subscriber wants to be subscribed to.
Yes.
> In NOTIFY the notifier sends its
> contact. Now
I need to know what should be the request-uri for re-subscription?
The RequestURI in initial/first SUBSCRIBE is set to the resource to
which the subscriber wants to be subscribed to. In NOTIFY the notifier
sends its contact. Now my question is - is it okay for the subscriber to
send re-subscri
15 matches
Mail list logo
