Kamailio / Freeswitch connection with rooms
Hi Aaron Clauson, we are currently trying the following UseCase: A user is supposed to connect to a Kamailo/Freeswitch on an iOS Unity client via WebRTC + SIP. The Freeswitch is working with the following descriptor. For Example:
SIPCallDescriptor callDescriptor = new SIPCallDescriptor(
currentFSInfo.username, // username
currentFSInfo.password, // password
$"sip:{currentRoomNumber.ToString()}@{currentFSInfo.hostname}", // uri
$"sip:{currentFSInfo.username}@{currentFSInfo.hostname}", // from
$"sip:{currentRoomNumber.ToString()}@{currentFSInfo.hostname}", // to => room id
null, null, null, // routeset, customHeaders, authUsername
SIPCallDirection.Out, // call direction
"application/sdp", // content type
currentModifiedOffer, // content
null);
Unfortunately, the SIPClientUserAgent does not take the correct paramters that are needed. Should look something like this:
new SIPClientUserAgent(sipTransport, invalidUser, invalidHost, sipInstanceId, currentRoomNumber.ToString());
Is such a scenario known, or is the library not designed for it at all?
By the way - Thanks for the great work
Small addendum:
Furthermore, we currently connect via JSSip in our WebApp. Unfortunately I don't see a way to work with sockets in the registration - like: https://jssip.net/documentation/3.2.x/api/ua_configuration_parameters/#parameter_sockets
WebRTC+SIP from Unity on iOS??!! That's very cool. If you have any demoes/examples/anything I'd love to see that in action.
Easy one first. The SIP over websockets should be doable. Take a look at this example. The sipsorcery library does support websockets as a transport protocol.
The SIPCallDescriptor can almost certainly take the parameters you need to place a call to FreeSWITCH. It's problem is being too flexible and therefore unweildy to use. Is there any reason you're using SIPClientUserAgent instead of SIPUserAgent? The SIPClientUserAgent is a lower level primitive and will take more wiring up. Whereabouts are you wiring up WebRTC in that scenario? The Asterisk ICE example may be a useful starting point. It's establishing a SIP call with Asterisk and using a WebRTC RTCPeerConnection for the media. FreeSWITCH should work with the example as is.
Hello Aaron Clauson, Ok, after I unfortunately couldn't manage to establish a connection in different ways, I'll get back to you. The last example you gave: SIPWebSocketChannel as well as SIPClientWebSocketChannel unfortunately I could not establish a connection.
var webSocketChannel = new SIPClientWebSocketChannel();
sipTransport.CanCreateMissingChannels = false;
sipTransport.AddSIPChannel(webSocketChannel);
sipRegistrationUserAgent =
new SIPRegistrationUserAgent(sipTransport, USERNAME, PASSWORD, DESTINATION, EXPIRY);
Basically, I am looking for a way to establish a connection like JSSIP, via the WebSocket interface: https://jssip.net/documentation/2.0.x/api/websocket/
var socket = new JsSIP.WebSocketInterface('wss://foo.bar.net');
var configuration = {
sockets: [socket],
uri: 'sip:[email protected]',
password: '123456654321'
};
ua = new JsSIP.UA(configuration);
ua.start();
Sorry if I am missing obvious things. But I am confused how a WebSocket connection can be passed through the existing classes? Especially about the default to pass an IPEndPoint or IPAddress. Or am I using SIPClientWebsocketChannel incorrectly? How exactly should the ServerUri be entered there?
Thanks for your work Patrick
Small addendum: the SIPClientWebSocket pulls its URL from the RIPRegistrationsUserAgent hostname. In our case, however, the WS-URI is not the same as the SIP-URI. WS-URI: wss://foo.bar.net/sip SIP-URI: sip:foo.bar.net (without the /sip)
If you want to specify a web socket transport on your SIP URI you can use:
sip:user@localhost:80;transport=ws
And for a TLS web socket:
sip:user@localhost:443;transport=wss
A handy testing tool is the sipcmdline utility:
examples\sipcmdline>dotnet run -- -d sip:user@localhost:443;transport=wss -s reg -v