> >The idea being running processes > >(usually games) that don't know their inside SIP. > > > >Would it be RTP? Ethernet tunnelling maybe? > > Huh. Well, if you've got a game that thinks it's just running over IP, or > over Ethernet, then you don't really need RTP's timestamps. On the other > hand, you also don't need the reliability of SIP-level messages--and those > would be a larger problem than the timestamps, because the game's protocol > might include some bits that should be unreliable (e.g., if audio > streams).
Tunneling protocol data inside SIP is generally considered a bad idea, as it would dramatically alter the workload of the SIP servers. It is also a bit weird. If you think about it that would be pretty much like sending game messages as instant messages. That may work for announcing your chess moves, but if you try that with a first person shooter neither the IM provider not the game player are going to like the result. The architecturally correct way to use SIP for games is to use a SIP exchange to initiate a game session, i.e. invite "sip:[EMAIL PROTECTED]" to join a game. The payload of the SIP messages (INVITE and response) will carry the IP address and port numbers used by the game application. -- Christian Huitema
