How to change invite IP on Outbound Call

Status
Not open for further replies.

Jeff J

New Member
Nov 21, 2017
6
0
1
62
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
Sep 29, 2016
3,038
556
113
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.
 

Jeff J

New Member
Nov 21, 2017
6
0
1
62
This is my gateway setup. Nothing in the advanced section and adding the CM as the Proxy, still does not send the correct SIP invite. What am I missing here?
upload_2017-11-27_10-20-6.png
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
According to your image above, I would expect to see: INVITE sip:5551212@<thingyouobscuredabove>;transport=TCP
 

Jeff J

New Member
Nov 21, 2017
6
0
1
62
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
Sep 29, 2016
3,038
556
113
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.
 

Jeff J

New Member
Nov 21, 2017
6
0
1
62
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
Sep 29, 2016
3,038
556
113
You shouls see whats going on in a more complete call log, can you post one of those.
 

Jeff J

New Member
Nov 21, 2017
6
0
1
62
I turned on every log I could find. Attached. The CM IP is 10.172.174.144
 

Attachments

  • FreeSwitch_Logs.txt
    38.4 KB · Views: 7

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
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?
 

Jeff J

New Member
Nov 21, 2017
6
0
1
62
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.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
If the device doesn't work without TCP then there is no pint forcing your PBX to TCP
 
Status
Not open for further replies.