[Standards-JIG] Jingle relaying or proxying

[Thiago Rocha Camargo]

Jean-Louis,

I can see several reasons to use the <relay> node:

<iq to='jingle.capulet.com/balcony' from='romeo at montague.net/orchard'
  id='jingle1' type='set'>
  <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo at montague.net/orchard'
          sid='a73sjjvkla37jfea'>
       *<relay>juliet at capulet.com/balcony</relay>*
       <content name='this-is-the-audio-content'>
       ...
	 </content>
</iq>


* It´s valid to say that the <relay> node will be more clear. Since it 
belongs to Jingle´s session it transmit the idea of a Jingle Relay, not 
a IQ foward...

* With various <relay> nodes the Media Proxy could work and behave as a 
Multi User Call Server. (Conference enabled)

* Every "Direct to internet" Jingle Client with this functionally 
implemented and enabled , could work as a Media Proxy. (BitTorrent, 
Skype and etc... Media Proxy architecture)

* Jingle could have this described as a standard Media Proxy behavior 
for Jingle Clients.

Regards,
Thiago

Jean-Louis Seguineau escreveu:
> In the preceding discussion about a Jingle media proxy, Peter very
> appropriately mentioned that in real life this kind of service may provided
> from a different machine that a user's home server. 
> The current XEP-0166 most of the examples refer to point-to-point session
> use cases, where two Jingle clients negotiate a session directly between
> themselves. The generic signaling context of the XEP can be summarized as:
>
> ClientA ---- XMPPServer1 ----- XMPPServer2 ----- ClientB
>
> Now, in the case where a Jingle proxying service of any sort (IPBX, media
> proxy, etc) is provided by a separate server, the signaling context would be
> more like:
>
>
> ClientA ---- XMPPServer1 ----- JingleSce ----- XMPPServer2 ----- ClientB
>
> In this use case, we would have ClientA discovering the JingleSce server
> through XEP-0030 disco, and ending up knowing the JID of the service, and
> negotiate directly with the service. So in the Jingle stanza the client
> would use something like:
>
> <iq to='jingle.capulet.com/balcony' from='romeo at montague.net/orchard'
> id='jingle1' type='set'>
>   <jingle xmlns='http://jabber.org/protocol/jingle'
>           action='session-initiate'
>           initiator='romeo at montague.net/orchard'
>           sid='a73sjjvkla37jfea'>
> ...
> </iq>
>
> If the Jingle service is only acting as a signaling relay, as it would be
> the case of an IPBX or Jingle media proxy, ClientA will in fact be trying to
> reach ClientB *through* the JingleSce server. At this point we need a way to
> tell the JingleSce server that the negotiation is in fact destined to
> ClientB.
>
> I wanted to reformulate the question on how this can be achieved. After
> off-list discussion two alternatives approaches have emerged:
>
> - modify the XEP-0166 specification to include a relaying/forwarding
> capability. This would be achieved by creating a new element to hold the JID
> of ClientB.
>
> <iq to='jingle.capulet.com/balcony' from='romeo at montague.net/orchard'
>   id='jingle1' type='set'>
>   <jingle xmlns='http://jabber.org/protocol/jingle'
>           action='session-initiate'
>           initiator='romeo at montague.net/orchard'
>           sid='a73sjjvkla37jfea'>
>        <relay>juliet at capulet.com/balcony</relay>
>        <content name='this-is-the-audio-content'>
>        ...
> 	 </content>
> </iq>
>
> - use the XEP-0033 extended addressing to hold the JID of ClientB without
> modifying the XEP-0166.   
>
> <iq to='jingle.capulet.com/balcony' from='romeo at montague.net/orchard'
>   id='jingle1' type='set'>
>   <addresses xmlns='http://jabber.org/protocol/address'>
>        <address type='to' jid=' juliet at capulet.com/balcony '/>
>   </addresses>
>   <jingle xmlns='http://jabber.org/protocol/jingle'
>           action='session-initiate'
>           initiator='romeo at montague.net/orchard'
>           sid='a73sjjvkla37jfea'>
>        <content name='this-is-the-audio-content'>
>        ...
> 	 </content>
> </iq>
>
> We would be interested in hearing everyone's comments on these two protocol
> approaches.
>
> Jean-Louis
>
>
>
>