Genesys CTI User Forum
Genesys CTI User Forum => Genesys CTI Technical Discussion => Topic started by: gen_den on January 05, 2017, 11:09:52 AM
-
Hi experts,
I am looking for information if Genesys can directly Integrate with Twilio? or it's mandatory to have Asterisk or any other switch in between>
can our Genesys SIP server directly integrate with any VOIP providers and send and receive calls without any switch/PBX in between?
Thanks
Ankush
-
I've set up Twilio as a SIP trunk into SIP Server.. I'll have to have a look see if I can find the config.
You don't need anything other than SIP Server to get it to work.
-
Thanks a lot for your reply , it would be great if you could provide the configuration for Twilio with SIP server please.
-
I've done it direct to SIP Server and via an SBC (strongly recommend using an SBC), it's essentially the same as connecting SIP Server to any external call source, eg. create a trunk DN and you're done.
-
Thanks, I have also deployed using direct SIP server. Created a SIP trunk and directed the call from provider to my trunk and it worked :)
As far as I know SIP server is capable of performing all the function a switch can do , however SBC i guess good for security
-
Hello can someone post this configuration? I have the inbound Twilio setup but my outbound is not working at all.
-
Yeah....magic balls and deamon spells are out...so logs will have to do this time. Sorry for the inconvenience
-
SBC is for both security, and topology hiding. Meaning it will deal with the fact that your SIP Server uses an internal IP address and be the single point of contact for your SIP traffic to get into your network.
-
Hi there,
I have this integration working perfectly for both Inbound and Outbound calls. It depends what kind of error you are getting from Twilio when your infra send INVITe to Twilio.
However for me i faced an error where Twilio could not authenticate my request, so you need to make sure for OUtbound calls.
---> You have created entry of your IP in ACL in Twilio page/account. So that Twilio trust the Request when it get from your Infrastructure.
---> The number which is allocated to you by Twilio send that number to Twilio in your INVITE , you can do it by adding an option "cpn" in your Trunk under TServer section.
Please post the logs with the error Error from Twilio or from the point it;s failing , hope it help :)
Thanks
-
I'm trying to connect directly to SIP Server as well, using Twilio's SIP Trunk.
Calls make it in, however there is no audio.
It seems that SIP Server is sending Twilio local ips.
How did you overcome that?
-
??? ???
Logs please and you configuration...
Are you using a SBC? without knowing your architecture is quite impossible to help
-
Trying to do what the others in this thread have done, directly using SIPServer without a SBC.
In the logs SIPServer is sending a 200 OK with a private IP in the Contact, so Twilio can't return the ACK, and the call times out after ~30 seconds.
-
Sir, your architecture and components with configuration can be similar but will never be the same.
Logs
-
So your SIP Server has a direct public IP?
-
Twilio needs an IP address that is publicly addressable to send the call/s to.
How would the others setup a trunk directly to SIP Server without one?
-
??? You need to go back to the basics of SIP.
SBC or similar software/hardware is needed to be able to change the destination address...your private IP is obviously not reachable by Twilio or any SIP equipment, therefore you need something to modify headers.
All solutions here refer to a SBC or similar being used
If you are using WDE as Endpoint then you can use this maybe:
https://docs.genesys.com/Documentation/SESDK/9.0.0NET/Developer/DefaultConfigSettings#public_address
But if you are sending calls to MCP then no way as far as I know as it needs to advertise the local IP for connection settings
-
That's what I had figured, and why I was surprised to read that the previous posters were able to get the trunk working directly with SIP Server (IE no SBC).
Their configurations would be extremely helpful in understanding. Thanks for the responses.
-
I was the one that said I got it working and unfortunately I couldn't find any details about how I managed to do it and this was a while ago
In regards to private IP in contact header, you resolve this by using DNS. Regarding private IP in SDP, you can use DNS here too for WDE but last I tried MCP did not allow this. For MCP you can specify a different (public) IP in the SDP with a setting.. this would only work for calls that access MCP from outside your network and becomes difficult when you have more than 1 MCP.
What I've also seen done is configuring the public IP as an IP on the machines that run the software - but this seems overkill and with DNS solving lots of the problems around internal/external contact, via, etc headers you just need to do that.. ensure the dns record resolves to internal IP for your internal DNS, and public IP for public facing DNS
-
??? ??? Sorry but a DNS management can't fix the IP Address sent at the via IP parameter in SDP...would be so easy if so and there would be no need for SBCs or Firewalls doing NAT alteration
-
You can specify FQDN in the SDP using MCP options and now thinking about it I'm not 100% sure if it was WDE or if t was MCP that supported it, but at the time one of the components did support it and one did not.
But like I said you can force MCP to send a different IP (ie the public IP) using an option.. Actually you can set it to FQDN or a public IP using the same option - mpc/sdp.connection
https://docs.genesys.com/Documentation/Options/Current/GVP/GVP_MCP-mpc#sdp-connection ..
MCP Options:
[code]mpc/sdp.connection = IN IP4 110.12.13.14
sip/transport.localaddress = mcp-01.company.com[/code]
And obviously ensure that SIP Server only uses FQDN everywhere..
The only place that needs to be an actual IP in the SIP messages is SDP but even in that case the RFC does allow for FQDN so devices should support it (but lots don't - I always like to try when connecting to something new)
[code]; sub-rules of 'c='
connection-address = multicast-address / unicast-address
; generic sub-rules: addressing
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
...
FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)[/code]