From robert.mcqueen at collabora.co.uk  Wed Sep  3 18:12:36 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 00:12:36 +0100
Subject: [Jingle] [Fwd: [google-talk-open] VNC over libjingle]
In-Reply-To: <48B9B468.8060800@stpeter.im>
References: <48B9B468.8060800@stpeter.im>
Message-ID: <48BF19E4.8060606@collabora.co.uk>

Peter Saint-Andre wrote:
> Of interest.

Indeed. Actually very similar in spirit to Telepathy's stream tubes.
It's on our todo list to draft a Jingle content XEP for this, also
including a mapping to XEP-0115 capabilities to re-use DNS-SD service
names describe what protocols are available from a given contact.

Also of relevance to running file transfers or other stream protocols
over datagram transports, we found a library recently called Enet
(http://enet.bespin.org/) which lets you send reliable or
reliable+ordered packet streams over a UDP connection which can be NAT
traversed reliably. I think libjingle's P2P stuff is pretty heavily tied
up with their XMPP implementation in lj 0.4 onwards, so Enet might be
cleaner for integration in existing clients.

The real problem is that even though either might work pretty well, it's
kinda awkward from a standards perspective to have just implementations
but no standard. We really need a reliability which is defined on paper
so that we can normatively reference it from a XEP. R?mi Denis-Courmont
at Nokia has been discussing the same kind of problem space on the IETF
BEHAVE WG. He's written a draft for something like TCP but intended for
use on top of UDP, but the problem there is the reverse - there didn't
seem to be a lot of concensus about it, and there are no implementations
currently. :(

Regards,
Rob

> -------- Original Message --------
> Date: Sat, 30 Aug 2008 12:08:19 -0700 (PDT)
> Subject: [google-talk-open] VNC over libjingle
> From: ramuramamurthy <ramu.ramamurthy at gmail.com>
> To: google-talk-open <google-talk-open at googlegroups.com>
> 
> 
> The gnat google-code project is a wrapper around libjingle to allow
> client-server applications like VNC to connect using
> gmail handles instead of IP addresses
> 
> http://code.google.com/p/gnat/
> 
> Enjoy!
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "google-talk-open" group.
> To post to this group, send email to google-talk-open at googlegroups.com
> To unsubscribe from this group, send email to
> google-talk-open+unsubscribe at googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/google-talk-open?hl=en
> -~----------~----~----~----~------~----~------~--~---
> 


From robert.mcqueen at collabora.co.uk  Wed Sep  3 18:26:06 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 00:26:06 +0100
Subject: [Jingle] Replacing codec parameters and content-modify/replace
In-Reply-To: <1219473152.15807.14.camel@TesterBox.tester.ca>
References: <1219473152.15807.14.camel@TesterBox.tester.ca>
Message-ID: <48BF1D0E.8060206@collabora.co.uk>

Olivier Cr?te wrote:
> Hello,
> 
> While discussing the pidgin implementation of Jingle. I realized that we
> missed one case.

Uh oh...

> Codecs like Theora, Vorbis and H.264 need a header to be received before
> any media can be decoded. The ideal way to reliably transmit that header
> is in the signalling. To produce that header for some codecs (including
> Vorbis and Theora), you often want to initialize the encoder and pass
> one buffer through it.
> 
> This becomes problematic if you want to start a recv-only call and later
> activate sending. With SIP, what I'd do is first send SDP without the
> header and later when I want to start sending, send it in the updated
> SDP as part of the re-invite. Maybe we could do the same with
> content-modify, being able to send a new <definition> block with updated
> parameters?

Starting a recv-only call is pretty weird though, isn't it? Isn't the
initiator always going to want to originate media, and the responder
then may or may not decide they want to reply with media too. What I'm
getting at is: Does this require a full renegotiation with a new SDP
offer and a new answer, or does it really just require an updated answer
to the original offer?

I'm not sure about including new <definition> blocks in a
"content-modify", as it overloads the semantics somewhat, and makes it
ambiguous what modifications you do/don't have to respect/look out for
in this action. If we /do/ want to do things like updating/replacing the
codec descriptions, maybe we want "description-info" or maybe even
"description-replace"/"description-accept", but this really terrifies me.

> This also applies if the header changes mid-stream (lets say I want to
> dynamically change the source in the case of a server-brokered
> multi-conference). We also need to modify the SDP.

If we're going for a full general purpose re-negotiation I'd much rather
try and push it into making a new content and removing the old one when
it's set up, rather than adding a whole load of hooks/extra semantics
into Jingle to deal with these situations. This avoids various issues
with crossed-over offers (contents are named uniquely by either the
initiator or responder) and gives an unambiguous ordering and indication
of who needs to start/stop which stream when.

The cost is that you might be forced into doing more transport
renegotiation than you wanted to, but I think that these renegotiation
cases are quite rare. There's a big benefit in any reasonably coded
Jingle client to making the state machine per stream as simple as
possible, and just running multiple instances of it if necessary, rather
than ending up with a baby copy of the SIP transactional engine in every
Jingle client. :/

We had the same kind of idea for early media at the XMPP summit. Rather
than require re-negotiation, actually just tweak XEP-0166 so that adding
streams to a pending session is allowable, and put a send-only ringing
stream into the session (maybe hint it somehow in XEP-0167 to say "early
media, content-accept this now if you understand/care).

Similarly I don't really expect clients to support transport-replace
with media calls, it's really just intended for falling back when
establishing stream transports fails and you want to try a different
thing. Maybe we could document that somewhere...

Regards,
Rob

From robert.mcqueen at collabora.co.uk  Wed Sep  3 18:48:33 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 00:48:33 +0100
Subject: [Jingle] jingle summit/hackfest?
Message-ID: <48BF2251.1000909@collabora.co.uk>

I mentioned this to a few people at the XMPP summit in Portland, but I
think we'd make some more definitive progress on Jingle if we got the
right people together for maybe a day or two of brainstorming on the
outstanding protocol issues, and a few days of hacking code to see if we
can get the major clients up to some baseline functionality/interopability.

We could take some time to check over the current XEPs and sketch out
some new protocols for the extra functionality we'd like to see covered
(to give Peter lots of nice XEP drafting work to do :D), and then spend
the rest of the time trying to get our Jingle implementations to talk to
each other somehow.

For clients using or planning to use Farsight do the streaming stuff, we
can also have one of our guys on hand to help out, and for clients not
planning to use Farsight, they can explain why you should. :D

If people were interested in such an event I'd be willing for Collabora
to look at organising the initial event, maybe here in Cambridge, and
try and arrange some sponsorship for venue and travel accomodation as
needed (or even sponsor a little from Collabora), and of course any help
here would be appreciated (I don't suppose any Googlers are hanging out
here and would like to put up some XMPP hackers in Mountain View for a
week? :D).

It'd be nice to get a couple of people from the major Jingle
stakeholders (so the clients who are working on support, any
device/server vendors looking to interoperate, etc) along. What do
people think?

Regards,
Rob

From robert.mcqueen at collabora.co.uk  Wed Sep  3 19:17:30 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 01:17:30 +0100
Subject: [Jingle] Are We There Yet?
In-Reply-To: <48A8D000.7000101@stpeter.im>
References: <48A8D000.7000101@stpeter.im>
Message-ID: <48BF291A.3020806@collabora.co.uk>

Peter Saint-Andre wrote:
> As far as I can see, we've incorporated all the consensus points from
> the recent XMPP Summit into the core Jingle specs, so I wonder if they
> are done now. Can we perhaps take the temperature of the list about
> whether XEP-0166, XEP-0167, and XEP-0176 are ready to be advanced to
> Draft? (AFAIK the only outstanding issue is to clean up the examples and
> schemas a bit, but I can do that this week.)

I just skimmed 0166 and 0167 at least, and I think they look reasonably
good now. The only stuff I have on my list that applies to the core XEP is:
a) Allow doing content-add while a session is pending, provided we
clarify that session-accept only accepts contents which were included in
the session-initiate. This would let us do early media with an extra
content, so it should just require a little tweak to XEP-0167 to say
that's how it's done.
b) Add an optional <thread> element to go in under <jingle> so that you
can associate calls/file transfers/etc with an ongoing conversation, so
that UIs which can present multiple interactions in the same window can
relate these things when they are sent over the wire
c) Add some more semantics to transport-replace, including a tie break
in the case of two crossed-over replace actions (session initiator wins,
responder should forget they even tried), and maybe explaining you can
reply with a "content-remove" with a <reason> if the new transport
doesn't work for you.

I'm a bit behind on ICE, and particular how it turns up in SIP, but I
also had a vague interop concern with XEP-0176, which is whether it has
enough information in it that you can turn the ICE candidates into a
SIP+ICE offer, and then deal gracefully with a SIP endpoint that doesn't
understand the ICE parts? I seem to recall that SIP had ICE as extra
lines in the offer, but that it also chose one of the most likely
candidates to put in the "normal" place in case the other endpoint
didn't do ICE. With XEP-0176, is there some way to reply to the ICE
candidates to say that actually, you want to use just raw UDP on the
wire, or does this actually rely on us doing a transport renegotiation
to use the raw UDP transport XEP instead?

> Now, I know we need to work on some extensions. These are:
> 
> 1. File transfer -- needs to be updated per the core specs.

I've got a lot to say on how we can put file transfer together.
Unfortunately despite early skepticism, I'm now pretty sold on Google's
concept of using HTTP over a stream transport, and using a reliability
layer to multiplex streams over a datagram transport.

The reliability layer can be defined in a XEP which provided both a
Jingle description to say "I'm a reliability layer" and a Jingle
transport which can say "put me over the reliability layer content named
'foo', port 80". This means that a file transfer with a group of files
can then just do a single ICE-UDP negotiation as the datagram transport
for the reliability layer, and then include one content stanza for each
file, with a description saying that HTTP is in use, and the path of the
file is here, maybe with a thumbnail too. Something like:

<jingle ...>
  <content name="reliability">
    <description xmlns="...pseudo-tcp">
    <transport xmlns="...ice-udp">
      <candidate ...>
    </transport>
  </content>
  <content name="file0">
    <description xmlns="...http-file">
      <desc>My cat!</desc>
      <size>12345</size>
      <path>/cat.jpg</path>
      <thumbnail>/small-cat.jpg</thumbnail>
    </description>
    <transport xmlns="...pseudo-tcp">
      <content>reliability</content>
      <port>80</port>
    </transport>
  </content>
  <content name="file1">
    <description xmlns="...http-file">
      <desc>My dog!</desc>
      <size>67890</size>
      <path>/dog.jpg</path>
      <thumbnail>/small-dog.jpg</thumbnail>
    </description>
    <transport xmlns="...pseudo-tcp">
      <content>reliability</content>
      <port>80</port>
    </transport>
  </content>
</jingle>

Besides being able to retreive thumbnails separately from the files
themselves, and giving us a reasonable way to multiplex many files over
one session, Justin Uberti from Google pointed out a big advantage with
using HTTP over the reliability layer, which is that if you've got a
relay server (like theirs) which can bridge TCP and pseudo-TCP over ICE,
then a web client can just go for the TCP candidate straight away and
HTTP it directly from http://relayserver:1234/cat.jpg.

> 2. Early media.
> 
> 3. Session transfer.
> 
> 4. Presence sharing (not Jingle-specific).

Looks good. Additionally I'd like to see a XEP with a content
description for miscellaneous existing stream protocols (so, VNC and
stuff). I know I said I'd write it but, yeah... We didn't find an
interested client for that, so it keeps slipping off the todo list atm.
Maybe the same for datagrams too.

> However, I don't think we need to have those done before we can advance
> the core specs to Draft.

Seems fair.

> What do you all say?

Let's do it. Hopefully we'll have an updated implementation to match the
current XEPs really really soon now (the guy just got back from his
honeymoon :D), and any further feedback shouldn't be too major to just
push into the XEP after it's gone Draft.

> /psa

Regards,
Rob

From robert.mcqueen at collabora.co.uk  Wed Sep  3 19:28:59 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 01:28:59 +0100
Subject: [Jingle] XEP for stream protocols
In-Reply-To: <8763qpx6b6.fsf@phex.sachmittel.de>
References: <4887AAAA.3090407@stpeter.im> <4887D274.50108@collabora.co.uk>
	<8763qpx6b6.fsf@phex.sachmittel.de>
Message-ID: <48BF2BCB.9070307@collabora.co.uk>

Dirk Meyer wrote:
> Let me understand it right. Simply speaking Telepathy's Tubes are a
> way to connect local Dbus applications to other machines in the LAN
> and even on the Internet. This idea his very similar to something I'm
> working on except that I don't plan to use Dbus for application
> specific communication and want to use XEPs for that, too. We really
> should work together on how to let applications interact with
> eachother on the internet. 

Yes, that's right. My current thought is that we should have a Jingle
XEP content description which says "this stream protocol is in use", and
refer to it by its DNS-SD service name. We can also define a mapping
between the DNS-SD extra parameters and the Jingle offer.

We'd then be able to signal a Jingle session to have our streams sent
over a raw TCP transport, SOCKS5 or IBB, or when we have code/XEPs for
it we can also make use of a reliability layer on top of ICE-UDP. We can
say that the offerer is the listener, and the responder can establish as
many connections over the stream as he wishes while the session is open.
This will allow protocols like HTTP or DAAP where the client can connect
multiple times to the server to be used.

Also we could define something to include in XEP-0115 entity
capabilities to list the DNS-SD protocols you're able to take part in,
such as:
<feature var="jingle:yada:stream#vnc"/>
<feature var="jingle:yada:stream#http"/>

> Regards,
> 
> Dirk

Regards,
Rob

From robert.mcqueen at collabora.co.uk  Wed Sep  3 19:48:25 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 01:48:25 +0100
Subject: [Jingle] XEP-0181: Jingle DTMF
In-Reply-To: <488A8C55.4030701@null.ro>
References: <488672CF.7070403@collabora.co.uk>	<C98C56C1-AC6D-4661-A8D3-A8C44ADB2D84@edvina.net>	<4887C9CA.9020106@collabora.co.uk>
	<488A8C55.4030701@null.ro>
Message-ID: <48BF3059.7020500@collabora.co.uk>

Diana Cionoiu wrote:
> Hi Rob,

Hi there,

> When you do PBX and you use DTMF's to make all kinds of functionalities,
> than you need to have the DTMF's on the signalling path not in the RTP,
> because the RTP goes directly between end points.
> This is why SIP people added SIP INFO, so don't even think that you
> don't need DTMF's in signalling.

SIP calls can indeed be redirected from one proxy to another as they are
established in this PBX kind of use case, but this isn't normal in XMPP
at all. XMPP signalling is generally end-to-end, so having your call
signalling bounced between several XMPP entities as a call is
established/routed is very unusual. After you've decided who to call,
then you direct your Jingle calls by turning it into the JID you want,
and it's routed by XMPP servers who look at the address, not by punching
numbers.

Admittedly, it works differently depending if you're gatewaying or not.
Either:

 You're talking to something which must be controlled by DTMF, so it's
 going through a gateway to some kind of telephony service. This gateway
 is talking XMPP to signal with you, and receiving your media, and then
 passing it on however it wants. In this gateway situation, the the
 Jingle client can use RTP DTMF with the gateway, which can either pass
 it on if it wishes, or interpret it and make some signalling events if
 it wishes.

Or:

 You're /not/ talking to something which must be controlled by DTMF,
 because it's an XMPP capable endpoint. You can control your Jingle
 middle-man using something better than DTMF, so mapping DTMF tone
 events into XMPP is meaningless. You can use XMPP technologies like
 service discovery, ad-hoc commands, data forms, etc, to browse the men
 or route your call or pick a song to play or whatever.

Either way, I don't really buy your reason at all. Note that the SIP
INFO DTMF method was added by Cisco who make their money selling you
expensive things which will take your SIP call and redirect it via or to
their other expensive SIP things. :P

It think it's really harmful for us to have two different mechanisms for
doing the same thing, one signalling mechanism which makes very little
sense and is required and has weird/useless semantics/timing, and the
other in the RTP stream which is far more interoperable but not required
to be supported by Jingle clients. It means everyone just has to have
two code paths for the same thing, even the gateways.

> Regards,
> Diana

Regards,
Rob

> Robert McQueen wrote:
>> Johansson Olle E wrote:
>>  
>>> I agree that in most situtations, DTMF in the media stream is to be
>>> preferred, mostly because
>>> of timing issues. In some cases, DTMF is handled out of band for IVR
>>> situations, then maybe
>>> KPML could be used in the XMPP stream. It's an XML-based definition in
>>> RFC 4730.
>>>     
>>
>> What IVR situations can't just process the events out of the RTP stream
>> in order to find out what DTMF is being sent? I don't think this is a
>> compelling argument for either a) requiring clients to implement two
>> DTMF methods, or b) preventing DTMF interoperation between normal Jingle
>> and SIP endpoints unless the gateway does extra work.
>>
>>  
>>> Please also note that 4733 REQUIRES use of SRTP, where RFC 2833 doesn't.
>>> That's propably why most SIP devices still only claim support of 4733.
>>>     
>>
>> I think 2833-compliant endpoints can still exchange telephony events
>> with 4733-compliant endpoints. It'd be pretty broken if that wasn't the
>> case. And it doesn't REQUIRE the use of SRTP, it just says this:
>>
>>    To meet the need for protection both of confidentiality and
>>    integrity, compliant implementations SHOULD implement the Secure
>>    Real-time Transport Protocol (SRTP) [7].
>>
>> When we can signal SRTP, we'll probably say the same kind of thing
>> too. :D
>>
>>  
>>> /Olle
>>>     
>>
>> Regards,
>> Rob
>>   
> 
> 


From robert.mcqueen at collabora.co.uk  Wed Sep  3 19:51:20 2008
From: robert.mcqueen at collabora.co.uk (Robert McQueen)
Date: Thu, 04 Sep 2008 01:51:20 +0100
Subject: [Jingle] XEP-0181: Jingle DTMF
In-Reply-To: <488D20BB.4090201@stpeter.im>
References: <488672CF.7070403@collabora.co.uk> <488D20BB.4090201@stpeter.im>
Message-ID: <48BF3108.5030304@collabora.co.uk>

Peter Saint-Andre wrote:
>> [1]: If it involves not using RTP, I don't think we care. Something
>> which puts a non-RTP call over Jingle and wants to do DTMF can define
>> its own session info events. Any meaningful interoperability with Jingle
>> RTP clients is obviously completely dead in that case, so the inevitable
>> gateway could just convert RFC 4733 stuff into whatever the non-RTP
>> thing used, but whoever deviates from the norm gets to do the extra work.
> 
> As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
> use transports other than RTP, we might want to define a method for
> sending DTMF in the signalling channel. I agree that we could do that as
> session-info messages, but that's what XEP-0181 defines. (!) So perhaps
> it makes sense to let this gently lapse into deferred until someone
> needs it?

I still think it's best to make it very lapsed, because having two ways
to do it when RTP /is/ in use is pretty harmful I think. I think we
should put XEP-0181 on ice and instead just make it a MUST in the RTP
XEP that if you're doing DTMF, you use the RFC 4733 stuff. If we do fins
a stunningly important non-RTP content description that still needs us
to do gatewaying to PSTN and send DTMFs, we can cross that bridge when
we get to it. :)

> /psa

Regards,
Rob

From stpeter at stpeter.im  Wed Sep  3 21:22:51 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 03 Sep 2008 20:22:51 -0600
Subject: [Jingle] jingle summit/hackfest?
In-Reply-To: <48BF2251.1000909@collabora.co.uk>
References: <48BF2251.1000909@collabora.co.uk>
Message-ID: <48BF467B.1080905@stpeter.im>

Robert McQueen wrote:
> What do people think?

I think that sounds like a capital idea! When would you want to make it 
happen? I might be able to rope in some sponsors from the XSF side of 
things or have the XSF help out (speaking of which, I need to raise more 
money for the XSF so we can keep holding XMPP Summit meetings...).

Peter

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080903/1e351187/attachment.bin 

From paulrw at codian.com  Thu Sep  4 05:13:22 2008
From: paulrw at codian.com (Paul Witty)
Date: Thu, 04 Sep 2008 11:13:22 +0100
Subject: [Jingle] jingle summit/hackfest?
In-Reply-To: <48BF2251.1000909@collabora.co.uk>
References: <48BF2251.1000909@collabora.co.uk>
Message-ID: <48BFB4C2.7030607@codian.com>

Robert McQueen wrote:
> It'd be nice to get a couple of people from the major Jingle
> stakeholders (so the clients who are working on support, any
> device/server vendors looking to interoperate, etc) along. What do
> people think?
>
>   
I'd definitely be interested in participating.  I've not had a chance to 
work on Jingle stuff for a while (though I hope to do so in the 
not-to-distant future), and it seems like a good way to get the specs 
finalised and actually do a bit of interop testing.

-- 

Paul

From stpeter at stpeter.im  Tue Sep  9 20:55:21 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 09 Sep 2008 19:55:21 -0600
Subject: [Jingle] XEP-0181: Jingle DTMF
In-Reply-To: <48BF3108.5030304@collabora.co.uk>
References: <488672CF.7070403@collabora.co.uk> <488D20BB.4090201@stpeter.im>
	<48BF3108.5030304@collabora.co.uk>
Message-ID: <48C72909.8020604@stpeter.im>

Robert McQueen wrote:
> Peter Saint-Andre wrote:
>>> [1]: If it involves not using RTP, I don't think we care. Something
>>> which puts a non-RTP call over Jingle and wants to do DTMF can define
>>> its own session info events. Any meaningful interoperability with Jingle
>>> RTP clients is obviously completely dead in that case, so the inevitable
>>> gateway could just convert RFC 4733 stuff into whatever the non-RTP
>>> thing used, but whoever deviates from the norm gets to do the extra work.
>> As Diana points out, RFCs 2833/4733 are RTP-specific. If in Jingle we
>> use transports other than RTP, we might want to define a method for
>> sending DTMF in the signalling channel. I agree that we could do that as
>> session-info messages, but that's what XEP-0181 defines. (!) So perhaps
>> it makes sense to let this gently lapse into deferred until someone
>> needs it?
> 
> I still think it's best to make it very lapsed, because having two ways
> to do it when RTP /is/ in use is pretty harmful I think. I think we
> should put XEP-0181 on ice and instead just make it a MUST in the RTP
> XEP that if you're doing DTMF, you use the RFC 4733 stuff. If we do fins
> a stunningly important non-RTP content description that still needs us
> to do gatewaying to PSTN and send DTMFs, we can cross that bridge when
> we get to it. :)

I think Diana is saying that she has already arrived at that bridge and 
that she needs in-band DTMF for her application. Yes, we can say that if 
you're using RTP then do your DTMF signalling there. But if you're not 
using RTP then do your DTMF signalling via XEP-0181.

/psa

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080909/881558ac/attachment.bin 

From xmpp at mullercentral.com  Fri Sep 19 10:38:15 2008
From: xmpp at mullercentral.com (Jeff Muller)
Date: Fri, 19 Sep 2008 11:38:15 -0400
Subject: [Jingle] Combined audio + video
Message-ID: <gb0h19$tke$1@ger.gmane.org>

Hi,

I just wanted to be perfectly sure: when creating a session with _related_, 
combined audio + video, what is the structure?

Is it two content elements, each with their own (single) description tag? It 
doesn't seem to be explicitly stated in the base Jingle XEP, but from poking 
around the various related XEPs that's what I'm inferring.

To me, it would make sense that each _realated_ set of media would go into a 
single content element with multiple description elements. For example:

<content creator='initiator' name='person'>
  <description ... media='audio'>
    ...
  </description>
  <description ... media='video'>
    ...
  </description>
  <transport ... />
</content>
<content ... name='security-cam1'>
  <description ... media='video'>
  </description>
  <transport ... />
</content>


Anyway, the point is that I could see it being done either way. But what is 
correct with regard to the XEP?

Thanks,
Jeff 



From remko at el-tramo.be  Sun Sep 21 09:57:13 2008
From: remko at el-tramo.be (=?ISO-8859-1?Q?Remko_Tron=E7on?=)
Date: Sun, 21 Sep 2008 07:57:13 -0700
Subject: [Jingle] jingle summit/hackfest?
Message-ID: <133fd4c60809210757v6769ceddxce1dd6a4e1128d2b@mail.gmail.com>

Sorry for breaking this thread up, but I wasn't subcscribed when the
original post arrived.

> If people were interested in such an event I'd be willing for Collabora
> to look at organising the initial event, maybe here in Cambridge, and
> try and arrange some sponsorship for venue and travel accomodation as
> needed (or even sponsor a little from Collabora),

I would definitely be interested in participating for Psi, as we are
in the process of implementing Jingle ourselves. As a bonus, we are
planning on using farsight, so that would make it even more useful.

As for location: Cambridge works for me.

cheers,
Remko

From diana-liste at null.ro  Mon Sep 22 17:39:25 2008
From: diana-liste at null.ro (Diana Cionoiu)
Date: Tue, 23 Sep 2008 01:39:25 +0300
Subject: [Jingle] news
Message-ID: <48D81E9D.7030208@null.ro>

Hello boys & girls,

Any news on jingle. When are we gonna have added the necessary
modifications for PSTN discuses in Portland?

Diana


From stpeter at stpeter.im  Tue Sep 23 09:20:05 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 23 Sep 2008 08:20:05 -0600
Subject: [Jingle] news
In-Reply-To: <48D81E9D.7030208@null.ro>
References: <48D81E9D.7030208@null.ro>
Message-ID: <48D8FB15.3000009@stpeter.im>

Diana Cionoiu wrote:
> Hello boys & girls,
> 
> Any news on jingle. 

I need feedback from everyone on this list regarding the latest versions
of the specs. I'll review them this week, too -- I think there may be
some inconsistencies, the schemas need to be corrected, etc. Please take
some time to read the specs again so we can finalize them!

> When are we gonna have added the necessary
> modifications for PSTN discuses in Portland?

This week I will write initial versions of the early media and session
transfer specs, based on the discussions in Portland.

I also need to fix the file transfer spec, and see if the current specs
correctly document the session renegotiation flow we talked about.

Finally, we need to write the initial version of the "smoke-out"
protocol ("I'll share presence+caps if you will").

Anything else?

Let's get this done!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From stpeter at stpeter.im  Tue Sep 23 11:24:51 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 23 Sep 2008 10:24:51 -0600
Subject: [Jingle] Are We There Yet?
In-Reply-To: <48BF291A.3020806@collabora.co.uk>
References: <48A8D000.7000101@stpeter.im> <48BF291A.3020806@collabora.co.uk>
Message-ID: <48D91853.8080004@stpeter.im>

Thanks for the feedback. Updates below.

Robert McQueen wrote:
> Peter Saint-Andre wrote:
>> As far as I can see, we've incorporated all the consensus points from
>> the recent XMPP Summit into the core Jingle specs, so I wonder if they
>> are done now. Can we perhaps take the temperature of the list about
>> whether XEP-0166, XEP-0167, and XEP-0176 are ready to be advanced to
>> Draft? (AFAIK the only outstanding issue is to clean up the examples and
>> schemas a bit, but I can do that this week.)
> 
> I just skimmed 0166 and 0167 at least, and I think they look reasonably
> good now. The only stuff I have on my list that applies to the core XEP is:
> a) Allow doing content-add while a session is pending, provided we
> clarify that session-accept only accepts contents which were included in
> the session-initiate. This would let us do early media with an extra
> content, so it should just require a little tweak to XEP-0167 to say
> that's how it's done.
> b) Add an optional <thread> element to go in under <jingle> so that you
> can associate calls/file transfers/etc with an ongoing conversation, so
> that UIs which can present multiple interactions in the same window can
> relate these things when they are sent over the wire
> c) Add some more semantics to transport-replace, including a tie break
> in the case of two crossed-over replace actions (session initiator wins,
> responder should forget they even tried), and maybe explaining you can
> reply with a "content-remove" with a <reason> if the new transport
> doesn't work for you.

I'm working these into XEP-0166 now.

> I'm a bit behind on ICE, and particular how it turns up in SIP, but I
> also had a vague interop concern with XEP-0176, which is whether it has
> enough information in it that you can turn the ICE candidates into a
> SIP+ICE offer, and then deal gracefully with a SIP endpoint that doesn't
> understand the ICE parts? I seem to recall that SIP had ICE as extra
> lines in the offer, but that it also chose one of the most likely
> candidates to put in the "normal" place in case the other endpoint
> didn't do ICE. With XEP-0176, is there some way to reply to the ICE
> candidates to say that actually, you want to use just raw UDP on the
> wire, or does this actually rely on us doing a transport renegotiation
> to use the raw UDP transport XEP instead?

I need to investigate this further. Will post again when I have finished
with 166 and have moved on to 176. :)

>> Now, I know we need to work on some extensions. These are:
>>
>> 1. File transfer -- needs to be updated per the core specs.
> 
> I've got a lot to say on how we can put file transfer together.
> Unfortunately despite early skepticism, I'm now pretty sold on Google's
> concept of using HTTP over a stream transport, and using a reliability
> layer to multiplex streams over a datagram transport.
> 
> The reliability layer can be defined in a XEP which provided both a
> Jingle description to say "I'm a reliability layer" and a Jingle
> transport which can say "put me over the reliability layer content named
> 'foo', port 80". This means that a file transfer with a group of files
> can then just do a single ICE-UDP negotiation as the datagram transport
> for the reliability layer, and then include one content stanza for each
> file, with a description saying that HTTP is in use, and the path of the
> file is here, maybe with a thumbnail too. Something like:
> 
> <jingle ...>
>   <content name="reliability">
>     <description xmlns="...pseudo-tcp">
>     <transport xmlns="...ice-udp">
>       <candidate ...>
>     </transport>
>   </content>
>   <content name="file0">
>     <description xmlns="...http-file">
>       <desc>My cat!</desc>
>       <size>12345</size>
>       <path>/cat.jpg</path>
>       <thumbnail>/small-cat.jpg</thumbnail>
>     </description>
>     <transport xmlns="...pseudo-tcp">
>       <content>reliability</content>
>       <port>80</port>
>     </transport>
>   </content>
>   <content name="file1">
>     <description xmlns="...http-file">
>       <desc>My dog!</desc>
>       <size>67890</size>
>       <path>/dog.jpg</path>
>       <thumbnail>/small-dog.jpg</thumbnail>
>     </description>
>     <transport xmlns="...pseudo-tcp">
>       <content>reliability</content>
>       <port>80</port>
>     </transport>
>   </content>
> </jingle>
> 
> Besides being able to retreive thumbnails separately from the files
> themselves, and giving us a reasonable way to multiplex many files over
> one session, Justin Uberti from Google pointed out a big advantage with
> using HTTP over the reliability layer, which is that if you've got a
> relay server (like theirs) which can bridge TCP and pseudo-TCP over ICE,
> then a web client can just go for the TCP candidate straight away and
> HTTP it directly from http://relayserver:1234/cat.jpg.

You know, that does seem reasonable. But we'd still want/need the old
methods (even including IBB) as fallbacks, no? Or do we just scuttle the
old stuff?

>> 2. Early media.

I think early media is just a bit of text added to XEP-0167.

>> 3. Session transfer.

I think this is a new XEP.

>> 4. Presence sharing (not Jingle-specific).

This one is lower on my priority list, but I'll get to it.

> Additionally I'd like to see a XEP with a content
> description for miscellaneous existing stream protocols (so, VNC and
> stuff). I know I said I'd write it but, yeah... We didn't find an
> interested client for that, so it keeps slipping off the todo list atm.
> Maybe the same for datagrams too.

Go for it. :)

>> However, I don't think we need to have those done before we can advance
>> the core specs to Draft.
> 
> Seems fair.
> 
>> What do you all say?
> 
> Let's do it. Hopefully we'll have an updated implementation to match the
> current XEPs really really soon now (the guy just got back from his
> honeymoon :D), and any further feedback shouldn't be too major to just
> push into the XEP after it's gone Draft.

Super!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


From stpeter at stpeter.im  Tue Sep 23 12:42:33 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 23 Sep 2008 11:42:33 -0600
Subject: [Jingle] media='audio'
Message-ID: <48D92A89.4030203@stpeter.im>

XEP-0167 currently has examples like...

  <jingle>
    <content name='voice'>
      <description xmlns='urn:xmpp:tmp:jingle:apps:rtp' media='audio'>
        <payload-type.../>
      </description>
    </content>
  </jingle>

I see that the 'media' attribute is not yet well documented. It maps to
the "m=" line in SDP, as described here:

http://mail.jabber.org/pipermail/standards/2008-May/018925.html

I'll clarify that...

/psa


From dmeyer at tzi.de  Tue Sep 23 13:11:02 2008
From: dmeyer at tzi.de (Dirk Meyer)
Date: Tue, 23 Sep 2008 20:11:02 +0200
Subject: [Jingle] Are We There Yet?
In-Reply-To: <48D91853.8080004@stpeter.im> (Peter Saint-Andre's message of
	"Tue\, 23 Sep 2008 10\:24\:51 -0600")
References: <48A8D000.7000101@stpeter.im> <48BF291A.3020806@collabora.co.uk>
	<48D91853.8080004@stpeter.im>
Message-ID: <87skrq7mx5.fsf@phex.sachmittel.de>

Peter Saint-Andre wrote:
> Robert McQueen wrote:
>>> 1. File transfer -- needs to be updated per the core specs.
>> 
>> I've got a lot to say on how we can put file transfer together.
>> Unfortunately despite early skepticism, I'm now pretty sold on Google's
>> concept of using HTTP over a stream transport, and using a reliability
>> layer to multiplex streams over a datagram transport.

I'm not sure I understand this? You want to use HTTP over something
over UDP?

>> Besides being able to retreive thumbnails separately from the files
>> themselves, and giving us a reasonable way to multiplex many files over
>> one session, Justin Uberti from Google pointed out a big advantage with
>> using HTTP over the reliability layer, which is that if you've got a
>> relay server (like theirs) which can bridge TCP and pseudo-TCP over ICE,
>> then a web client can just go for the TCP candidate straight away and
>> HTTP it directly from http://relayserver:1234/cat.jpg.

I'm not sure I can follow all this? Is HTTP the transport or the
highest level protocol? Do you have some more details?

> You know, that does seem reasonable. But we'd still want/need the old
> methods (even including IBB) as fallbacks, no? Or do we just scuttle the
> old stuff?

HTTP over IBB maybe?

Just jumping in this discussion I want to add a feature request:
seeking in file transfer. Maybe I want to watch a video from my home
network and use XMPP to negotiate what file to play and how to open a
transport layer using Jingle. IBB is no option, but with a TURN server
or a direct connection transfering video is possible. Now I may want
to seek in the file like Flash does. So maybe we can add optional
chunks and byte positions in the stream and use the XMPP layer for
seeking.

1. Jingle negotiation
2. A requests movie.mpg
3. B sends 0 and 1MB of the movie
4. B sends 1 and 1MB of the movie
....
5. B sends 50 and 1MB of the movie
6. A says seek to 75
7. B sends 75 and 1MB of the movie

The bute position is required because it takes some time between
sending the seek and receiving the correct data. It doesn't matter if
the video stream is transmitted over TCP or with HTTP as extra
layer. Flash uses something similar:
http://en.wikipedia.org/wiki/Real_Time_Messaging_Protocol

I know there is a range header in HTTP but I would prefer to not open
a new connection for every seek. And yes, I know that there is RTSP
and RTP for stuff like that, but IMHO using TCP for streaming is the
better choice in this case. Realtime is not important, getting all
packages is.

Maybe this belongs into the file transfer XEP, maybe it is an extra
XEP.


Dirk

-- 
A man generally has two reasons for doing a thing. One that sounds
good, and a real one.

From stpeter at stpeter.im  Tue Sep 23 16:29:07 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Tue, 23 Sep 2008 15:29:07 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0166 (Jingle)]
Message-ID: <48D95FA3.4030306@stpeter.im>

FYI.

Now moving on to XEP-0167...

/psa

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Tue, 23 Sep 2008 16:21:30 -0500
Subject: [Standards] UPDATED: XEP-0166 (Jingle)

Version 0.30 of XEP-0166 (Jingle) has been released.

Abstract: This specification defines an XMPP protocol extension for
initiating and managing peer-to-peer media sessions between two XMPP
entities in a way that is interoperable with existing Internet
standards. The protocol provides a pluggable model that enables the core
session management semantics to be used for a wide variety of
application types (e.g., voice chat, video chat, file sharing) and with
a wide variety of transport methods (e.g., TCP, UDP, ICE,
application-specific transports).

Changelog: [See revision history] (ram/psa)

Diff: http://is.gd/31Jk

URL: http://www.xmpp.org/extensions/xep-0166.html



From olivier.crete at collabora.co.uk  Tue Sep 23 16:58:01 2008
From: olivier.crete at collabora.co.uk (Olivier =?ISO-8859-1?Q?Cr=EAte?=)
Date: Tue, 23 Sep 2008 17:58:01 -0400
Subject: [Jingle] Replacing codec parameters and content-modify/replace
In-Reply-To: <48BF1D0E.8060206@collabora.co.uk>
References: <1219473152.15807.14.camel@TesterBox.tester.ca>
	<48BF1D0E.8060206@collabora.co.uk>
Message-ID: <1222207081.16776.26.camel@TesterTop3.tester.ca>

Sorry for being so slow on the replying..g

On Thu, 2008-09-04 at 00:26 +0100, Robert McQueen wrote:
> Olivier Cr?te wrote:
> > Codecs like Theora, Vorbis and H.264 need a header to be received before
> > any media can be decoded. The ideal way to reliably transmit that header
> > is in the signalling. To produce that header for some codecs (including
> > Vorbis and Theora), you often want to initialize the encoder and pass
> > one buffer through it.
> > 
> > This becomes problematic if you want to start a recv-only call and later
> > activate sending. With SIP, what I'd do is first send SDP without the
> > header and later when I want to start sending, send it in the updated
> > SDP as part of the re-invite. Maybe we could do the same with
> > content-modify, being able to send a new <definition> block with updated
> > parameters?
> 
> Starting a recv-only call is pretty weird though, isn't it? Isn't the
> initiator always going to want to originate media, and the responder
> then may or may not decide they want to reply with media too. What I'm
> getting at is: Does this require a full renegotiation with a new SDP
> offer and a new answer, or does it really just require an updated answer
> to the original offer?

Its exactly the same if you receive a call (its recv-only to you). A
Full renegotiation mostly means sending a SDP and receiving a new one.
But well, the state is kept, so the new answer should really be an
updated answer to the initial one (or an update to the initial offer is
the re-negotiation is triggered by the callee).

> I'm not sure about including new <definition> blocks in a
> "content-modify", as it overloads the semantics somewhat, and makes it
> ambiguous what modifications you do/don't have to respect/look out for
> in this action. If we /do/ want to do things like updating/replacing the
> codec descriptions, maybe we want "description-info" or maybe even
> "description-replace"/"description-accept", but this really terrifies me.

Calling is description-replace/accept or whatever is the same to me.
Don't be terrified!

> > This also applies if the header changes mid-stream (lets say I want to
> > dynamically change the source in the case of a server-brokered
> > multi-conference). We also need to modify the SDP.
> 
> If we're going for a full general purpose re-negotiation I'd much rather
> try and push it into making a new content and removing the old one when
> it's set up, rather than adding a whole load of hooks/extra semantics
> into Jingle to deal with these situations. This avoids various issues
> with crossed-over offers (contents are named uniquely by either the
> initiator or responder) and gives an unambiguous ordering and indication
> of who needs to start/stop which stream when.
>
> The cost is that you might be forced into doing more transport
> renegotiation than you wanted to, but I think that these renegotiation
> cases are quite rare. There's a big benefit in any reasonably coded
> Jingle client to making the state machine per stream as simple as
> possible, and just running multiple instances of it if necessary, rather
> than ending up with a baby copy of the SIP transactional engine in every
> Jingle client. :/

I see re-doing the transport as a no-go. If you have a relay, it means
allocation new ports, opening more ports in the firewall, disrupting the
call, etc, etc. It seems really wasteful. All I'm asking is to resend a
few lines of text... I don't see why it scares you so much. And I'm not
sure how it will make the state machine so much more complicated (one
side sends a "replace"... waits for accept or refuse.. if accept if can
forget about it, if refuse, you end the stream).

-- 
Olivier Cr?te
olivier.crete at collabora.co.uk
Collabora Ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://mail.jabber.org/pipermail/jingle/attachments/20080923/938f4099/attachment.pgp 

From arv.3g8pln at no-mx.jabberforum.org  Wed Sep 24 06:42:09 2008
From: arv.3g8pln at no-mx.jabberforum.org (arv)
Date: Wed, 24 Sep 2008 13:42:09 +0200
Subject: [Jingle] Flash Client for webchat
Message-ID: <arv.3g8pln@no-mx.jabberforum.org>


Hello everyone,

i'm totally new 2 jabber. i'v setup openfire and used the jeti client
with it. My client wants to use flash to develop a chat application with
video. Iv tried xiffian but connection to the server fails. I also need
to restrict presence information or some users. Can anyone direct me as
to how to start and how this can be done? Has anyone used the as3xmpp
libraries or xiff libraries?

While browsing i have got the impression that jingle does not implement
sending of video stream, but is only used for the signalling. Is that
correct? if so, how do i send a video stream using jingle and jabber?

any help will be greatly appreciated,
Thanks,
Arv.


-- 
arv
------------------------------------------------------------------------
arv's Profile: http://www.jabberforum.org/member.php?userid=17275
View this thread: http://www.jabberforum.org/showthread.php?t=797


From xmpp at mullercentral.com  Wed Sep 24 07:58:19 2008
From: xmpp at mullercentral.com (Jeff Muller)
Date: Wed, 24 Sep 2008 08:58:19 -0400
Subject: [Jingle] Combined audio + video
In-Reply-To: <gb0h19$tke$1@ger.gmane.org>
References: <gb0h19$tke$1@ger.gmane.org>
Message-ID: <gbddhj$j7g$1@ger.gmane.org>

Should this question go in the standards-jig group???

"Jeff Muller" <xmpp at mullercentral.com> wrote 
in message news:gb0h19$tke$1 at ger.gmane.org...
> Hi,
>
> I just wanted to be perfectly sure: when creating a session with 
> _related_, combined audio + video, what is the structure?
>
> Is it two content elements, each with their own (single) description tag? 
> It doesn't seem to be explicitly stated in the base Jingle XEP, but from 
> poking around the various related XEPs that's what I'm inferring.
>
> To me, it would make sense that each _realated_ set of media would go into 
> a single content element with multiple description elements. For example:
>
> <content creator='initiator' name='person'>
>  <description ... media='audio'>
>    ...
>  </description>
>  <description ... media='video'>
>    ...
>  </description>
>  <transport ... />
> </content>
> <content ... name='security-cam1'>
>  <description ... media='video'>
>  </description>
>  <transport ... />
> </content>
>
>
> Anyway, the point is that I could see it being done either way. But what 
> is correct with regard to the XEP?
>
> Thanks,
> Jeff
>
> 



From stpeter at stpeter.im  Wed Sep 24 08:56:19 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 24 Sep 2008 07:56:19 -0600
Subject: [Jingle] Combined audio + video
In-Reply-To: <gbddhj$j7g$1@ger.gmane.org>
References: <gb0h19$tke$1@ger.gmane.org> <gbddhj$j7g$1@ger.gmane.org>
Message-ID: <48DA4703.9020208@stpeter.im>

No, this is the right list. A <content/> element can contain only one
<description/> element (this is specified in XEP-0166), so you need two
<content/> elements for audio+video. Do you not see examples of
audio+video in XEP-0167? I'll be reviewing that one today, so I'll
double-check.

Jeff Muller wrote:
> Should this question go in the standards-jig group???
> 
> "Jeff Muller" <xmpp at mullercentral.com> wrote in message
> news:gb0h19$tke$1 at ger.gmane.org...
>> Hi,
>>
>> I just wanted to be perfectly sure: when creating a session with
>> _related_, combined audio + video, what is the structure?
>>
>> Is it two content elements, each with their own (single) description
>> tag? It doesn't seem to be explicitly stated in the base Jingle XEP,
>> but from poking around the various related XEPs that's what I'm
>> inferring.
>>
>> To me, it would make sense that each _realated_ set of media would go
>> into a single content element with multiple description elements. For
>> example:
>>
>> <content creator='initiator' name='person'>
>>  <description ... media='audio'>
>>    ...
>>  </description>
>>  <description ... media='video'>
>>    ...
>>  </description>
>>  <transport ... />
>> </content>
>> <content ... name='security-cam1'>
>>  <description ... media='video'>
>>  </description>
>>  <transport ... />
>> </content>
>>
>>
>> Anyway, the point is that I could see it being done either way. But
>> what is correct with regard to the XEP?
>>
>> Thanks,
>> Jeff
>>
>>
> 
> 


From stpeter at stpeter.im  Wed Sep 24 10:09:58 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Wed, 24 Sep 2008 09:09:58 -0600
Subject: [Jingle] Flash Client for webchat
In-Reply-To: <arv.3g8pln@no-mx.jabberforum.org>
References: <arv.3g8pln@no-mx.jabberforum.org>
Message-ID: <48DA5846.9080907@stpeter.im>

arv wrote:

> While browsing i have got the impression that jingle does not implement
> sending of video stream, but is only used for the signalling. Is that
> correct? if so, how do i send a video stream using jingle and jabber?

Correct, the core Jingle spec (XEP-0166) covers only the signalling. To
send video, you would use RTP (XEP-0167). As far as I know, most
developers are working on audio, not video, so I don't know which
projects you might be able to test with.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


From arv.3g9hkb at no-mx.jabberforum.org  Wed Sep 24 16:46:19 2008
From: arv.3g9hkb at no-mx.jabberforum.org (arv)
Date: Wed, 24 Sep 2008 23:46:19 +0200
Subject: [Jingle] Flash Client for webchat
References: <arv.3g8pln@no-mx.jabberforum.org> <48DA5846.9080907@stpeter.im>
Message-ID: <arv.3g9hkb@no-mx.jabberforum.org>


Peter Saint-Andre;3716 Wrote: 
> arv wrote:
> 
> > While browsing i have got the impression that jingle does not
> implement
> > sending of video stream, but is only used for the signalling. Is
> that
> > correct? if so, how do i send a video stream using jingle and
> jabber?
> 
> Correct, the core Jingle spec (XEP-0166) covers only the signalling.
> To
> send video, you would use RTP (XEP-0167). As far as I know, most
> developers are working on audio, not video, so I don't know which
> projects you might be able to test with.
> 
> 

Hi Peter,
Thanks for the prompt reply. I can see from some recent posts that
therz a lot still going on with jingle. Is there anything i should be
aware of while building a video client? which actionscript library would
u advise for video? 

When u say "developers are working on audio, not video" do you mean
there are few/no libraries that implement jingle video transfer yet? Or
is it that the libraries for video transfer are available but not in any
current projects?

thanks,
Arv.


-- 
arv
------------------------------------------------------------------------
arv's Profile: http://www.jabberforum.org/member.php?userid=17275
View this thread: http://www.jabberforum.org/showthread.php?t=797


From paulrw at codian.com  Thu Sep 25 05:10:42 2008
From: paulrw at codian.com (Paul Witty)
Date: Thu, 25 Sep 2008 11:10:42 +0100
Subject: [Jingle] Flash Client for webchat
In-Reply-To: <arv.3g9hkb@no-mx.jabberforum.org>
References: <arv.3g8pln@no-mx.jabberforum.org> <48DA5846.9080907@stpeter.im>
	<arv.3g9hkb@no-mx.jabberforum.org>
Message-ID: <48DB63A2.8020606@codian.com>

arv wrote:
> Peter Saint-Andre;3716 Wrote: 
>   
>> arv wrote:
>>
>>     
>>> While browsing i have got the impression that jingle does not
>>>       
>> implement
>>     
>>> sending of video stream, but is only used for the signalling. Is
>>>       
>> that
>>     
>>> correct? if so, how do i send a video stream using jingle and
>>>       
>> jabber?
>>
>> Correct, the core Jingle spec (XEP-0166) covers only the signalling.
>> To
>> send video, you would use RTP (XEP-0167). As far as I know, most
>> developers are working on audio, not video, so I don't know which
>> projects you might be able to test with.
>>
>>
>>     
>
> Hi Peter,
> Thanks for the prompt reply. I can see from some recent posts that
> therz a lot still going on with jingle. Is there anything i should be
> aware of while building a video client? which actionscript library would
> u advise for video? 
>
> When u say "developers are working on audio, not video" do you mean
> there are few/no libraries that implement jingle video transfer yet? Or
> is it that the libraries for video transfer are available but not in any
> current projects?
>
>
>   
As far as I know, I'm the only person working on video transfer.  I have 
an implementation up and running which can send video to itself, but it 
is lagging slightly behind the latest spec, and only supports H.261 and 
H.263 at present (not the recommended Theora).

-- 

Paul


From arv.3gakvb at no-mx.jabberforum.org  Thu Sep 25 06:55:25 2008
From: arv.3gakvb at no-mx.jabberforum.org (arv)
Date: Thu, 25 Sep 2008 13:55:25 +0200
Subject: [Jingle] Flash Client for webchat
References: <arv.3g8pln@no-mx.jabberforum.org>
	<48DA5846.9080907@stpeter.im><arv.3g9hkb@no-mx.jabberforum.org>
	<48DB63A2.8020606@codian.com>
Message-ID: <arv.3gakvb@no-mx.jabberforum.org>


Thanks for the reply Paul.

On which language are u working? Any reasons for your program sending
data to itself? would you mind posting sum usable code or just givin a
rough guide on how to proceed?

Thanks,
Arv


-- 
arv
------------------------------------------------------------------------
arv's Profile: http://www.jabberforum.org/member.php?userid=17275
View this thread: http://www.jabberforum.org/showthread.php?t=797


From paulrw at codian.com  Thu Sep 25 07:04:49 2008
From: paulrw at codian.com (Paul Witty)
Date: Thu, 25 Sep 2008 13:04:49 +0100
Subject: [Jingle] Flash Client for webchat
In-Reply-To: <arv.3gakvb@no-mx.jabberforum.org>
References: <arv.3g8pln@no-mx.jabberforum.org>	<48DA5846.9080907@stpeter.im><arv.3g9hkb@no-mx.jabberforum.org>	<48DB63A2.8020606@codian.com>
	<arv.3gakvb@no-mx.jabberforum.org>
Message-ID: <48DB7E61.3040204@codian.com>

arv wrote:
> Thanks for the reply Paul.
>
> On which language are u working? Any reasons for your program sending
> data to itself? would you mind posting sum usable code or just givin a
> rough guide on how to proceed?
>   

I'm working in C++, on dedicated hardware (doing a Jingle to H.323/SIP 
gateway).  Unfortunately, this means everything is implemented from the 
ground up and closed source, and so not using any available libraries, 
or writing any for others to use.

The reason it only makes video calls to itself is because there's 
nothing else to make video calls to.  It would be nice to make a video 
call to something else; unfortunately there is nothing else!

-- 

Paul

From stpeter at stpeter.im  Thu Sep 25 11:30:48 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 10:30:48 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0166 (Jingle)]
Message-ID: <48DBBCB8.8040405@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Thu, 25 Sep 2008 11:27:26 -0500
Subject: [Standards] UPDATED: XEP-0166 (Jingle)

Version 0.31 of XEP-0166 (Jingle) has been released.

Abstract: This specification defines an XMPP protocol extension for
initiating and managing peer-to-peer media sessions between two XMPP
entities in a way that is interoperable with existing Internet
standards. The protocol provides a pluggable model that enables the core
session management semantics to be used for a wide variety of
application types (e.g., voice chat, video chat, file sharing) and with
a wide variety of transport methods (e.g., TCP, UDP, ICE,
application-specific transports).

Changelog: Added disposition attribute to content element for mapping to
SIP Content-Disposition header. (psa)

Diff: http://is.gd/37MA

URL: http://www.xmpp.org/extensions/xep-0166.html



From stpeter at stpeter.im  Thu Sep 25 11:31:15 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 10:31:15 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0167 (Jingle RTP Sessions)]
Message-ID: <48DBBCD3.7010106@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Thu, 25 Sep 2008 11:27:51 -0500
Subject: [Standards] UPDATED: XEP-0167 (Jingle RTP Sessions)

Version 0.24 of XEP-0167 (Jingle RTP Sessions) has been released.

Abstract: This specification defines a Jingle application type for
negotiating one or more sessions that use the Real-time Transport
Protocol (RTP) to exchange media such as voice or video. The application
type includes a straightforward mapping to Session Description Protocol
(SDP) for interworking with SIP media endpoints.

Changelog: [See revision history] (psa/dc)

Diff: http://is.gd/37MC

URL: http://www.xmpp.org/extensions/xep-0167.html



From stpeter at stpeter.im  Thu Sep 25 11:37:47 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 10:37:47 -0600
Subject: [Jingle] early media
Message-ID: <48DBBE5B.3050005@stpeter.im>

OK, I've added text and examples about early media to XEP-0167, based on
our discussions in Portland:

http://www.xmpp.org/extensions/xep-0167.html#earlymedia

http://www.xmpp.org/extensions/xep-0167.html#scenarios-earlymedia

As far as I can see (cf. also RFCs 3959 and 3960), this necessitated the
addition of a 'disposition' attribute to the core Jingle <content/> element:

http://www.xmpp.org/extensions/xep-0166.html#def-content

If you disagree with what I've done, please complain to the list. :)

Next up: XEPs 176 and 177.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


From stpeter at stpeter.im  Thu Sep 25 12:19:12 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 11:19:12 -0600
Subject: [Jingle] Are We There Yet?
In-Reply-To: <48BF291A.3020806@collabora.co.uk>
References: <48A8D000.7000101@stpeter.im> <48BF291A.3020806@collabora.co.uk>
Message-ID: <48DBC810.40206@stpeter.im>

Robert McQueen wrote:

> I'm a bit behind on ICE, and particular how it turns up in SIP, but I
> also had a vague interop concern with XEP-0176, which is whether it has
> enough information in it that you can turn the ICE candidates into a
> SIP+ICE offer, and then deal gracefully with a SIP endpoint that doesn't
> understand the ICE parts? I seem to recall that SIP had ICE as extra
> lines in the offer, but that it also chose one of the most likely
> candidates to put in the "normal" place in case the other endpoint
> didn't do ICE. With XEP-0176, is there some way to reply to the ICE
> candidates to say that actually, you want to use just raw UDP on the
> wire, or does this actually rely on us doing a transport renegotiation
> to use the raw UDP transport XEP instead?

Here's how I see it.

Jingle clients are smart, so they use ICE (Google Talk does anyway, and
everyone wants to interoperate with Google Talk, right?). The Raw UDP
transport is like the "I'm feeling lucky" transport: you put in there
the candidate that you consider most likely to succeed. That candidate
is also the first candidate you'll send under ICE. So for
Jingle-to-Jingle communication I don't think we'll use Raw UDP at all.

Things are a bit more complicated for Jingle-to-SIP communication,
because as you point out the SIP endpoint might not do ICE. However, the
signalling is going to pass through a gateway. So IMHO the gateway needs
to have the intelligence to handle the case you mention. The scenario I
envision is this:

1. Jingle endpoint sends session-initiate with ICE-UDP transport.

2. Gateway forwards request to SIP endpoint.

3. Gateway determines that SIP endpoint doesn't do ICE.

4. On behalf of SIP endpoint, gateway sends content-add to switch
transport from ICE to Raw UDP and content-remove to get rid of the
ICE-UDP transport. Probably this means that the gateway will function as
a media relay, so it knows that the candidate it proposes will work.
Simultaneously, gateway sends appropriate SIP re-INVITE to SIP endpoint.

5. Jingle endpoint accepts use of Raw UDP, SIP endpoint accepts
re-INVITE, and everyone uses the gateway's media relay.

Maybe this can be simplified (if the gateway has capabilities
information about the SIP endpoint, it can immediately switch from
ICE-UDP to Raw UDP without discovering the lack of ICE support on the
SIP side "the hard way").

Or maybe this is unrealistic -- will Jingle-to-SIP gateways really run
media relays for use by older SIP endpoints? I don't know enough about
the SIP side of the equation to say that definitively.

Anyway, that's how I see it right now -- I'm quite open to being
corrected. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/


From stpeter at stpeter.im  Thu Sep 25 14:47:00 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 13:47:00 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0177 (Jingle Raw UDP
	Transport Method)]
Message-ID: <48DBEAB4.7020704@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Thu, 25 Sep 2008 14:46:21 -0500
Subject: [Standards] UPDATED: XEP-0177 (Jingle Raw UDP Transport Method)

Version 0.10 of XEP-0177 (Jingle Raw UDP Transport Method) has been
released.

Abstract: This specification defines a Jingle transport method that
results in sending media data using raw datagram sockets via the User
Datagram Protocol (UDP). This simple transport method does not provide
NAT traversal, and the ICE-UDP transport method should be used if NAT
traversal is required.

Changelog: [See revision history] (psa)

Diff: http://is.gd/38nG

URL: http://www.xmpp.org/extensions/xep-0177.html



From stpeter at stpeter.im  Thu Sep 25 16:00:56 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 15:00:56 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0176 (Jingle ICE-UDP
	Transport Method)]
Message-ID: <48DBFC08.4040905@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Thu, 25 Sep 2008 16:00:11 -0500
Subject: [Standards] UPDATED: XEP-0176 (Jingle ICE-UDP Transport Method)

Version 0.21 of XEP-0176 (Jingle ICE-UDP Transport Method) has been
released.

Abstract: This specification defines a Jingle transport method that
results in sending media data using raw datagram sockets via the User
Datagram Protocol (UDP). This transport method is negotiated via the
Interactive Connectivity Establishment (ICE) methodology defined by the
IETF and thus provides robust NAT traversal for media traffic.

Changelog: [See revision history] (psa)

Diff: http://is.gd/38yX

URL: http://www.xmpp.org/extensions/xep-0176.html



From stpeter at stpeter.im  Thu Sep 25 16:42:08 2008
From: stpeter at stpeter.im (Peter Saint-Andre)
Date: Thu, 25 Sep 2008 15:42:08 -0600
Subject: [Jingle] [Fwd: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)]
Message-ID: <48DC05B0.9060205@stpeter.im>

FYI.

-------- Original Message --------
From: XMPP Extensions Editor <editor at xmpp.org>
To: standards at xmpp.org
Date: Thu, 25 Sep 2008 16:41:06 -0500
Subject: [Standards] UPDATED: XEP-0234 (Jingle File Transfer)

Version 0.7 of XEP-0234 (Jingle File Transfer) has been released.

Abstract: This specification defines a Jingle application type for
transferring files between two entities. The protocol provides a modular
framework that enables the exchange of information about the file to be
transferred as well as the negotiation of parameters such as the
transport to be used.

Changelog: [See revision history] (psa)

Diff: http://is.gd/38FM

URL: http://www.xmpp.org/extensions/xep-0234.html



From arv.3gc95c at no-mx.jabberforum.org  Fri Sep 26 04:37:09 2008
From: arv.3gc95c at no-mx.jabberforum.org (arv)
Date: Fri, 26 Sep 2008 11:37:09 +0200
Subject: [Jingle] Flash Client for webchat
References: <arv.3g8pln@no-mx.jabberforum.org>	<48DA5846.9080907@stpeter.im><arv.3g9hkb@no-mx.jabberforum.org>	<48DB63A2.8020606@codian.com><arv.3gakvb@no-mx.jabberforum.org>
	<48DB7E61.3040204@codian.com>
Message-ID: <arv.3gc95c@no-mx.jabberforum.org>


Ok. Well thanks Paul.

I guess i'll have to work with the XEP specs n implement video with
xiff or as3xmpp. Any advice on it?

Thnx,
Arv


-- 
arv
------------------------------------------------------------------------
arv's Profile: http://www.jabberforum.org/member.php?userid=17275
View this thread: http://www.jabberforum.org/showthread.php?t=797


From bogus@does.not.exist.com  Tue Sep 23 07:25:05 2008
From: bogus@does.not.exist.com ()
Date: Tue, 23 Sep 2008 12:25:05 -0000
Subject: No subject
Message-ID: <mailman.5.1233396842.3753.jingle@xmpp.org>

seems that Theora (both spec-wise and implementation-wise) is strongly
lacking behind h.264 and its implementations (e.g. x264). Not to mention
the possibility of SVC
(http://en.wikipedia.org/wiki/Scalable_Video_Coding) in the future.

After all, you want to deliver the best user experience, not only in
the NAT traversal field but also in video quality and coding efficiency.
Why would people use new or inferior technology if they can continue
using Sk*pe, right? (No, most of them don't care about open standards,
but what the software can really do.)

Also, don't forget that the USA are NOT the whole world and software
patents are not valid everywhere.

(The world would be much nicer place without software patents and such
widespread NAT usage?)

Regards,
Luk?? 'spike411' Pol?vka


-- 
spike411
------------------------------------------------------------------------
spike411's Profile: http://www.jabberforum.org/member.php?userid=17075
View this thread: http://www.jabberforum.org/showthread.php?t=1382