Hi I've checked again locally against some other reinvites, and it seems it is normal to use the media IP in the reinvite sip request URI. The actual problem I am having, is that on the live environment only, the reinvite request URI does not contain a username, which causes a 404 0r a 402 to be generated. I've tried this with a number of downstream carriers with the same result, so it seems freeswitch is deciding not to include the username for some reason. I can't replicate this locally unfortunately, even using direct IP dialling. I am using this command to initiate the scenario from the fs_cli originate {origination_uuid=74f1bee7-9078-4d0d-b686-c2dc4334e1a,origination_caller_id_number=TestTest}sofia/lpmedia/ 1001@10.15.20.14:5063 '&lua(scenario.lua)' the lpmedia scenario file is here: http://pastebin.com/0NYnxZFH the lua script is here: http://pastebin.com/f46N4WnM If anyone could shed any light I would appreciate it... this is the last step in what I am trying to achieve! Thanks Pete On 8 October 2010 08:15, Pete Kelly <pkelly@gmail.com> wrote:
On 8 October 2010 02:55, Anthony Minessale <anthony.minessale@gmail.com>wrote:
Most likely its some nat related issue.
I am seeing the same problem on a local network (calling 2 devices registered to a local opensips proxy) and on a live setup calling tier 1 carriers with no NAT.
Would it help if I posted the sample scripts as requested?
Pete
On Oct 7, 2010 8:19 PM, "Michael Collins" <msc@freeswitch.org> wrote:
I don't know if it's a bug or not, but I think you probably will need to create a dialplan and sample Lua script to demonstrate the behavior. Post them on pastebin and link to this thread. We will see if we can reproduce the symptoms and diagnose from there.
-MC
On Thu, Oct 7, 2010 at 7:37 AM, Pete Kelly <pkelly@gmail.com> wrote:
Hi, I posted a question to this list yesterday because I was having problems with my calls ending as soon as they were bridged. I was originating 2 outbound calls from a lua script, then bridging them. I managed to get round the problem of the calls shutting down immediately by initiating calls using the originate command, thusly:
originate sofia/lpmedia/2000@10.15.20.122 '&lua(click2call_call.lua)'
This causes the lua script to initiate with a session already present and then a bridge to a new call (legB) completes successfully.
Within the lua script I am bridging to leg B like this:
session:execute("bridge", "[bypass_media_after_bridge=true]sofia/lpmedia/ 91979197@10.15.20.122")
This works, but the reINVITEs which get sent out after legB is established contain the wrong sip request URI.
- The SIP URI in the reINVITE to Leg A is to the MEDIA IP of leg B (the SIP packet is sent to the correct IP, just the request URI contains the media IP) - The SIP URI in the reINVITE to Leg B is to the MEDIA IP of leg A... again the SIP packet is sent to the correct IP, it's just the request URI which contains the media IP.
In some instances the request URI doesn't contain the username either, it is just INVITE sip:<MEDIA_IP>
I am using the latest sources of freeswitch from git
Is this a bug I need to report? It is causing me to receive 404 and 402 errors on the reinvite as the request URI is invalid.
Pete
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE: http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org