2010/9/11 Adrian Georgescu :
> Inaki,
>
> I am afraid that only moving towards a SIP 3.0 standard can enforce such a
> dramatic change.
Then all the implementors trying to implement RLS subscription should
wait until SIP 3.0.
--
Iñaki Baz Castillo
___
Inaki,
I am afraid that only moving towards a SIP 3.0 standard can enforce such a
dramatic change.
Not sure where the energy for this may come from.
Adrian
"Iñaki Baz Castillo" wrote:
>2010/9/11 Adrian Georgescu :
>> Probably is better not to use it at all unless you can reach your PA using
2010/9/11 Adrian Georgescu :
> Probably is better not to use it at all unless you can reach your PA using
> TCP/TLS. Even individual NOTIFYs can have large payloads.
> UDP is a bad design decision when it comes to applications beyond VoIP and
> even voice suffers because ICE payloads are also huge
On Sep 11, 2010, at 2:02 PM, Iñaki Baz Castillo wrote:
> 2010/9/11 Iñaki Baz Castillo :
>> So I expect that this should be enforced by the whole application,
>> this is, both the client and its outboud proxy should force TCP. It
>> should be valid to add this constrain.
>
> If it is not possible
2010/9/11 Iñaki Baz Castillo :
> So I expect that this should be enforced by the whole application,
> this is, both the client and its outboud proxy should force TCP. It
> should be valid to add this constrain.
If it is not possible (adding a constrain about the transport
protocol) then SIMPLE spe
2010/9/11 Adrian Georgescu :
>> all the path MUST be a reliable transport.
>
> As far as I know you cannot control this from the client side, cannot enforce
> it.
Except in the case the user knows the exact URI of the presence server
and the topology between it so it can construct the SUSBCRIBE r
> all the path MUST be a reliable transport.
As far as I know you cannot control this from the client side, cannot enforce
it.
Adrian
>
>
> References:
>
> https://lists.cs.columbia.edu/pipermail/sip-implementors/2010-April/024794.html
> http://www.ietf.org/mail-archive/web/simple/current
2010/9/10 Adrian Georgescu :
>> Why is HTTP more reliable than SIP?
>
> At least two reasons:
>
> 1. Stupid intermediaries (ALGs, SBCs and the like)
There are also HTTP proxies breaking things.
> 2. Fragmentation over UDP, with SIP you cannot control the transport chosen
> by intermediaries
SI
2010/9/10 Adrian Georgescu :
>> Perhaps in your implementation, but OMA specs clearly state that an UA
>> subscribes to the XCAP/XDMS server for changes in its documents.
>
> I assume that one always subscribes to its own URI for presence.winfo and
> xcap-diff events, and ends up on the PA of the
On Sep 10, 2010, at 9:47 PM, Iñaki Baz Castillo wrote:
> 2010/9/10 Adrian Georgescu :
>> What I meant by 'syncing' is transporting the buddy list data over SIP as
>> payload, what you try to achieve.
>>
>> SIMPLE related, this data could be passed as payload in a Notify for
>> xcap-diff event
On Sep 10, 2010, at 9:56 PM, Iñaki Baz Castillo wrote:
>> On Sep 10, 2010, at 8:05 PM, Iñaki Baz Castillo wrote:
>>
>>> 2) The XCAP/XDMS server notifies the user with incremental changes
>>> occured in the resource-lists by other UA (wow, an HTTP server
>>> handling SIP subscriptions!!).
>>
2010/9/10 Adrian Georgescu :
> Check the code we built for managing these exceptions:
>
> http://sipsimpleclient.com/wiki/SipMiddlewareApi#XCAPsupport
>
> Your bug reports are welcome.
I admirate your work on this area, be sure. I just hate the whole
specification :)
> On Sep 10, 2010, at 8:05
2010/9/10 Adrian Georgescu :
> What I meant by 'syncing' is transporting the buddy list data over SIP as
> payload, what you try to achieve.
>
> SIMPLE related, this data could be passed as payload in a Notify for
> xcap-diff event but I would not implement this, is much more reliable to
> fetch
2010/9/10 Worley, Dale R (Dale) :
>
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
> Castillo [...@aliax.net]
>
> But what I mean is that IETF/OMA already
> defines how a SIP
There is no version number, you use etags.
Adrian
On Sep 10, 2010, at 8:59 PM, Worley, Dale R (Dale) wrote:
>
> From: sip-implementors-boun...@lists.cs.columbia.edu
> [sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
> Castillo [.
Inaki,
On Sep 10, 2010, at 8:05 PM, Iñaki Baz Castillo wrote:
> 2010/9/10 Adrian Georgescu :
>> Syncing buddy lists by using SIP protocol is something you should think
>> about more carefully before even attempting it.
>
> SIMPLE (or OMA) already defines it:
What I meant by 'syncing' is transp
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo [...@aliax.net]
But what I mean is that IETF/OMA already
defines how a SIP UA can receive incremental changes in its
cont
Check the code we built for managing these exceptions:
http://sipsimpleclient.com/wiki/SipMiddlewareApi#XCAPsupport
Your bug reports are welcome.
Adrian
On Sep 10, 2010, at 8:05 PM, Iñaki Baz Castillo wrote:
> 2010/9/10 Adrian Georgescu :
>> Syncing buddy lists by using SIP protocol is someth
2010/9/10 Adrian Georgescu :
> Syncing buddy lists by using SIP protocol is something you should think about
> more carefully before even attempting it.
SIMPLE (or OMA) already defines it:
1) The user subscribes to changes in its resource-lists document.
2) The XCAP/XDMS server notifies the use
2010/9/10 Worley, Dale R (Dale) :
> But as Paul says, using CSeq as a version number for the body content is a
> layer violation and will likely cause you trouble at some point in the future
> because some software will change CSeq in a way that is compatible with RFC
> 3261 but not with your ap
___
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz
Castillo [...@aliax.net]
Hi, I'm doing a custom specification in which NOTIFY's contain just
changes rather than the whole document
2010/9/10 Paul Kyzivat :
> IMO you should not use CSeq this way, for a variety of reasons:
>
> - its a "layer violation". The cseq values are pertinent at the
> dialog layer. The content of the NOTIFYs is at the application
> layer.
>
> - if perchance the dialog is being used for something else
>
2010/9/10 Adrian Georgescu :
> I know your opinion about XCAP, you put some work into trying to make it work
> and bump into its complexity.
Yes :)
> If you try to use another self-invented mechanism you will not be able to
> interoperate with anyone else.
And does XCAP clients interoperate w
Iñaki,
IMO you should not use CSeq this way, for a variety of reasons:
- its a "layer violation". The cseq values are pertinent at the
dialog layer. The content of the NOTIFYs is at the application
layer.
- if perchance the dialog is being used for something else
(e.g. an INVITE) as wel
I know your opinion about XCAP, you put some work into trying to make it work
and bump into its complexity.
If you try to use another self-invented mechanism you will not be able to
interoperate with anyone else. So in this case you may implement your own
specification with your own assumptions
2010/9/10 Adrian Georgescu :
> If you use TLS then it might work.
Humm, what is the difference? It still could occur that the UA speaks
TLS with the outbound proxy and the proxy UDP with the presence
server, so notifications from the presence server to the proxy could
fail. Am I wrong?
--
Iñaki
If you use TLS then it might work.
Adrian
On Sep 10, 2010, at 3:17 PM, Iñaki Baz Castillo wrote:
> 2010/9/10 Adrian Georgescu :
>> Syncing buddy lists by using SIP protocol is something you should think
>> about more carefully before even attempting it.
>>
>> Even by using a reliable transpor
2010/9/10 Adrian Georgescu :
> Syncing buddy lists by using SIP protocol is something you should think about
> more carefully before even attempting it.
>
> Even by using a reliable transport like HTTP/TCP the logic to keep in sync
> multiple documents on multiple clients is mind-blowing and the
No sure my advise will help in this case, because I may have other ideas.
Syncing buddy lists by using SIP protocol is something you should think about
more carefully before even attempting it.
Even by using a reliable transport like HTTP/TCP the logic to keep in sync
multiple documents on mul
2010/9/10 Adrian Georgescu :
> I do not see how SIP can be suitable for an application to sync data in a
> reliable way by using a Subscribe/Notify mechanism by making assumptions over
> the Cseq increments.
Please, take a look to my other recent mail with subject "Event header
with changing par
I do not see how SIP can be suitable for an application to sync data in a
reliable way by using a Subscribe/Notify mechanism by making assumptions over
the Cseq increments.
Adrian
On Sep 10, 2010, at 2:34 PM, Iñaki Baz Castillo wrote:
> 2010/9/10 Adrian Georgescu :
>> I would think that is up
2010/9/10 Adrian Georgescu :
> I would think that is up to the application to decide what is relevant for it
> and how it should react to such a failure. So I may not care to loose a
> Notify for some data and I will keep the same subscription alive, while for
> other application where I need co
I would think that is up to the application to decide what is relevant for it
and how it should react to such a failure. So I may not care to loose a Notify
for some data and I will keep the same subscription alive, while for other
application where I need consistency I would start the subscript
2010/9/10 Adrian Georgescu :
> Hi Inaki,
>
> If you lost an update you could Subscribe again, get the full state again,
> then continue with the incremental updates.
Yes, but according to RFC 3261 a UA MUST accept an in-dialog request
as valid if it contains a CSeq with an incremented value, it d
Hi Inaki,
If you lost an update you could Subscribe again, get the full state again, then
continue with the incremental updates.
Regards,
Adrian
___
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cu
Hi, I'm doing a custom specification in which NOTIFY's contain just
changes rather than the whole document (as there is no concept of
"document" at all). In this case I need that the watcher receives
always a NOTIFY with CSeq incremented in eactly one. If last received
NOTIFY had CSeq=12 and the wa
36 matches
Mail list logo
