Hi Alex, I do realize Kamailio to be a SIP proxy and, as you said, Kamailio may not be the best place to do a HTTP <> SIP gateway. I start to realize as time goes by...:) However, at least managing incoming SIP sessions and converting those to HTTP using http_query() although didn't go very smooth, but at the end, results are quite positive.
Now was starting doing the other direction HTTP=> SIP and using xhttp_reply() noticed was not so much available to start a dialogue and hence this email - as new starter in kamailio there are many modules and functions that not aware of and this asking to the expert's community. Tell me one thing. If was not a SIP INVITE but just a SIP INFO or SIP MESSAGE (since are stateless), would it be easier to do? I'll be off next week, but I'll comeback to this the week after. All inputs are welcome! Thanks Joao -----Original Message----- From: sr-users [mailto:[email protected]] On Behalf Of Alex Balashov Sent: sexta-feira, 19 de Junho de 2015 20:28 To: [email protected] Subject: Re: [SR-Users] New SIP INVITE from UAS (new dialogue) Hello Joao, As a general rule, speaking broadly and methodologically, Kamailio - as a SIP proxy - is not a good vehicle for the initiation of calls, since it cannot, itself, be a party to a dialog. Synthesising an INVITE using uac_req_send() isn't going to work because there's no second party to the dialog. Where will the replies to the INVITE go? Kamailio itself cannot be a party. There are, nevertheless, the ways to initiate a call from Kamailio using the 'dialog' module. The most straightforward is probably the 'dlg_bridge' / 'dlg.bridge' (MI and RPC respectively) commands, which can be called externally to Kamailio, http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3756384 or internally from route script, via the dlg_bridge() command: http://kamailio.org/docs/modules/4.3.x/modules/dialog.html#idp3698368 The general idea here is that an INVITE is initiated to one party and then that party is REFER'd out to another party. REFER is a SIP method that is commonly used for unattended transfers and call forwarding. You can read more about it here: https://www.ietf.org/rfc/rfc3515.txt Of course, for it to work, party #1 has to support REFER. -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at http://www.amdocs.com/email_disclaimer.asp _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
