How to change invite IP on Outbound Call

I've been testing Freeswitch/FusionPBX with our Avaya 6.3 CM. I have inbound calls working with a SIP trunk from the Avaya to Freeswitch on port 5080. I am unable to get an outbound call working. I setup the Avaya CM as an unregistered gateway and added a outbound route. Each time a place a test call from a softphone registered to Fusionpbx the invite always has the IP of the Freeswitch and not the IP of the Avaya.

Request: INVITE sip:5551212@192.1.2.1;transport=TCP

The invite needs to have the Avaya CM IP in the invite.
Request: INVITE sip:5551212@10.172.1.2;transport=TCP

Where do I set that up?

Thank you in advance

Jeff J.
 

DigitalDaz

Administrator
Staff member
The ruri should have the address of the next proxy in there so that should be the value of the proxy field in the gateway.

Also remember with the gateway to all ways put in a username and password even if you are not using one eg dummy/dummy and do not put anything at all in the 'Hostname' field.
 
That's what I would think as well, but instead I see the IP of the FS and not the IP of the Aavay_CM.
2017-11-27 14:13:16.271429 [WARNING] sofia_reg.c:1792 SIP auth challenge (INVITE) on sofia profile 'internal' for [18005551212@10.172.210.190] from ip 10.172.193.151
Is there anyway to force it?
 

DigitalDaz

Administrator
Staff member
I'm a bit at a loss here, above, you are showing a gateway which would be for outgoing calls but what you appear to be showing above is an invite from somewhere else.

So the above would be an invite to this box, ie 10.172.210.190 from something else. ie 10.172.193.151.

Its auth challenging so this 10.172.193.151 would need to be an extension.
 
The 10.172.193.151 is the Zoiper softphone calling the 11 digit number. the error is 404.
2017-11-27 14:48:25.711335 [NOTICE] switch_core_state_machine.c:312 Hangup sofia/internal/2352999@10.172.210.190 [CS_ROUTING] [NO_ROUTE_DESTINATION]
I can place an inbound call the that extension without issues. So when an 11 digit call is placed in this case does FS evaluate the outbound routes table to look for a match then send the call to the gateway based on the action bridge sofia/gateways/Avaya_CM/$1. Then from there based on what is in the proxy field use that for the invite? I know I can send back to the switch as we have an Asterisk box sending callbacks to CM via SIP as well.
 

DigitalDaz

Administrator
Staff member
Too heavy on the logging but never mind that did the trick.

The lines that are causing the problem are these:

Code:
017-11-27 15:14:46.571331 [INFO] mod_dialplan_xml.c:637 Processing 2352999 <2352999>->18005551212 in context public
2017-11-27 15:14:46.571331 [DEBUG] freeswitch_lua.cpp:365 DBH handle 0x7ff24419e290 Connected.
2017-11-27 15:14:46.571331 [DEBUG] freeswitch_lua.cpp:382 DBH handle 0x7ff24419e290 released.
Dialplan: sofia/internal/2352999@10.172.210.190 parsing [public->2352999] continue=true
This call should not be in the public context. What this would suggest is you have changed the default somewhere but where, I don't know.

The context in the extension settings should be the domain it was created in and shouldn't be touched. In this case I would expect to see the context as 10.172.210.190

Have you modified ANY of the xml files on the filesystem?
 
I've only made changes via the web frontend. To ensure it wasn't something I did, I redeployed a VM snapshot I took after building the server. Now it seems to be working some what. built the basic extension and registered it. Verified incoming call the FS works. Then built the gateway and outbound route and now the SIP invite toward the Avaya is correct.

The context for the dialplan.xml shows the domain.
[INFO] mod_dialplan_xml.c:637 Processing 2352999 <2352999>->18005551212 in context 10.172.210.190
Dialplan: sofia/internal/2352999@10.172.210.190 parsing [10.172.210.190->user_exists] continue=true

Now for the some what part. I see the SIP invite go out but never get a response back from the Avaya side. Tracing the TAC for the trunk group on Avaya I never see the call and on the FS side it will retry and then timeout. After playing around with the gateway settings and changing the transport to TCP I was finally about to get a call to pass. There's some weird stuff in the contact and a few other setting to tweak.