how-to block ads
|
igi
join:2002-04-21
Oceanport, NJ
| reply to DracoFelis
Re: [Equipment] Useful Sipura tricks...
Hi DracoFelis,
Thanks a lot for your master tricks. I have a question about latency though in your Line 2/Line 1 forwarding: have you checked if this increases latency/delay when you call another FWD user?
I'm interested in using the same trick, but I wouldn't want to add more delay to what I already have, since some of my FWD calls are literally to the other side of the world. If the IP forwarding is done all internal inside the SPA, then I don't see why this would add delay, but with the external IP address trick, are you now opening another routing through the internet?
Thanks,
I. | |
DracoFelis
Premium
join:2003-06-15
| said by igi  :I have a question about latency though in your Line 2/Line 1 forwarding: have you checked if this increases latency/delay when you call another FWD user? No, I have not checked. However, based upon some posts over on Voxilla.com (since the time I came up with that "trick"), it appears that Sipura adapters do NOT do forwarding "internally", but instead send a SIP "reinvite" message back to the calling SIP device. Essentially, the Sipura sends a message back to the original SIP provider, telling that provider to send the SIP traffic to an alternate destination.
As a result, the predicted behavior of my forwarding "trick" is this:
1) Since the Sipura essentially tells the sending provider to redirect the traffic, any provider that ignores such redirect messages will likely not work with this forwarding trick (and in fact, at least one person who tried my forwarding trick with a commercial VoIP provider appeared to fail for this reason). Thankfully FWD does pay attention to "reinvite" messages, so this trick can work with inbound FWD calls (which happens to be also what I originally tested it on).
2) Since the SIP messages aren't really "forwarded", but instead the original caller is told (by the SIP reinvite message) to try sending the call elsewhere, you shouldn't have any more "latency" then if the user had called that other port directly.
3) This also explains why you have to use the EXTERNAL (internet, NOT LAN) address of your Sipura, and why you have to forward the SIP ports on your router to your Sipura (for this trick to work). Simply put, it appears that the "SIP reinvite" message (that your Sipura gives out as a result of the "forward" setup) tells the remote SIP device how to call the other port of your Sipura directly "peer to peer".
4) If I'm correct in what is going on, that would also explain how to directly call a Sipura "peer to peer" without any "service provider" (even FWD) at all! Anyone with a Sipura want to help test this theory out? Can another user on the internet directly "ring our phone" by calling the same URI that we have in our "forwarding" trick? I bet the answer is "yes", but I would like to test this theory out first, before saying for sure that it will work! | |
gnexus
join:2005-06-24
1 edit | said by DracoFelis :4) If I'm correct in what is going on, that would also explain how to directly call a Sipura "peer to peer" without any "service provider" (even FWD) at all! Anyone with a Sipura want to help test this theory out? Can another user on the internet directly "ring our phone" by calling the same URI that we have in our "forwarding" trick? I bet the answer is "yes", but I would like to test this theory out first, before saying for sure that it will work! Yes! You are correct Draco. It does work! (of course it does, SIP is P2P so it has to. . .unless there's a Sipura prob. with P2P) You beat me to the next "trick". 
I was going to post it, but then I had problems:
I had it working after trying your trick! Now it doesn't however. . . The voice is audible inbound only and I'm trying to troubleshoot. That's why I'm back here at BBR. . .searching through old posts on NAT traversal.
You would think it's, and somehow it probably is, a NAT traversal problem. It is a strange one, however, because it was working before, and occasionally has since, after settings changes. Then it stops, however. I even tried setting the SPA as DMZ. That still only had it working for a single call. Due to that I'm starting to think that my SPA is screwed up because of that, and intermittent outbound dropouts (every 10s or so) on my regular VoIP provider (and all the other free VoIP services, too). I even tried resetting the SPA with no improvement. . .
Since it is likely a NAT traversal problem, I am (impatiently) awaiting the next DD-WRT beta. It has a SER built in which will eliminate NAT traversal problems and the use of the STUN gun. 
Edit: Still no luck. . .One way audio, fleeting two way audio. I did find out something interesting in the SIP logs, however:
SIPphone server response:
Server: Sip EXpress router (0.8.12-tcp_nonb (i386/linux))
That means the SIPphone proxy server is using the same code as the SER being added to DD-WRT! | |
|
