mirror of https://github.com/sipwise/sems.git
* pin_collect applications again has two modes: authentication via XMLRPC server, and sending out transfer REFER with PIN in URI * added documentation for pin_collect, and transfer for conference git-svn-id: http://svn.berlios.de/svnroot/repos/sems/trunk@257 8eb893ce-cfd4-0310-b710-fb5ebe64c474sayer/1.4-spce2.6
parent
eec606aedb
commit
0ce5e2c3d2
@ -1,6 +1,15 @@
|
||||
|
||||
# authentication mode:
|
||||
# XMLRPC : authenticate against XMLRPC server
|
||||
# REFER : add pin to REFER sent out to be checked at proxy
|
||||
auth_mode=XMLRPC
|
||||
|
||||
# XMLRPC url to authenticate against if auth_mode==XMLRPC
|
||||
auth_xmlrpc_url = http://127.0.0.1:9090/
|
||||
|
||||
# messages to play to caller
|
||||
welcome_msg=/usr/lib/sems/audio/pincollect/welcome.wav
|
||||
pin_msg=/usr/lib/sems/audio/pincollect/enter_pin.wav
|
||||
fail_msg=/usr/lib/sems/audio/pincollect/fail.wav
|
||||
auth_fail_msg=/usr/lib/sems/audio/pincollect/notcorrect.wav
|
||||
|
||||
auth_xmlrpc_url = http://127.0.0.1:9090/
|
||||
@ -0,0 +1,33 @@
|
||||
SEMS pin_collect application Readme
|
||||
|
||||
This application collects a PIN and then transfers using a
|
||||
(proprietary) REFER the call.
|
||||
|
||||
The authentication mode can be set in the configuration file
|
||||
(auth_mode parameter).
|
||||
|
||||
Authentication Modes:
|
||||
XMLRPC : Authenticate against an XMLRPC server (python example
|
||||
server in test/authserver.py
|
||||
|
||||
REFER : the transfer request (REFER) sent out has as user part of
|
||||
the URI the original user part, a plus sign, and the entered
|
||||
PIN. The PIN can thus be verified by the proxy handling the
|
||||
transfer REFER.
|
||||
|
||||
|
||||
"Transfer" REFER:
|
||||
The "Transfer REFER" is a proprietary REFER call flow which transfers a
|
||||
SIP dialog and session to another user agent ('taker'). If the transfer
|
||||
REFER is accepted, the one transfering the call just "forgets" the dialog
|
||||
and associated session, while the taker can send a re-Invite, thus overtaking
|
||||
the dialog and session. For this to work, both transferer and taker must
|
||||
be behind the same record routing proxy, and the callers user agent must
|
||||
properly support re-Invite (updating of contact, and session, as specified
|
||||
in RFC3261).
|
||||
|
||||
The transfer request sent out has two headers, which are needed by the
|
||||
entity taking the call:
|
||||
P-Transfer-RR : route set of the call
|
||||
P-Transfer-NH : next hop
|
||||
|
||||
Loading…
Reference in new issue