한국어

소프트스위치

온누리070 플레이스토어 다운로드
    acrobits softphone
     온누리 070 카카오 프러스 친구추가온누리 070 카카오 프러스 친구추가친추
     카카오톡 채팅 상담 카카오톡 채팅 상담카톡
    
     라인상담
     라인으로 공유

     페북공유

   ◎위챗 : speedseoul


  
     PAYPAL
     
     PRICE
     

pixel.gif

    before pay call 0088 from app


http://staskobzar.blogspot.kr/2017/01/opensips-command-line-tricks.html


OpenSIPS provides powerful and flexible tool called "opensipsctl". Here I put some useful commands I am using while working with OpenSIPS to: restart phone, change MWI, change presence, remote dial with REFER.


Restart phone


Some SIP phones (Polycoms, Avaya, Aastra and more) support remote configuration reload or reboot when they receive SIP NOTIFY request with special "Event" header. Value of "Event" header depends on phone vendor implementation. Usually it is "check-sync" but some other vendors can have different values. Like Sipura will use "resync", Linksys - "reboot_now".

With "opensipsctl", we can do it as following (it's all in one line):

opensipsctl fifo t_uac_dlg NOTIFY sip:3864@10.0.20.52 . . '"From: <sip:3864@voip.proxy.com>;tag=8755a8d01a12f7e\r\nTo: <sip:3864@voip.proxy.com>\r\nEvent: check-sync\r\n"'

Details on the MI command "t_uac_dlg" can be found on transaction module (TM) OpenSIPS documentation page.

Here "sip:3864@10.0.20.52" is subscriber contact of the phone registered with OpenSIPS and "sip:3864@voip.proxy.com" is subscriber AOR. You can get these data with command:

opensipsctl ul show 3864@voip.proxy.com


MWI light on/off


When SIP user receive new voicemail, then SIP PBX sends NOTIFY request with Event "message-summary" and the body text with details about voicemail messages.

Here opensipsctl command to activate MWI light (it's all in one line):

opensipsctl fifo t_uac_dlg NOTIFY sip:299@voip.proxy.ca . . '"To: <sip:299@voip.proxy.ca>\r\nFrom: <sip:299@voip.proxy.ca>;tag=e17f5bec0b4bfb0bd\r\nEvent: message-summary\r\nContent-Type: application/simple-message-summary\r\nExpires: 3600\r\n"' '"Messages-Waiting: yes\r\nMessage-Account: sip:*97@voip.proxy.ca\r\nVoice-Message: 2/0 (0/0)\r\n"'

This command assumes that we subscriber "299@voip.proxy.ca" is registered with OpenSIPS server and (!) has subscribed to message-summary event. This can be checked with command: "opensipsctl fifo subs_phtable_list". That's why in this command, the request URI (sip:299@voip.proxy.ca) looks like a AOR and not a Contact with IP address. The point is OpenSIPS will check presence subscribers table in memory for subscriber "sip:299@voip.proxy.ca" and event "message-summary", recover the contact IP from the found record, and, finally, will create and send SIP packet to the good destination. The TM module will also take care that all the headers conform subscription session: call-id, from-tag, to-tag, content-length etc.
The header "Message-Waiting" must have value "yes". Another important header is "Voice-Message: 2/0 (0/0)". It means there 2 new messages and 0 old and in parentheses,   (0/0), it's number of urgent new/old messages.

Same is for deactivating MWI light. Just set "Messages-Waiting" to "no" and for "Voice-Message" new messages to 0. For example:

opensipsctl fifo t_uac_dlg NOTIFY sip:235@voip.proxy.ca . . '"To: <sip:299@voip.proxy.ca>\r\nFrom: <sip:299@voip.proxy.ca>;tag=e17f5bec0b4bfb0bac22d\r\nEvent: message-summary\r\nContent-Type: application/simple-message-summary\r\nExpires: 3600\r\n"' '"Messages-Waiting: no\r\nMessage-Account: sip:*97@voip.proxy.ca\r\nVoice-Message: 0/0 (0/0)\r\n"'


Actually, the same can be done with another MI function: "pua_publish" from module "pua_mi". While previous example can be changed to use IP address in R-URI and send "message-summary" notification even to users without voicemail subscriptions, pua_publish will send "notify" message only if there is a subscription exists.

Following command will activate MWI light:

opensipsctl fifo pua_publish sip:7402@voip.proxy.ca 3600 message-summary application/simple-message-summary . . '"Messages-Waiting: yes\r\nMessage-Account: sip:*97@voip.proxy.ca\r\nVoice-Message: 1/0 (0/0)\r\n\r\n"'

And this one to deactivate MWI light:

opensipsctl fifo pua_publish sip:7402@voip.proxy.ca 3600 message-summary application/simple-message-summary . . '"Messages-Waiting: no\r\nMessage-Account: sip:*97@voip.proxy.ca\r\nVoice-Message: 0/0 (0/0)\r\n\r\n"'

The difference is only "Message-Waiting" header, which is set to "no" and "Voice-Message" header.

Refer to dial


Some SIP phones support dial on REFER request behavior. Polycoms, for example, do support this. It is possible to simply send REFER SIP message to phone and  phone would initiate a call to the destination specified in the REFER message.
Here is an example:

opensipsctl fifo t_uac_dlg REFER sip:7329@10.10.0.141 . . '"From: <7329@voip.proxy.ca>;tag=123456789\r\nTo: <sip:7329@voip.proxy.ca>\r\nRefer-To: <sip:5553312244@voip.proxy.ca>\r\nRefer-Sub: false\r\n"'

MI function "t_uac_dlg" will send REFER to the user "7329" with contact IP "10.10.0.141". Notice, that this is initial dialog (no to-tag). When phone receives this message, it will initiat call to "5553312244" (see Refer-To header).

Presence state


Update presence state of the SIP phone is also quite easy with opensipsctl command and pua_publish function. As with an MWI example, phone must be subscribed to watch presence of particular user.

Following example will change presence state of "agent01@bar.voip.ca" to "open":

opensipsctl fifo pua_publish sip:agent01@bar.voip.ca 3600 presence application/pidf+xml . . "<?xml version='1.0'?><presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' entity='sip:agent01@bar.voip.ca'><tuple id='0x81475a1'><status><basic>open</basic></status></tuple></presence>"

After that message, it is expected that on all the phones that watch user "agent01@bar.voip.ca" the corresponding state indication would be changed. For example, it can be green light on the button or icon change, or some message on soft-phones. The implementation also depends on the phone vendors but usually follows PIDF specifications (for example RFC3863).

조회 수 :
49574
등록일 :
2017.09.13
05:06:37 (*.160.88.18)
엮인글 :
http://webs.co.kr/index.php?document_srl=3311877&act=trackback&key=de7
게시글 주소 :
http://webs.co.kr/index.php?document_srl=3311877
List of Articles