in my own roster; I could imagine some hosts and
clients might not handle that too well, or at least annoy the developers :)
thx!
Tim Julien
Cool thanks - but will you be subscribed to future presence changes -
i.e., will you know when they sign off? I suppose you could essentially
poll - with presence probes?
-Tim
Peter Saint-Andre wrote:
Tim Julien wrote:
Is there any way to get the presence information for your account
Peter Saint-Andre wrote:
On 05/30/2008 12:14 PM, Tim Julien wrote:
One of the first things I'm going to want to do is add ice-udp (we have
a reliable UDP impl) as a transport
Isn't reliable UDP different from UDP? Or would you just negotiate
ice-udp and if your UDP stack provides reliable
sounds good.
-Tim
Peter Saint-Andre wrote:
On 06/04/2008 10:47 AM, Tim Julien wrote:
Peter Saint-Andre wrote:
On 06/03/2008 2:14 PM, Maiku wrote:
In XEP-0176, Jingle using the ICE-UDP transport method, it says for
the initiator to send out the transport candidates either as soon as
getting
From the diff I see that you corrected the transport namespaces from
ice-tcp to ice-udp.
Any thoughts around creating an ice-tcp transport?
XMPP Extensions Editor wrote:
Version 0.18 of XEP-0167 (Jingle Audio via RTP) has been released.
Abstract: This specification defines a Jingle
Peter Saint-Andre wrote:
On 05/21/2008 1:18 PM, Tim Julien wrote:
So, I'm confused about some of the transport negotiation stuff.
It was sketched out rather quickly and probably needs more work.
In first scenario (section 3.1) the negotiation occurs after
session-accept - which is counter
The Changelog says content-modify and content-accept were removed from
the PENDING state. But the state diagram in section 5.1 still lists
them as valid actions when in PENDING.
-Tim Julien
XMPP Extensions Editor wrote:
Version 0.25 of XEP-0166 (Jingle) has been released.
Abstract
9.4 also makes use of content-replace in the PENDING state in a
slightly different way - during transport negotiations as opposed to as
a final step.
-Tim Julien
XMPP Extensions Editor wrote:
Version 0.17 of XEP-0167 (Jingle Audio via RTP) has been released.
Abstract: This specification defines
This makes use of content-replace in the PENDING state (i.e., before
session-accept) as the final step in transport negotiation.
see the state diagrams and examples in sections 5.1, 5.6.
However, Jingle (166) is very clear that content-replace cannot be used
in the PENDING state.
-Tim
from the other Jingle specs, but I really
like it. It's analogous to the listing of multiple payload-type's in
Jingle Audio RTP, and both parties agree on one.
-Tim Julien
XMPP Extensions Editor wrote:
Version 0.2 of XEP-0234 (Jingle File Transfer) has been released.
Abstract
10 matches
Mail list logo
