Hello,
uac module provides a new function that allow sending sip requests from configuration file: - uac_send_req() http://kamailio.org/docs/modules/devel/uac.html#id2467912
It opens the door for a new bunch of things you can do now. I can think of now: 1) send IM alerts on special events
route { $uac_req(method)="MESSAGE"; $uac_req(ruri)="sip:alert@kamailio.org"; $uac_req(furi)="sip:server@kamailio.org"; $uac_req(hdrs)="Content-Type: text/plain\r\n"; $uac_req(body)="SIP request from:" + $si + ":" + $sp; uac_send_req(); }
2) turn lamps on for some sip phones on some events - e.g., snom: http://wiki.snom.com/Features/LED_Remote_Control
3) talk server-to-server - here one example can be building a platform with a central server for accounting
Accounting is done at 200ok. So each routing server will build a csv list (time,callid, from tag, to tag, invite from uri, invite r-uri):
onreply_route[1] { if(status!="200") return; $uac_req(method)="ACCOUNTING"; $uac_req(ruri)="sip:store@accounting.kamailio.org"; $uac_req(furi)="sip:server@server1.kamailio.org"; $uac_req(hdrs)="Content-Type: text/accounting-csv\r\n"; pv_printf($uac_req(body), "$TS,$ci,$ft,$tt,$T_req($fu),$T_req($ru)"); uac_send_req(); }
note that $T_req() is given by tm module, also with Kamailio trunk: http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#tm_module_ps...
The accounting server:
route{ # you should check the source IP also if(method=="ACCOUNTING" && $rU="store") { sql_query("ca", "insert into accounting(timeval,callid,ftag,ttag,src,dst) values ('$(rb{s.select,0,,})','$(rb{s.select,1,,})', ...)", "ra"); send_reply("200", "Stored"); } }
... and put your imagination work ... there are plenty of new and cute features you can add on your service with this functionality ...
Cheers, Daniel
2009/1/16 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
uac module provides a new function that allow sending sip requests from configuration file:
- uac_send_req()
http://kamailio.org/docs/modules/devel/uac.html#id2467912
It opens the door for a new bunch of things you can do now.
How! This is becoming a B2BUA XD
I can think of now:
- send IM alerts on special events
route { $uac_req(method)="MESSAGE"; $uac_req(ruri)="sip:alert@kamailio.org"; $uac_req(furi)="sip:server@kamailio.org"; $uac_req(hdrs)="Content-Type: text/plain\r\n"; $uac_req(body)="SIP request from:" + $si + ":" + $sp; uac_send_req(); }
Just a question: after sending the above MESSAGE, will the process wait for a reply to that MESSAGE? if so, could I access to the MESSAGE reply code and reason?
if(method=="ACCOUNTING" && $rU="store")
method "ACCOUNTING" !!?? Hum, I should warn IETF people about it XD
Great work.
Iñaki Baz Castillo wrote:
method "ACCOUNTING" !!?? Hum, I should warn IETF people about it XD
I plan to use this to implement the SIP 4.0 draft as soon as is practicable.
http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt
In particular, I will be doing away with BYEs, CANCELs, and ACKs and replacing them with permutations of an INVITE:
"Unlike RFC 3261, there is only one method: INVITE. There is no ACK, BYE, REGISTER, CANCEL, PRACK, UPDATE, INFO, MESSAGE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, etc. The concept here is simple: to make a session request (a "call") you use INVITE to "invite" a party to a session. To end a call you INVITE the UA to leave. To register, you INVITE a Registrar to send INVITEs to you. To send a Instant Message you INVITE a UA to render the MIME attachment. To subscribe to event state notifications you INVITE a UAS to send you INVITEs for events, and the notification is an INVITE to the UAC of an event occurring. To transfer a call you INVITE the caller to call someone else, or to join another session. You get the idea. These "intentions" of the INVITE are handled with invite-packages, defined later if we have time. "
2009/1/16 Alex Balashov abalashov@evaristesys.com:
Iñaki Baz Castillo wrote:
method "ACCOUNTING" !!?? Hum, I should warn IETF people about it XD
I plan to use this to implement the SIP 4.0 draft as soon as is practicable.
http://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt
In particular, I will be doing away with BYEs, CANCELs, and ACKs and replacing them with permutations of an INVITE:
"Unlike RFC 3261, there is only one method: INVITE. There is no ACK, BYE, REGISTER, CANCEL, PRACK, UPDATE, INFO, MESSAGE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, etc. The concept here is simple: to make a session request (a "call") you use INVITE to "invite" a party to a session. To end a call you INVITE the UA to leave. To register, you INVITE a Registrar to send INVITEs to you. To send a Instant Message you INVITE a UA to render the MIME attachment. To subscribe to event state notifications you INVITE a UAS to send you INVITEs for events, and the notification is an INVITE to the UAC of an event occurring. To transfer a call you INVITE the caller to call someone else, or to join another session. You get the idea. These "intentions" of the INVITE are handled with invite-packages, defined later if we have time. "
Very good joke :) I already readed it ;)
On 01/16/2009 02:28 PM, Iñaki Baz Castillo wrote:
2009/1/16 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
uac module provides a new function that allow sending sip requests from configuration file:
- uac_send_req()
http://kamailio.org/docs/modules/devel/uac.html#id2467912
It opens the door for a new bunch of things you can do now.
How! This is becoming a B2BUA XD
just 1UA so far...
I can think of now:
- send IM alerts on special events
route { $uac_req(method)="MESSAGE"; $uac_req(ruri)="sip:alert@kamailio.org"; $uac_req(furi)="sip:server@kamailio.org"; $uac_req(hdrs)="Content-Type: text/plain\r\n"; $uac_req(body)="SIP request from:" + $si + ":" + $sp; uac_send_req(); }
Just a question: after sending the above MESSAGE, will the process wait for a reply to that MESSAGE?
no, the process will not wait. To get the insight, it is like msilo sending stored messages upon receiving the REGISTER. The reply will come in another process.
if so, could I access to the MESSAGE reply code and reason?
You can, in default onreply route, with some trick (be carefully here) in local_route or sending the request to the proxy via $uac_req(ouri) and then process and arm onreply/failure route.
These for now, as the module has inside design for running onreply_route when reply is received, just that needs some fix for local timeout case (no reply received). To be added in the future.
if(method=="ACCOUNTING" && $rU="store")
method "ACCOUNTING" !!?? Hum, I should warn IETF people about it XD
:-)
Cheers, Daniel
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo