SIPSORCERY WORKING AGAIN!!! THANKS AARON!!!

Support zone
Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: SIPSORCERY NOT WORKING ANYMORE!!!

Post by Aaron » Wed Jun 02, 2010 11:15 pm

I've updated the sipsorcery proxy to allow a single spiral/loop that means the iptel call scenario will now work.

In regards to one way audio when calling between two sipsorcery accounts if they are behind the same NAT you can get the audio working using:

sys.Dial("testservice1@local[ma=false]")

The [ma=false] dial string option tells the sipsorcery server NOT to mangle the SDP request and leave the private IP addresses within it alone.

If the two ends of the call are behind two different NATs then it's a lottery and whether audio will work depends on the types of NAT. If you find it doesn't work then you are better off forwarding the call through a provider that does have a media server such as iptel, pbxes, voxalot.

Aaron

netdomain
Posts: 13
Joined: Sun May 30, 2010 7:34 pm

Re: SIPSORCERY NOT WORKING ANYMORE!!!

Post by netdomain » Thu Jun 03, 2010 1:10 am

Aww man!

I tried the [ma=false] method, but still didn't work :(

I put it back to

#RUBY

sys.Log("call from #{req.Header.From.FromURI.ToString()} to #{req.URI.User}.")

if sys.Out then
# Do your OUTGOING call processing customisations here.
case req.URI.User
when /^102/ then sys.Dial("${dst}@vbuzzer")
when /^testservice1/ then sys.Dial("${dst}@iptel")
when /^44/ then sys.Dial("${dst}@voipstunt")
else sys.Dial("vonage")
end
end


NOW EVERYTHING WORKS AGAIN!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

THANKS SO MUCH AARON!!! I'LL FULLY SUPPORT YOU AND GIVE A DONATION!!!

IMGrant
Posts: 2
Joined: Wed Jun 02, 2010 10:24 pm

Re: SIPSORCERY NOT WORKING ANYMORE!!!

Post by IMGrant » Thu Jun 03, 2010 9:11 am

My Sipgate setup works fine again now too - thanks Aaron!

ddn
Posts: 3
Joined: Mon May 31, 2010 3:14 pm

Re: SIPSORCERY WORKING AGAIN!!! THANKS AARON!!!

Post by ddn » Thu Jun 03, 2010 3:04 pm

Same here, everything works.

Great job!

Thanks,

--Ddn

reraikes
Posts: 237
Joined: Thu Aug 13, 2009 10:15 pm

Re: SIPSORCERY NOT WORKING ANYMORE!!!

Post by reraikes » Thu Jun 03, 2010 5:54 pm

Aaron wrote:I've updated the sipsorcery proxy to allow a single spiral/loop ...
Aaron,

I have both channels of a PAP2 (on ports 5060 and 5061) registered to Sip Sorcery with a phone connected to each. I also have Sip Sorcery registered to Gizmo5 and Voxalot. I have SIP and RTP ports explicitly forwarded in my router as well as a STUN server enabled in the PAP2, so I normally never experience any audio problems.

Prior to the server change, I could call my Gizmo5 or Voxalot number from one phone and it would ring into the other phone with no audio problems of any kind. After the server change, these calls would go to voicemail due to the loop-back detection. Since you made the change above, the calls now go through again, but there is no audio in either direction. On all calls (to myself or otherwise), the console log reports:

SDP on UAC call had public IP not mangled, RTP socket ...

I tried adding [ma=false] to the sys.Dial string, but it made no difference.

If you have any other suggestions for getting this to work again, I'd like to try them. This capability often comes in handy for testing purposes.

Thanks,

Ron

Aaron
Site Admin
Posts: 4652
Joined: Thu Jul 12, 2007 12:13 am

Re: SIPSORCERY WORKING AGAIN!!! THANKS AARON!!!

Post by Aaron » Thu Jun 03, 2010 10:37 pm

Sounds like there are more people using spiralled requests than I thought, a spiral is where the call goes out from sipsorcery through a different provider and then comes back to sipsorcery. That's not an issue unless it conintues to spiral in which case it's a loop. The loops are what I wanted to stop and the sprials were an unforseen casualty. Thankfully there was an easy way to allow spirals and still block loops so all is good now.

In regards to audio issues there should be no change with the adjustments for spirals, loops or the new server. If a call is destined for two SIP agents behind the same NAT then you should do as you've done and use set ma=false. That will cause sipsorcery to leave the SDP alone (which is the only thing that plays a part in determining where the audio goes) but it won't make any difference to any other providers and they may mangle the SDP anyway or more likely they will be bridging the audio so ma=false is irrelevant.

If it was working at one stage and now it's not first thing to do is try rebooting or resetting your router. It's easy to do and always worth a try and it will result in your NAT mappings getting cleaned out which is the sort of thing that can cause one way audio issues.

Regards,
Aaron

reraikes
Posts: 237
Joined: Thu Aug 13, 2009 10:15 pm

Re: SIPSORCERY WORKING AGAIN!!! THANKS AARON!!!

Post by reraikes » Fri Jun 04, 2010 12:23 am

The last time it was working was when the server was on Amazon. The router has been rebooted several times since, including just prior to posting, to make sure the router isn't the culprit.

As soon as the silent call is answered, there's a steady steam of packets (presumably RTP) to the PAP2, but no audio can be heard on either phone. As soon as the call ends, the packets stop (just like a nornal call).

jadam
Posts: 68
Joined: Sat Oct 18, 2008 9:05 pm
Location: England

Re: SIPSORCERY WORKING AGAIN!!! THANKS AARON!!!

Post by jadam » Tue Jun 15, 2010 12:05 am

On the "loop" issue
1) If for example I registered a voxalot account on SS for voicemail, but used a non-existant "not_here_dude@sipsorcery.com" as the registration contact,
2) then if a call comes in, no ATA is registered to SS, no-one available to receive the call,
3) so my incoming dialplan sends the call to the voxalot account for voicemail.
4) The voxalot account has voicemail delay set to 0 but still the call comes back to SS via the registration,
5) then because the "not_here_dude@sipsorcery.com" registration contact does not exist SS ends the last return leg and the voxalot voicemail picks the call up.
Really the equivalent of a null user or of /dev/null in *nix?
Previously there would have been 1 iterations of an incoming call, now with the extra loop you've allowed there will be 2 iterations, but with the "not_here_dude" we will be as one again
"not_here_dude" could be the official name for this :shock:

Post Reply