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

Peter Saint-Andre stpeter at jabber.org
Mon Oct 30 19:20:29 UTC 2006


I was (mostly) joking...

Thiago Rocha Camargo wrote:
> 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
>>>>>>>>>
>>>>>>>>>                 
-------------- 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/f22093d0/attachment.bin>


More information about the Standards mailing list