Hi- where can I find details about the Wildfire server Jingle implementation? Specifically, I’'m looking for how Wildfire manages “dialing plans” and call routing.
Here’‘s an example of a question I’'m looking to answer: if a numeric address (e.g. telephone number) or a user not on the current wildfire server is “called”, how does the server know where to had the call off to?
Thanks,
Dan
Jingle is basicly a protocol to establish a direct call between two clients.
The Jingle idea is do not have server dependency.
Btw, Sometime we need some server help to establish a p2p connection. That´s when wildfire should arrive. To provide a public address discovery, a media proxy to ensure p2p connectivity, etc…
Jingle is not like SIP, if your XMPP server can route a packet to another user, even if it registered in another server, you both should be able to talk, if both clients support jingle, and with a common transport type and a common codec.
About dialling numbers, you should call something like an asterisk server. But, avoid this for a while, since we do not have any standard way to do this. What we have is several approachs.
Regards,
Thiago
Thiago- thanks for the response. Let me explain a little about what I’‘m doing so that you have more context. I’'m looking to create a Jingle-to-SIP gateway so that members of a specific Jabber/Jingle server can make/take calls from other VoIP networks and the PSTN. Wildfire/Spark looks to be the perfect platform for this. I figured I could create a Spark plugin that would allow the user to call another Jingle user P2P or make calls onto other networks using SIP addresses or telephone numbers.
My assumption was that Jingle call requests go through the Wildfire server before going to client… if that’'s not true, then I guess I need to go back to the drawing board. If it is true, then I would like to get some more details about the future implementation so that I could start designing the Jingle-SIP gateway.
On a slightly different note- I and my colleagues have a great deal of experience with NAT traversal and session border controllers, so if you hit any snags or want a design review, let me know.
Great software, by the way- thanks for your efforts!
Cheers,
Dan
Hello Dan,
The Jingle Packets pass through Wildfire, but just for routing processes.
But, you can Intercept packets before they are submitted.
This way you can make a SIP gateway adding something like a plugin to wildfire that intercepts Jingle Packets. And change the destiny of it.
Btw, We are finishing the development of a Media Proxy to Wildfire.
In our implementation we use 2 ports (media and control) for each session. So the media proxy server must open a port range for UDP traffic. Around 5000 UDP ports. Do you see any problem with opening these ports?
How your SIP Media Proxy works, bind 2 ports per session, or has a unique UDP port to send an receive the traffic from all connected Streams?
Regards,
Thiago
Thiago- I’‘m having trouble answering your question, in large part because I don’'t fully understand the architecture and/or problem space itself. Can you send me a schematic showing the logical and physical elements as well as a sample call flow? That should provide the context I need. You can email to ecodan@montana.com.
Just to give you some idea of where we’‘re coming from, we use a Netrake SBC to front-end all of our SIP sessions. The endpoints are of various types on various networks, and they communicate with multiple disparate proxys behind the SBC. In our case the SBC handles NAT traversal. We’'ve used STUN/TURN in the past as well, but with less success.
To your question- port management behind firewalls can indeed be problematic… we’‘ve wrestled with this problem on a number of occasions. But again, without understanding the specifics, I can’'t really offer anything substantive.
Also, it might make sense for us to have a quick conference call to discuss- do you have access to Skype or Yahoo with voice or another VoIP tool we could use?
Cheers,
Dan
Dan,
The call flow is the simplest ever.
Jingle negociate the session and the call, client-client. The server JUST route the packet from one user to another.
Wildfire DONT process the packets content before sending it to destiny JID.
Jingle Servers dont exists.
Basicly, when thinking of how Jingle establish a call, forget the server. Imagine that you are negocianting just p2p calls.
Jingle was created to pc-to-pc calls. Not for convencional telephony. So dont think about Jingle as we used to think about SIP.
I´ll provide as soon as I can, a graphical explanation about Jingle.
Regards,
Thiago
Thiago- I understand the “signalling” path now (client-to-server-to-client to set up the call). It’'s the “media” path that seems to be the issue.
From your note above, though, it sounded like you were building an RTP proxy on the server that would remain in the audio path between both clients. This is a common approach in SIP world to get around client NAT issues and also allow for intelligent media server actions (DTMF listening, etc.). It’'s also bandwidth intensive and expensive.
But again, perhaps I didn’‘t understand the media flow. I’'ll look forward to your diagram.
Cheers,
Dan
Dan,
Yep, you’‘re right. If P2P negotiation via STUN fails then you have to fall back to a UDP media proxy, which we’'ll support in Wildfire itself (and eventually also in connection managers for added scaling).
Regards,
Matt
Hey guys- I’'m going to mark this as answered, but my colleagues and I are standing by to work with you on your firewall/NAT traversal architecture. Just let us know.