Hi,
i would advise you to take the current SVN release, as it is now very
close to 1.0 release. You could then get rid of the unix socket
interface and use SEMS's native SIP stack. This will be the prefered
method as of 1.0.
-Raphael.
S. wrote:
> Hello everyone,
>
> I installed OpenSER 1.2 and SEMS 0.10 but I am having problems making
> them work togeather. The point is: once I launch both programs, and
> try to make a call directed to sems, I get the following message on
> the debug screen of SEMS :
> /(15652) WARNING: wait4data (AmCtrlInterface.cpp:265): poll timed out
> (15652) ERROR: send_msg (AmServer.cpp:135): while waiting for Ser's
> response
> (15652) ERROR: onInvite (AmSession.cpp:595): 500 could not send response/
>
> and the following on the OpenSER debug screen :
> /1(15783) ERROR: tsend_dgram: failed to send: (13) Permission denied
> 1(15783) ERROR:tm: _reply_light: can't generate 500 reply when a
> final 200 was sent out
> 1(15783) ERROR:tm:unixsock_t_reply: reply failed
> 1(15783) ERROR: tsend_dgram: failed to send: (13) Permission denied
> 1(15783) unix_server_loop: Command 't_reply' failed with return value -1/
>
> Here is my SEMS config file :
> # Sip Express Media Server (sems)
> #
> # sample configuration file
> #
> #
> # whitespaces (spaces and tabs) are ignored
> # comments start with a "#" and may be used inline
> #
> # example: option=value # i like this option
> #
>
> # parameter: plugin_config_path=<path>
> #
> # - in this path configuration files of the applications
> # (e.g. announcement.conf) are searched
> plugin_config_path=/usr/local/etc/sems/etc/
>
> # optional parameter: fork={yes|no}
> #
> # - specifies if sems should run in daemon mode (background)
> # (fork=no is the same as -E)
> fork=yes
>
> # optional parameter: stderr={yes|no}
> #
> # - debug mode: do not fork and log to stderr
> # (stderr=yes is the same as -E)
> stderr=yes
>
> # optional parameter: loglevel={0|1|2|3}
> #
> # - sets log level (error=0, warning=1, info=2, debug=3)
> # (same as -D)
> loglevel=2
>
> # optional parameter: default_application
> # - this application is executed if the application is
> # not explicitely set with P-App-Name header/appname
> # parameter of unix command.
> #
> # example:
> # default_application = conference
>
> # optional parameter: socket_name=<filename>
> #
> # - path and file name of our unix socket
> # (where ser writes messages to)
> socket_name=/tmp/sems_sock
>
> # optional parameter: reply_socket_name=<filename>
> #
> # - path and file name of the unix socket where we
> # get replies from ser
> reply_socket_name=/tmp/sems_resp_sock
>
> # optional parameter: ser_socket_name=<filename>
> #
> # - path and file name of Ser's unix socket
> # (where we write messages to)
> ser_socket_name=/tmp/ser_sock
>
> # optional parameter: plugin_path=<path>
> #
> # - sets the path to the plug-ins
> # - may be absolute or relative to CWD
> plugin_path=/usr/local/lib/sems/plug-in/
>
>
> # optional parameter: rtp_low_port=<port>
> #
> # - sets lowest for RTP used port
> rtp_low_port=10000
>
> # optional parameter: rtp_high_port=<port>
> #
> # - sets highest for RTP used port
> rtp_high_port=60000
>
> # optional parameter: media_processor_threads=<num_value>
> #
> # - controls how many threads should be created that
> # process media - on single-processor systems set this
> # parameter to 1 (default), on MP systems to a higher
> # value
> media_processor_threads=1
>
> # optional parameter: listen=<ip_address>|<device>
> #
> # - this informs SEMS about the interface where its SER is
> # bound to. SEMS needs this information to correctly set
> # the contact header in outgoing calls and registrations.
> # Should be set to equal the 'listen' configuration option
> # in ser_sems.cfg.
> # If not set, this defaults to the interface SEMS binds to.
> # Examples:
> listen=192.168.202.9 <http://192.168.202.9>
> # listen=eth0
>
> #sip_port=5060
>
> # default=300 (5 minutes)
> #
> # Examples:
> # # disable RTP timeout
> # dead_rtp_time=0
> # # RTP timeout after 10 seconds
> # dead_rtp_time=10
>
>
> The call initiates but stopes one second later. I guess it is a socket
> problem but can not find any solution. Does anyone knows about this
> point and eventually has a solution ?
>
> Thank you very much for you help :)
> Skender
> ------------------------------------------------------------------------
>
> _______________________________________________
> Semsdev mailing list
> [email protected]
> http://lists.iptel.org/mailman/listinfo/semsdev
>
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
