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]
Is there any spec invalidating the usage of custom and changing
parameters in the Event header within the
___
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
Hi, would be valid the following flow?:
# UA -> Presence Server
SUBSCRIBE ...
CSeq: 100
Event: buddylist;since-version=5
# Presence Server -> UA
NOTITY ...
CSeq: 1
Event: buddylist;version=6
# Presence Server -> UA
NOTITY
CSeq: 2
Event: buddylist;version=7
# Presence Server -> UA
NOTITY ...
CS
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
29 matches
Mail list logo
