Hi Stefan, I tested the b2b_connect_audio example and it works fine. I was trying to play with the script. I had a question, if I want to set the b_leg_callee same as the username part of the original Ruri received in the first leg, what do i do? I could easily change the caller parameters of second leg using the mod_uri module, uri.parse function on the first leg. But I could not find any function to fetch the Ruri parameters in that module.
Thanks for all your help. --- Jayesh On Thu, Aug 18, 2011 at 3:50 AM, Stefan Sayer <[email protected]>wrote: > Hello, > > a kind of (very brief) reference documentation which lists all actions, > conditions, parameters, and 'special variables', is in > doc/dsm/dsm_syntax.txt > doc/dsm/mods/Readme.mod_*.txt > > Last I checked, it was complete in that sense that everything is at least > referenced. > > e.g. from dsm_syntax.txt: > > Variables controlling call flow > ==============================**= > special variables: > connect_session "0" -> after the start event (initial transition): > do not connect session to > media processor on start > > -> after the invite event: > do not reply with 200 OK and do not > connect session to media processor on > start > enable_request_events "true" - run events on receiving a request > "false" - don't run events on receiveing request > > > You are right it lacks proper documentation. There is a system > documentation forthcoming, but you are welcome to write anything from a user > perspective. Being very close in the code, it is often difficult to change > viewpoint. > > Also, some real tutorials explaining how to accomplish different use cases > would be great. > > Any further questions, please just ask. > > Stefan > > > o Jayesh Nambiar on 08/17/2011 08:41 AM: > >> Hi Stefan, >> Really appreciate your detailed reply. I will try all the suggestions >> and work harder on getting this done. I sometimes feel like I am >> running short of documentation. For eg, I dont know all the existing >> variables that can be used, the functions that can be called under >> different modules etc. >> Like, I had to write set(connect_session) = 0 to not send the default >> 200 OK and play media in 183 Session progress. There could be other >> similar useful functions which I am not aware of. Then there are set >> of other variables like you mentioned #hdrs, #method, #type etc. Is >> there any one place where I find a list of these variables like a >> quick reference place or something. >> Also if you point me to some different places where I find all these, >> probably I can accumulate them and document it for other users. >> >> Thanks again for all your help. >> >> --- Jayesh >> >> On Tue, Aug 16, 2011 at 7:51 PM, Stefan Sayer >> <[email protected] >> <mailto:stefan.sayer@**googlemail.com<[email protected]>>> >> wrote: >> >> Hello Jayesh, >> >> o Jayesh Nambiar on 08/12/2011 05:34 PM: >> >> Hi All, >> I have an implementation of Click2Dial in place which I wish to >> migrate on SEMS platform. The idea is to learn basics before going >> ahead with developing complicated applications. I have been >> reading a >> lot on DSMs and it looks very exciting script language. My >> scenario is >> >> yes, I like it for these kind of things, too. It's both simple >> quickly create applications, but at the same time powerful enough >> to control stuff in detail. >> >> >> as follows: >> 1) There is a PHP-SIP application which first sends an INVITE >> to SEMS. >> The INVITE contains some extra-headers which I need to >> preserve before >> taking the call ahead in B2B mode. They are important for >> billing :) >> >> if the extra headers follow the P-App-Param format, just set >> set_param_variables=yes >> in dsm.conf, then you can access the parameters set there, e.g. >> P-App-Param: billing_dest=123;billing_unit=**__60 >> >> ... >> log(1, $billing_dest); >> log(1, $billing_unit); >> mysql.query(SELECT * FROM billing_items WHERE dest=$billing_dest); >> >> if the headers look different, you can set >> $enable_request_events=yes which makes you get sipRequest events - >> then you can access all headers with the #hdrs parameter. >> >> Alternatively, use mod_uri, and access the headers with >> uri.getHeader(), e.g. >> >> import(mod_uri); >> >> transition "saving stuff" START - invite / { >> uri.getHeader(P-Billing-Dest, billing_dest); >> log(1, $billing_dest); >> ... >> } -> ... >> >> >> >> 2) The Sems needs to execute a database query based on values >> in the >> extra-headers and based upon the resultset, need to route the call >> ahead to a SIP Proxy in B2B mode. >> >> I would actually handle the leg of the call from the PHP-SIP >> application separately from the other legs. >> >> You can simply create a new call (dlg.dialout()) for the first >> leg, and communicate with the PHP-SIP-leg with events. There is >> several examples, see e.g. doc/dsm/examples/b2b_connect__**_audio >> >> >> >> 3) Once this call gets connected, the PHP-SIP application sends a >> REFER with REFER-TO uri as the second leg of the call. >> >> set >> $enable_request_events=yes >> in the PHP-SIP leg and check for the sipRequest event: >> >> transition "refer received" WAIT_REFER - >> sipRequest(#method=="REFER") / { >> ... use #hdrs ... >> ... send event to other leg with postEvent(...) ... >> } -> WAIT_CONNECT_LEG2; >> >> >> 4) SEMS should be able to handle this REFER by generating a >> new INVITE >> towards the proxy and sending BYE to the PHP-SIP application. >> >> probably you want to send NOTIFYs after the BYE, thus I would not >> stop the PHP-SIP DSM right there, but send BYE and then later send >> notifys, and at the end stop that call with stop(false) : >> >> transition "refer received" WAIT_REFER - >> sipRequest(#method=="REFER") / { >> ... use #hdrs ... >> ... send event to other leg with postEvent(...) ... >> dlg.bye(); >> >> } -> WAIT_CONNECT_LEG2; >> >> ... >> >> transition "notifying" WAIT_CONNECT_LEG2 - >> event(#type=="progress") / { >> ... send notify ... >> } -> WAIT_CONNECT_LEG2; >> >> transition "ended" WAIT_CONNECT_LEG2 - event(#type=="connected") / { >> ... send final notify ... >> stop(false); >> } -> END; >> >> >> 5) SEMS should also be playing a media file in 183 session >> progress >> which will be audible to the call on first leg, since the call >> is now >> Reffered. (Some media file like "Please wait while we connect >> your call") >> >> in the first leg? that one from PHP-SIP? you are setting up the >> leg to the caller by sending INVITE there, so no possibility to >> send 183. >> >> otherwise, you can use dlg.acceptInvite(183, "Session Progress") >> and then use normal things like playFile(progress.wav) >> >> >> 6) Once the call is connected, both legs of the call are actually >> connected to each other. >> >> Do you want to have the audio flow through SEMS? Then you can use >> mod_conference, see e.g. b2b_connect_audio example. >> >> or do you want to re-invite the legs so that the two ends are >> connected directly, RTP-wise? then you can use the B2BUA, by using >> B2B.connectCallee function (in the leg of the caller). >> >> >> >> Questions: >> 1) Is this possible using the DSM as I think it is the most >> flexible >> way of configuring services in SEMS. >> >> yes, I would use DSM as well. saves you a lot of code, >> implementing the usual things, too. also, you have all advantages >> like monitoring, online reload, etc. >> >> >> 2) I dont see any example of how to handle REFER method in DSM >> language. Is it really possible to handle REFER easily and >> then send >> >> handle sipRequest events as explained above >> >> >> 183 with some media played in it to the first leg? >> 3) Is it possible to add extra headers while sending the INVITE on >> behalf of the REFER method received? >> >> depending on whether you want to do pure singaling B2BUA or >> connecting audio; for B2BUA you would use B2B.clearHeaders() >> B2B.addHeader(), B2B.setHeaders(); for two separate call legs, you >> would use _hdrs to set the headers. >> >> hth >> Stefan >> >> >> I am a newbie to SEMS but have worked a lot on Asterisk, >> Opensips and >> Kamailio. Any help or directions will be really appreciated. >> >> Thanks in advance, >> >> --- Jayesh >> >> >> >> ______________________________**___________________ >> Sems mailing list >> [email protected] <mailto:[email protected]> >> >> >> http://lists.iptel.org/__**mailman/listinfo/sems<http://lists.iptel.org/__mailman/listinfo/sems> >> >> <http://lists.iptel.org/**mailman/listinfo/sems<http://lists.iptel.org/mailman/listinfo/sems> >> > >> >> >> >> -- >> frafos.com <http://frafos.com> >> >> >> > > -- > frafos.com >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
