[Standards-JIG] new top level tag?

Ulrich Staudinger us at die-horde.de
Tue Mar 9 11:01:19 UTC 2004


a characteristic of RTP is, afaik, password support – means a server 
requests a password from the client, if the client does not support a 
passphrase, access is rejected through the rtp server.




when working on RTP XMPP integration i suddenly had the sudden flash of 
an idea:
a new top level tag.
it's not yet fully worked out, but it seems reasonable in some situations.

i.e.:
establish a 1-to-1 session on the server
both clients request personal relays on the server:
client A/B requests relay

<rtp to='rtprelay.com'>
<request>
<session type='private' id='abcd'></session>
</request>
</rtp>

server returns to both romeo and julia their personal RTP urls.

<rtp to='<jid> <to=%27 at romeo.org>'>
<session type='private' id='abcd'>
<streamurl>rtp://rtprelay.com:9001/romeoinput.rm</streamurl>
<recurl>rtp://rtprelay.com/romeoinput.rm</recurl>
<sessionhashkey>somepersonalhash</sessionhashkey>
</session>
</rtp>


Now both partners try to hook access the others url, by exchanging the 
rtp url of the partner along with the session hash:

romeo sends to julia

<rtp to='julia at jabber.org <mailto:to%3D%27julia at jabber.org>' type='private'>
<url>rtp://rtprelay.com/romeoinput.rm</url>
<password>romeoshash</password>
</rtp>


and julia sends to romeo

<rtp to='romeo at jabber.org <to=%27romeo at jabber.org>' type='private'>
<url>rtp://rtprelay.com/juliainput.rm</url>
<password>juliasshash</password>
</rtp>


one characteristic of RTP is, afaik, password support – means a server 
requests a password from the client, if the client does not support a 
passphrase, access is rejected through the rtp server.



      for MMUC

    *

      join a public session for listening on the server

client:
<rtp to='rtprelay.com' id='someid'><join>sessionname</join></rtp>

server:

<rtp to='client at jabber.org <mailto:to%3D%27client at jabber.org>' id='someid'>
<recurl>rtp://some.server.com/session101user5.rm</recurl>
<streamurl>rtp://some.server.com:9000/session101user5input.rm</streamurl>
</rtp>


the server then tries to mix the data from in this case a user with uid 
5 into the session 101.

the client may access his personally mixed session at 
rtp://some.server.com/session101user5.rm .

Of course, if a server refrains to support personal mixing, i.e. Due to 
memory or lack of CPU power on the server (mixing 1000 voice streams is 
no trivial task) it may simply transmit one url for all users in a session.






requesting comments.
thanks,
ulrich




More information about the Standards mailing list