5

It’s just a start where I am exploring more in P2P side, and finding reasons in terms of Scalability or anything else for : SIP or XMPP (Jingle) for following use case :

P2P Client Application Capable to perform File Transfer on all Network Traversal Scenarios.

// For Signaling (e.g.; to connect/locate/disconnect peers) both XMPP (Jingle) or SIP are available.

May I know possible reasons to use what and why? Any practical use? e.g.; Scalability or anything which really makes a difference for the above Use Case

Sumit Arora
  • 5,051
  • 7
  • 37
  • 57
  • I think of Jingle as a subset of XMPP/Jabber. – kenny Apr 04 '11 at 11:32
  • Yes you are absolutely right that Jingle is a *Subset* of XMPP, I just thought to find someone who practically learned or differentiated by some means JIngle vs SIP for signaling. May be Its a comparision of Apple and Oranges but still this duo exist to to provide similar solution. – Sumit Arora Apr 05 '11 at 00:46

1 Answers1

10

Jingle is an XMPP extension to handle multimedia sessions. In effect Jingle is the XMPP equivalent of SIP.

As far as a P2P file application goes:

  • Jingle and SIP are roughly equivalent as far as scalability goes. Both separate the signalling and media providing more flexibility (and consequently complications) with the way server side components can be deployed.

  • XMPP/Jingle has a better security design making it much more practicable to enforce clients using an SSL signalling layer. SIP does support SSL but it's more convoluted and also doesn't enjoy widespread support in the real World,

  • As far as NAT goes you're going to have the same problems with both. The scalability you get from having separate signalling and media paths comes back to bite when NAT is involved. There are a few different mechanisms to deal with NAT the latest attempt is ICE. ICE is collection of different mechanisms to try and resolve different NAT configurations and it's worth bearing in mind that not all configurations can be resolved and the fallback is to use a media proxying server such as TURN.

If I was you I'd use XMPP but before starting I'd work out exactly what NAT configurations need to be supported. If you need to support arbitrary clients from anywhere on the internet then you will not be able to rely on always being able to establish direct P2P communications between your clients and that's where you will face your biggest challenge.

Community
  • 1
  • 1
sipsorcery
  • 30,273
  • 24
  • 104
  • 155
  • 1
    Yes, I have worked out on *NAT Configurations* as well, definietly it require to support all *NAT Traversal* Scenarios by using ICE solution. Do you have any experience on libjingle ? Google Implementation for *Jingle Protocol*, It has inbuilt ICE, Is there any other major success who used libjingle etc for the same ? How about PJNATH ? One should use PJNATH for ICE or use inbuilt ICE in libjingle. – Sumit Arora Apr 05 '11 at 00:41
  • 1
    I don't have experience with those libraries. I have used agXMPP for some tasks and also wrote my own quick and dirty XMPP/Jingle stack to work with Google Voice. A client side XMPP application would only take a few weeks to write from the ground up, you'd be looking at a few months for a SIP one. If you also need to write an XMPP server it will be a much bigger task. THere's probably already an XMPP client app around that does file transfers. – sipsorcery Apr 05 '11 at 09:35