Hi,all
I have some questions.
the hardware require is only ISDN card,or not?
And I don't understand ISDN card very much.It connect to my computer and
telephone?like this?
_________ _________ ________________ ______
| telephone |----- | ISDN card | ----- |computer(ser server)| -----| SIP UA|
so, I can call this telephone by my sip ua through ISDN card?Am I right?
And the ISDN card need any support? which type or which function?
If I want to buy the ISDN card, somewhat I need to know?
thanks.
>Hi,
>I am happy to announce, that the isdngw reached beta state, thus I want to
>encourage everyone interested in testing the PSTN gateway.
>isdngw is a PSTN2SIP and SIP2PSTN gateway included in SEMS. It runs on
Linux
>and requires only a supported ISDN card (BRI or PRI).
>A new site for isdngw was launched, too. Find installation instructions and
a
>list of supported cards there:
>http://www.iptel.org/isdngw
>Any feedback, may it be bug reports, information on ISDN controllers, any
>other comments or success stories ;-) are very much appreciated.
>Regards,
>Uli.
i am having problems on login to serweb, logins are the default the username
is "admin" and the password is "heslo" when hit enter i get the login screen
again
At 01:04 AM 10/5/2004, Michael Shuler wrote:
>My intent is to do SIP load balancing using a layer 4 hardware switch (such
>as a Foundry ServerIron XL) or a layer 4 software switch (such as
>UltraMonkey).
>
>Since SER *could* operate in a completely stateless mode it could serve as a
>per packet proxy in front of a series of stateful feature servers such as
>Asterisk. A L4 device by itself would not be enough and a stateless MUST be
>in front to do the actually balancing because of SIP's flaw/design of
>containing routing information throughout the packets life.
I don't think that this specific issue is SIP design flaw. It is coming
from the proxy mode which is useful for many reasons. Achieving consistency
with a proxy and load-balancer is not as easy as for banal request-response
apps like web.
>It would have
>been nicer if it only carried a source and destination and worked more like
>TCP/IP but unfortunately it is what it is.
>
>Anyway, I about have everything working and I only seem to have a small
>issue when the second SER server comes online with some strange message
>passing between them. Most of it I believe is caused by my lack of
>understanding of how SER makes some decisions on where to send things.
It depends on what you mean by things. If you mean log error than these
are sent to syslog. If you mean replies, their destination is governed
by RFC3261 and rport extensions. If you mean proxied requests, than
the destination is governed by routing script.
>I
>think what would help is if I setup a "work in progress" web site that would
>show all my config files and the layout of the whole thing along with an
>explanation of why I decided to do what I did. I should have it up later
>today or tomorrow.
>
>----------------------------------------
>
>Michael Shuler, C.E.O.
>BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
>682 High Point Lane
>East Peoria, IL 61611
>Office: (217) 585-0357
>Cell: (309) 657-6365
>Fax: (309) 213-3500
>E-Mail: mike(a)bwsys.net
>Customer Service: (877) 976-0711
>
>> -----Original Message-----
>> From: Jiri Kuthan [mailto:jiri@iptel.org]
>> Sent: Monday, October 04, 2004 5:42 PM
>> To: Michael Shuler; serusers(a)lists.iptel.org
>> Cc: jan(a)iptel.org
>> Subject: RE: [Serusers] forward() and t_relay() differences
>>
>>
>> At 07:50 PM 10/4/2004, Michael Shuler wrote:
>> >Sorry if that first line sounded snotty, I didn't mean it
>> that way. I
>> >didn't read it until after I sent it. What I meant to say
>> was thank you for
>> >the response.
>>
>> you are very welcome.
>>
>> > I had already been through the docs though and found that too
>> >but I was still seeing the following problem..
>>
>> I am interestd in more feedback on load-balancers. To my
>> knowledge, it is
>> a technology which has some conflicts with SIP protocol and
>> those LBs that
>> try to fix the problems using built-in SIP awareness don't do
>> necessarily
>> any better. We are working on a SER built-in load-balancing
>> architecture
>> but that's still work in progress.
>>
>> -jiri
>>
--
Jiri Kuthan http://iptel.org/~jiri/
At 12:51 AM 10/5/2004, Franklin, Allen wrote:
>A very basic hook is provided that allows a script to call functions in a user-provided shared library,
>but this hook is only useful for rewriting the URI of the "current" message.
Thats incorrect. The shlibs can do and do much more than URI rewriting. See module list
and what they do.
>SER does not allow scripts or app server processes to see or modify the SDP, so an app
>server process could not be used to initiate a voice call.
There are modules that do SDP mangling. nathelper for example.
>SER does not have a SIP parser as would be found in a traditional SIP stack.
I don't know what a traditional SIP stack is but if you mean something slow
that SER doesn't have it ;) It is not available as a separate library if you
mean that.
Otherwise your assessment has been correct. If you are looking for a real
application server (meaning a stateful call control element) than it is
not SER. We have AA (www.iptel.org/aa).
-jiri
I have been trying to figure out if I can use the SER server as a true app server.
I have summarized my findings, below.
The findings are quite terse (I'm writing it for my superiors) and may sound a little
harsh, but that's not my intent. I am just hoping to generate some discussion.
Summary of using SER as an app server:
Controlling SER using scripts
-----------------------------
Routing scripts can be written by a user.
Only a single script is processed by the engine.
The SER server hands every SIP message it receives to the script processing engine.
The script may add/remove/modify header fields and then tell SER what to do with the result.
The script always operates on the "current" SIP message.
The scripts must be written in a SER-developed language.
The language provides operators and functions for manipulating string values in SIP headers.
The language provides routing functions like forward() and t_relay().
The script engine provides hooks to allow a script to execute shell commands.
A very basic hook is provided that allows a script to call functions in a user-provided shared library,
but this hook is only useful for rewriting the URI of the "current" message.
Controlling SER through an external process
-------------------------------------------
The SER server provides an interface to its internal functions via its "Application FIFO Server".
The IPC mechanism employed is a pair of fifos (or files).
There is a set of defined FIFO commands that the app can send to SER.
There is only 1 FIFO command for initiating a transaction from an external process: t_uac() (also t_uac_dlg()).
The app blocks on a fifo read until the server matches up a reply from the last command sent,
the complete message text is returned in the read. Presumably SER will handle retransmissions.
SER does not allow scripts or app server processes to see or modify the SDP, so an app
server process could not be used to initiate a voice call.
SER does not have a SIP parser as would be found in a traditional SIP stack.
At 07:50 PM 10/4/2004, Michael Shuler wrote:
>Sorry if that first line sounded snotty, I didn't mean it that way. I
>didn't read it until after I sent it. What I meant to say was thank you for
>the response.
you are very welcome.
> I had already been through the docs though and found that too
>but I was still seeing the following problem..
I am interestd in more feedback on load-balancers. To my knowledge, it is
a technology which has some conflicts with SIP protocol and those LBs that
try to fix the problems using built-in SIP awareness don't do necessarily
any better. We are working on a SER built-in load-balancing architecture
but that's still work in progress.
-jiri
I see in the example in the SER documentation for forward-on-no-answer to
voicemail that they use something they call a sink port. Anyone know what
this is? I'd like to do the following, as goes pseudocode:
...
db-voicemail flag set?
set timeouts to 16s, initiate call
if doesn't go through to registered destination, send to vm
else flag not set?
set timeouts to 180s, initiate call
if doesn't go through, issue 487
end
Is the sink port something I can or have to set up? Do I need it for this?
It seems non-obvious. Thanks.
-Keith, TSS
hi,
you can also uncomment the debug section in the ser.cfg, which will print out some debug infos.
useful when some modules or shared-libs cannot be loaded or found.
regards
thomas
________________________________
Von: serusers-bounces(a)lists.iptel.org im Auftrag von Michael Shuler
Gesendet: Mo 04.10.2004 18:07
An: 'Evgeny Ivanov'; serusers(a)lists.iptel.org
Betreff: RE: [Serusers] Debuging configuration
Ser -c give you more info
----------------------------------------
Michael Shuler, C.E.O.
BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
682 High Point Lane
East Peoria, IL 61611
Office: (217) 585-0357
Cell: (309) 657-6365
Fax: (309) 213-3500
E-Mail: mike(a)bwsys.net
Customer Service: (877) 976-0711
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Evgeny Ivanov
> Sent: Monday, October 04, 2004 10:39 AM
> To: serusers(a)lists.iptel.org
> Subject: [Serusers] Debuging configuration
>
>
> HI again,
>
> When I add something in ser.cfg it gives me this - ERROR: bad config
> file (2 errors). How can I determine where is the problem and to fix
> it ?
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
http://www.iptel.org/ser/doc/seruser/seruser.html#AEN923
At 06:42 PM 10/4/2004, Michael Shuler wrote:
>What is the difference between forward(uri:host, uri:port) and t_relay()?
>
>I understand that t_relay() is supposed to be transaction based but I really
>can't see a difference between the two.
>
>
>
>----------------------------------------
>
>Michael Shuler, C.E.O.
>BitWise Communications, Inc. (CLEC) And BitWise Systems, Inc. (ISP)
>682 High Point Lane
>East Peoria, IL 61611
>Office: (217) 585-0357
>Cell: (309) 657-6365
>Fax: (309) 213-3500
>E-Mail: mike(a)bwsys.net
>Customer Service: (877) 976-0711
>
>_______________________________________________
>Serusers mailing list
>serusers(a)lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers
--
Jiri Kuthan http://iptel.org/~jiri/
