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