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

Thiago Rocha Camargo thiago at jivesoftware.com
Mon Oct 30 18:18:29 UTC 2006


Nice idea,

But I´ll focus in ICE, because we can reduce the usage of the Media Proxy.

Peter Saint-Andre escreveu:
> 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
>>>>>>>>
>>>>>>>>                 




More information about the Standards mailing list