[Standards-JIG] Smack Jingle Development - XEP for Media Proxy negociation

Peter Saint-Andre stpeter at jabber.org
Mon Oct 30 18:53:02 UTC 2006


Sure, it's cool if an XMPP server offers the RTP bridge as an extra
service, since we already have the signalling channel open. But it
doesn't have to be my "home" server that does this, right? I mean, it's
quite similar to SOCKS5 Bytestreams, no?

But hey, if we really want to simplify things, the XMPP client could
tell its server that it wants to set up a media session with a contact
and the server would do all the hard work of session establishment. :-)


Thiago Rocha Camargo wrote:
> Hello Peter,
> 
> As we know, sometimes STUN isn´t enough for ICE. And sometimes we have
> networks with STUN blocked.
> So we need a Media Proxy to establish the media between parties.
> 
> I´m our implementation I´ll add an ICE candidate get from the Media
> Proxy set in XMPP server.
> XMPP server will have a service that generates and bind a candidate for
> the user who requests it.
> 
> Entity Requests a candidate from Host
> <iq type='get' id='cand1'>
>  <rtpbridge xmlns='http://www.jivesoftware.com/protocol/rtpbridge'>
>    <candidate/>
>  </rtpbridge >
> </iq>
> 
> Host Returns Current Registration to Entity
> <iq type='result' id='cand1'>
>  <rtpbridge xmlns='http://www.jivesoftware.com/protocol/rtpbridge'>    
> <candidate name='myvoicedata' ip='200.10.11.104' port='13540'
> generation='0'/>
>  </rtpbridge >
> </iq>
> 
> This way a NAT and firewallled network can reach another party passing
> through a Media Bridge with stable and rport working.
> 
> Let me know if you have another suggestion to make 2 parties talk each
> other if they are behind different firewalls and NATs. And have STUN
> Service blocked :)
> 
> Regards,
> Thiago
> 
> Peter Saint-Andre escreveu:
>> What does the XMPP server know about media candidates? It's (mostly)
>> just an XML router. Since you're already talking to a STUN server for
>> ICE, it makes sense to get your media candidates from the STUN server
>> (i.e., via TURN), not from the XMPP server.
>>
>> Thiago Rocha Camargo wrote:
>>  
>>> I´m writing a draft about it. It´s very small. Just request a media
>>> candidate from XMPP server. I think it should work fine, as it will
>>> behave as ICE XEP expects.
>>> Hope I send the draft soon.
>>>
>>> For more information about it. Check:
>>>
>>> http://antecipate.blogspot.com/2006/10/jingle-media-relaying.html.
>>>
>>>
>>> Scott Ludwig escreveu:
>>>    
>>>> I believe he wants to know the protocol that Jingle uses to allocate
>>>> and use a relay session from a relay server (to be used in the case
>>>> where a direct peer to peer connection is not possible). That
>>>> currently is not documented. It does need documentation in the Jingle
>>>> series XEPs.
>>>>
>>>> I'll refer you to the libjingle source code for how Google Talk
>>>> currently does this. However we'd like to see movement towards TURN as
>>>> a standard.
>>>>
>>>> On 10/26/06, Peter Saint-Andre <stpeter at jabber.org> wrote:
>>>>      
>>>>> I think you want to build a STUN server. See RFC 3489 for details.
>>>>> There
>>>>> are several open-source STUN servers in existence, and I think you can
>>>>> also use libjingle to run a media relay (but I don't think that the
>>>>> relay is STUN-compliant).
>>>>>
>>>>> Thiago Rocha Camargo wrote:
>>>>>        
>>>>>> Hello  Jean-Louis,
>>>>>>
>>>>>> The proxy that I intend to do. It is just a Media Proxy to help in
>>>>>> NAT
>>>>>> Traversal issues.
>>>>>>
>>>>>> So the proxy will just ACT as intermediary actor in the calling.
>>>>>>
>>>>>>                       |             |
>>>>>> |                     |                       |          |
>>>>>> Jingle Client ---|  NAT  | ------------| Media Proxy
>>>>>> |---------------|
>>>>>> NAT | --- Jingle Client B
>>>>>>        A            |             |
>>>>>> |                      |                      |          |
>>>>>>
>>>>>> And for the first moment I intend to use RAW-UDP for the transport.
>>>>>>
>>>>>> For Voice Mail Proxy I understand that the Proxy must act as a
>>>>>>           
>>>>> standard
>>>>>        
>>>>>> Jingle client, but for a RTP Redirection Media Proxy, I didn´t see
>>>>>> any
>>>>>> XEP describing such behavior.
>>>>>>
>>>>>> Regards,
>>>>>> Thiago
>>>>>>
>>>>>> Jean-Louis Seguineau escreveu:
>>>>>>          
>>>>>>> Hi Thiago,
>>>>>>>
>>>>>>> You may want to further define what you call "media proxy", as
>>>>>>>             
>>>>> this may
>>>>>        
>>>>>>> cover many use cases ;) It could be a proxy to a streaming
>>>>>>>             
>>>>> service, to a
>>>>>        
>>>>>>> voice mail service, to a voice gateway service, etc... plus all the
>>>>>>> equivalent for video.
>>>>>>>
>>>>>>> If your proxy offers one of the existing media described amongst the
>>>>>>> jingle
>>>>>>> XEPs, this is all you would need for the proxy to communicate with a
>>>>>>> jingle
>>>>>>> client. For example, if you want to offer a voice mail proxy
>>>>>>> service,
>>>>>>> then
>>>>>>> the proxy itself must implement XEP-166, XEP-167 as it will be a
>>>>>>>             
>>>>> voice
>>>>>        
>>>>>>> proxy, and XEP-176, XEP-177 to negotiate the appropriate
>>>>>>>             
>>>>> transport. You
>>>>>        
>>>>>>> would then set a redirect with the voice mail proxy service JID in
>>>>>>>             
>>>>> your
>>>>>        
>>>>>>> Jingle client. When the client receives a call initiation
>>>>>>> request, it
>>>>>>> will
>>>>>>> then redirect the negotiation to the proxy, and from then on the
>>>>>>>             
>>>>> proxy
>>>>>        
>>>>>>> will
>>>>>>> act as a Jingle client.
>>>>>>>
>>>>>>> That said, you will always have to provide discovery of the proxy's
>>>>>>> features, and we'll have to add disco categories and features to the
>>>>>>> registrar.  But as long as the proxy itself implements the Jingle
>>>>>>> XEPs, you do not need
>>>>>>> anything else to negotiate a proxy session for the type of media
>>>>>>> described
>>>>>>> in the XEP. Obviously, if the proxy provides a service which have
>>>>>>>             
>>>>> not yet
>>>>>        
>>>>>>> been defined by an XEP, such as voice or video streaming, we'll
>>>>>>>             
>>>>> have to
>>>>>        
>>>>>>> write the relevant XEPs first.
>>>>>>>
>>>>>>> Hope this helps
>>>>>>>
>>>>>>> Jean-Louis
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> Date: Tue, 24 Oct 2006 16:44:51 -0200
>>>>>>> From: Thiago Rocha Camargo <thiago at jivesoftware.com>
>>>>>>> Subject: [Standards-JIG] Smack Jingle Development - XEP for Media
>>>>>>>     Proxy    negociation
>>>>>>> To: Jabber protocol discussion list <standards-jig at jabber.org>
>>>>>>> Message-ID: <453E5F23.7040202 at jivesoftware.com>
>>>>>>> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>>>>>>>
>>>>>>> Hello guys,
>>>>>>>
>>>>>>> Here in Jive, we are working on Smack Jingle extension API. The
>>>>>>> first
>>>>>>> Pure Java Jingle API.
>>>>>>>
>>>>>>> We start to thinking about the first Media Proxy in Java.
>>>>>>> And we want to know if  is there a standard that describes a Media
>>>>>>> Proxy Session establishment?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Thiago
>>>>>>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20061030/948585ff/attachment.bin>


More information about the Standards mailing list