Hi, I could do it by setting the following: set(b_leg_callee=@user) It works as expected.
--- Jayesh On Thu, Aug 18, 2011 at 10:48 AM, Jayesh Nambiar <[email protected]>wrote: > 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
