Hi All,
I have problem with URI module. Here my uri parameter setting :
# -- uri params --
modparam("uri", "db_url", "sql://ser:heslo@localhost/ser")
modparam("uri", "uri_table", "uri")
modparam("uri", "uri_user_column", "username")
modparam("uri", "uri_domain_column", "domain")
modparam("uri", "uri_uriuser_column", "uri_user")
modparam("uri", "subscriber_table", "subscriber")
modparam("uri", "subscriber_user_column", "username")
modparam("uri", "subscriber_domain_column", "domain")
And I got message error like these below :
linuxfedora5# ser -c
0(32960) set_mod_param_regex: parameter <db_url> not found in module <uri>
0(32960) parse error (203,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <uri_table> not found in module
<uri>
0(32960) parse error (204,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <uri_user_column> not found in
module <uri>
0(32960) parse error (205,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <uri_domain_column> not found in
module <uri>
0(32960) parse error (206,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <uri_uriuser_column> not found in
module <uri>
0(32960) parse error (207,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <subscriber_table> not found in
module <uri>
0(32960) parse error (208,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <subscriber_user_column> not found
in module <uri>
0(32960) parse error (209,20-21): Can't set module parameter
0(32960) set_mod_param_regex: parameter <subscriber_domain_column> not
found in module <uri>
0(32960) parse error (210,20-21): Can't set module parameter
ERROR: bad config file (8 errors)
0(32960) CHECK_UA - destroing module
linuxfedora5#
Does anyone help me to solve this problem ?
Thanks,
Asep
hi list!
we installed ser 0.9.6 on slackware 10.2 from source, all was working ok,
but it seems it doesn't restart on boot?
i put the executable file on /etc/rc.d/rc.local. two script below don't
start ser automatically when the box rebooted. is it a bug of ser? or
problem with slackware? no logs on /var/log/messages :( only ser don't start
on boot all other scripts put in rc.local start automatically.
# Run SER
#/usr/local/sbin/ser -f /usr/local/etc/ser/pstn.ser02
/usr/local/sbin/serctl start
thanks and regards,
emer
Peter,
thank you, first of all. i will try both and see how they work. i'm
pretty confident they will.
> The docs say that the add_uri_param will only work from the
> ROUTE function, so handling gateway failover could be an
> issue if you can't do it from the FAILURE_ROUTE thing...
>
in the failure_route i only do a ds_mark_dst(), send a "480 Temporarily
unavailable" reply, and trigger an alarm, instead of attempting to
relinquish to the next destination in sequence. most of the time the
caller's patience is less than the invite response timeout, and they
will hang up and dial again anyway.
> In theory (??) you should not have to do a ds_select_domain()
> with the CANCEL branch as the destination should already be
> known to OpenSER (as it routed the INVITE), so you should
> just be able to t_relay() it...
>
regarding the CANCEL, well... that's what i thought too, it should've
been routed properely by the transaction, but as far as i remember it
didnt seem to work. i'll give it a try again with 1.1. the BYE worked
though.
> Perhaps a feature request for the dispatcher module to
> support transport types as well??
before i had your answers, i was in fact thinking of doing that myself.
let me see how can i put up with what the docs say about the dispatcher
list file: "destination must be a valid SIP URI".
have a good day,
Radu M
AFAIK, there is no single place to find all the @vars. It's still on the
to-do...
Jan: Could you provide some quick pointers?
g-)
Luis Silva wrote:
>
> Hi Greger, where can I find the complete list of all the @vars?
>
> @from, @from.uri, @to, @to.uri, @from.tag, @from.name, @to.tag.
> @to.name, @from.params, @to.params, @contact, @contact.uri,
> @contact.params, @contact.expires, @contact.q, @via, and so on. <---
>
> Regards,Luis Silva
>
>
>
>
>> From: "Greger V. Teigre" <greger(a)teigre.com>
>> To: sip <sip(a)arcdiv.com>
>> CC: serusers(a)lists.iptel.org
>> Subject: Re: SER CVS head, new select identifiers info - was - Re:
>> [Serusers]Textops with AVPs?
>> Date: Wed, 12 Jul 2006 08:47:11 +0200
>>
>> It's in head only (0.10.x track)
>> g-)
>>
>> sip wrote:
>>> Greger,
>>>
>>> Sounds incredibly handy. Is this available only in SER head or is it
>>> something
>>> that's been around for a little while (i.e. do I have any hope of
>>> using it in
>>> ser 0.9.6) ?
>>>
>>>
>>> N.
>>>
>>>
>>> On Tue, 11 Jul 2006 21:18:38 +0200, Greger V. Teigre wrote
>>>
>>>> I repost Jan's original description of the "select identifier"
>>>>
>>> functionality. Since then, more select identifiers have been added,
>>> both from
>>> core and modules.
>>> g-)
>>>
>>> SER core can parse select identifiers using the configuration parser.
>>> A select identifiers begins with @ characters and contains several
>>> components/tokens delimited by . (unless it is integer component).
>>> Integer components are enclosed in [], for example:
>>>
>>> @contact[1].uri
>>>
>>> This identifier is converted into binary structure which contains the
>>> array of components. After that the parser tries to lookup function
>>> that matches the identifier.
>>>
>>> Available functions are arranged in a tree-like structure. When
>>> looking up a function the tree is traversed (starting at the root)
>>> until the parser finds corresponding function. The part of the tree
>>> containing TLS functions looks like:
>>>
>>> "tls"-+-"peer"-+-"subj"-+-"name" (select_peer_name())
>>> | \
>>> | "state" (select_peer_state())
>>> |
>>> +-"issuer"-+-"name" (select_peer_issuer_name())
>>> \
>>> "state" (select_peer_issuer_state())
>>>
>>> Thus when you write @tls.peer.subj.state in the configuration file
>>> then the parser will traverse the tree until it reaches
>>> select_peer_state() function and then it would remember that this
>>> function should be called.
>>>
>>> The tree of identifiers and functions is built dynamically at runtime.
>>> This is a nice feature becase this way modules can register their own
>>> functions or whole subtrees and make their functions available in the
>>> configuration file.
>>>
>>> Thus if you load TLS module then all @tls.* selects become avaiable,
>>> if you do not load the module they are not available. Only a couple of
>>> core functions and the framework is built in the core, the rest can be
>>> in modules.
>>>
>>> This framework is currently used in tls and xmlrpc modules. XMLRPC
>>> module exports the name of the XML-RPC method to the script. TLS
>>> module exports information from TLS layer.
>>>
>>> The SER core itself contains a couple of functions that can retrieve
>>> various parts of a SIP message:
>>>
>>> @from, @from.uri, @to, @to.uri, @from.tag, @from.name, @to.tag.
>>> @to.name, @from.params, @to.params, @contact, @contact.uri,
>>> @contact.params, @contact.expires, @contact.q, @via, and so on.
>>>
>>> TLS related functions are described in a separate email.
>>>
>>>> sip wrote: Sounds like something I might look more into. Thanks,
>>>> Greger. Is
>>>>
>>> there
>>> anything written more about @var constructs? I checked the admin
>>> guide (I
>>> know... that was kind of silly considering how out of date it is ;)
>>> ), and
>>> tried to do a search in Google (it seems to ignore the @, so @var
>>> just gives
>>> me every message with the word 'var' in it) and didn't see anything.
>>> Is there
>>> anything over at OnSIP discussing it?
>>>
>>> N.
>>>
>>> On Tue, 11 Jul 2006 08:35:11 +0200, Greger V. Teigre wrote
>>> If this functionality was added in later openser versions than 0.9,
>>> it will most likely not be in SER. What you are describing is hard
>>> to do with the avpops version in 0.9. The avpops module was generic
>>> enough to do more than it was designed for; making some code
>>> operations quite dirty in 0.9 (using the ruri as a temporary storage
>>> while manipulating a variable). SER head uses @var to more directly
>>> access data instead of going through a module. You may want to have
>>> a look at it! g-)
>>>
>>> sip wrote:
>>> Is there a version of textops that can do substs with AVPs that
>>> will work on
>>> SER 0.9.6 or is that an openSER-only modification of the code?
>>>
>>> I'm curious because we're ALSO running into the issues of charging the
>>> call-forwarding user for forwarding a call to the PSTN instead of
>>> charging the
>>> calling party. Ideally, I'd like to rewrite the from address solely
>>> for the
>>> purpose of authenticating the user who's doing the forwarding and
>>> charging him
>>> for the call, but that would likely break things as there'd be no
>>> way to get
>>> back to the original user if I just rewrote the from username.
>>>
>>> SO, I thought, why not let the b2bua handle the details and just
>>> forward a uri
>>> with a prefix string that includes the user who's forwarding the
>>> call (the
>>> original RURI instead of just the rewritten one).
>>>
>>> And there's the trick. How do I craft a RURI out of bits and pieces
>>> of things
>>> into one long RURI?
>>>
>>> If it were all the same number, I could use prefix, but it's dynamic
>>> (as is
>>> the nature of most things), so prefix won't work.
>>>
>>> How do I take
>>>
>>> RURI=1105
>>>
>>> And add to it:
>>>
>>> The rewritten RURI from the call forwarding info: 18005551212
>>>
>>> AND the prefix for the b2bua auth: 9999
>>>
>>> To make:
>>>
>>> new ruri: 9999110518005551212
>>>
>>> N.
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers@lists.iptel.orghttp://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>>
>>>
>
>
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)lists.iptel.org
>> http://lists.iptel.org/mailman/listinfo/serusers
>
>
>
hi all,
i need to use the dispatcher module to route (load-balanced) an incoming
SIP request to one of my bunch of asterisk machines. openser (1.1.0, the
only one that implements the dispatcher as i need it) is also supposed
to translate from TCP (the protocol that my peer gateway uses) to UDP
(the only protocol that asterisk knows - snip).
my attempt was this:
# routing INVITE and CANCEL messages received from the gateway to
Asterisk
if (uri=~"^sip:\+1[0-9]+@xx\.xx\.xx\.xx") {
t_on_failure("2");
if ((method=="INVITE") || (method=="CANCEL")) {
ds_select_dst("1", "0");
t_relay("udp:$dd:5061");
return;
}
}
note that t_relay() must change the protocol type and set a non-default
port number. the problem is that the $dd pseudovariable in t_relay() is
not parsed, i actually get an error at openser startup:
Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]: ERROR: mk_proxy:
could not resolve hostname: "$dd"
Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]:
ERROR:tm:fixup_phostport2proxy: failed to resolve <$dd>
Jul 11 14:43:31 davinci /usr/local/sbin/openser[16906]: ERROR:
fix_actions: fixing failed (code=-478) at cfg line 119
anybody has any idea about how can i either:
(A) set the preferred protocol and destination port for the transaction,
then call t_relay() with no arguments, OR
(B) capture the destination domain name selected by the dispatcher in a
variable, append "udp:" in front of it and ":5061" at the end, and feed
it as argument to t_relay().
a hint would be great, a few lines of code would be even better ;) since
i have some trouble locating the documentation for the core functions.
thanks!
Radu M.
Hello all,
I've recently upgraded from 1.0.0 cvs to 1.1.0 release and the db functions have seemed to quit working.
[bp@boognish openser]$ /usr/sbin/openserctl lcr show
WARINIG: no database engine found - tried ''
This command requires a database engine - none was loaded
It seems like loadmodule "/usr/lib/openser/modules/mysql.so" in openser.cfg isn't doing the trick anymore.
I have used openser_mysql.sh to reinstall the databases, which are in the default places.
Any ideas what's going on?
Britton
Thanks,
That configuration is accepted but now my "registered" client is denied at both following lines:
if (!lookup_user("From")) {
if ((!avp_equals_xl("$registered_host", "%si") || !avp_equals_xl("$registered_port", "%sp"))) {
How can I print $registered_host to log ?
I can print %si with xlog().
Thanks,
ilker
-----Original Message-----
From: Miklos Tirpak [mailto:miklos@iptel.org]
Sent: Wednesday, July 12, 2006 4:01 PM
To: İlker Aktuna (Koç.net)
Cc: serusers(a)iptel.org
Subject: Re: [Serusers] prevent INVITE without REGISTERing
İlker Aktuna (Koç.net) wrote:
>
>
> Thanks Miklos,
>
> I think this is just what I'm looking for.
> But I get some errors for this line:
> if ((src_ip != @ruri.host) || (src_port != @ruri.port)) {
You can access src_ip and src_port via xl_lib:
$registered_host = @ruri.host;
$registered_port = @ruri.port;
if ((!avp_equals_xl("$registered_host", "%si"))
|| (!avp_equals_xl("$registered_port", "%sp"))) {
...
Miklos
>
> 0(30074) parse error (175,16-17): syntax error
> 0(30074) parse error (175,16-17): ip address or hostname expected
> 0(30074) parse error (175,16-17): bad command
> 0(30074) parse error (175,21-22): bad command
> 0(30074) parse error (175,21-22): bad command
> 0(30074) parse error (175,26-27): bad command
> 0(30074) parse error (175,26-27): bad command
> 0(30074) parse error (175,28-30): bad command
> 0(30074) parse error (175,31-32): bad command
> 0(30074) parse error (175,32-40): bad command
> 0(30074) parse error (175,41-43): bad command
> 0(30074) parse error (175,44-45): bad command
> 0(30074) parse error (175,49-50): bad command
> 0(30074) parse error (175,49-50): bad command
> 0(30074) parse error (175,54-55): bad command
> 0(30074) parse error (175,54-55): bad command
> 0(30074) parse error (175,55-56): bad command
> 0(30074) parse error (175,57-58): bad command
>
> Any idea why ?
>
> Thanks,
> ilker
>
> -----Original Message-----
> From: Miklos Tirpak [mailto:miklos@iptel.org]
> Sent: Wednesday, July 12, 2006 11:58 AM
> To: İlker Aktuna (Koç.net)
> Cc: serusers(a)iptel.org
> Subject: Re: [Serusers] prevent INVITE without REGISTERing
>
> Hi Ilker,
>
> just my first idea, not tested:
>
>
> 1. lookup the From HF
>
> if (!lookup_user("From")) {
> # reject the INVITE
> ...
> }
>
> 2. save original To UID and Request URI
>
> $orig_to_uid = $tu.uid;
> $orig_req_uri = @ruri;
>
> 3. set To UID -- registrar module will use this in the lookup
>
> $tu.uid = $fu.uid;
>
> 4. lookup From HF and compare the source address of the INVITE with
> the source address of the REGISTER message
>
> if (lookup("location")) {
> if ((src_ip != @ruri.host) || (src_port != @ruri.port)) {
> # reject the INVITE
> ...
> }
> # restore original To UID and Request URI
> $tu.uid = $orig_to_uid;
> attr2uri("$orig_req_uri");
> } else {
> # reject the INVITE
> ...
> }
>
> Note, that the above solution is a bit ugly, you can get into troubles
> when the user registers multiple contact addresses. It is better to
> disable branches (see append_branches parameter in registrar module),
> but you loose some functionality.
>
> Regards,
> Miklos
>
> İlker Aktuna (Koç.net) wrote:
> >
> > Hi everyone,
> >
> > I am still trying to find a solution to this problem. (but couldn't
> > find > yet) > Victor was trying to help me but I think he's not
> able to reply these days.
> >
> > Is there any idea to achieve what I need.
> >
> > Thanks,
> > ilker
> >
> >
> ----------------------------------------------------------------------
> > --
> > *From:* serusers-bounces(a)lists.iptel.org >
> [mailto:serusers-bounces@lists.iptel.org] *On Behalf Of *İlker Aktuna
> > (Koç.net) > *Sent:* Tuesday, July 11, 2006 1:41 PM > *To:* Victor
> Stanescu > *Cc:* serusers(a)iptel.org > *Subject:* RE: [Serusers]
> prevent INVITE without REGISTERing > > Hi, > > What if my proxy
> does not handle authenticating INVITE messages ?
> >
> > In that case I think the best way is to lookup location table for
> the > source URI.
> > If the source URI location matches the location in that table then
> we > must permit INVITE message.
> > How can I configure this ?
> >
> > Thanks,
> > ilker
> >
> > -----Original Message-----
> > From: serusers-bounces(a)lists.iptel.org >
> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Victor Stanescu
> > Sent: Monday, July 10, 2006 1:49 PM > Cc: serusers(a)iptel.org >
> Subject: Re: [Serusers] prevent INVITE without REGISTERing > >
> Please read "domain" instead of "gtstelecom.ro":
> > www_authorize("domain",
> > "subscriber") and proxy_authorize("domain", "subscriber"),
> otherwise > the code fragment will not be correct. I forgot to
> replace with a generic name.
> >
> > Victor Stanescu wrote:
> > > I think it is easier to force him to authenticate the INVITE. If
> he > is > able to authenticate the INVITE, why do you care if he is
> > registered > or not?
> > >
> > > if (method=="REGISTER") {
> > > if(!src_ip=="other") {
> > > if (!www_authorize("gtstelecom.ro", "subscriber")) {
> > > www_challenge("domain", "0");
> > > break;
> > > };
> > > save("location");
> > > log("Replicating REGISTER\n");
> > > t_replicate("other", "5060");
> > > } else {
> > > save("location");
> > > };
> > > break;
> > > } else {
> > > # this is an INVITE
> > > if (!proxy_authorize("gtstelecom.ro", "subscriber")) {
> > > proxy_challenge("domain", "1");
> > > break;
> > > };
> > > # route the call
> > > ...
> > > };
> > >
> > > İlker Aktuna (Koç.net) wrote:
> > >>
> > >> Hi all,
> > >>
> > >> Is it possible to prevent any user calling without registering ?
> > What >> is the best way to do this ?
> > >> I guess I'll have to check if the source URI exists in location
> table.
> > >> What is the easiest way to do this ?
> > >>
> > >> If there is a more robust way to do it, please suggest...
> > >>
> > >> Thanks,
> > >> ilker
> > >>
> > >>
> >
> >
> >
<http://387555.sigclick.mailinfo.com/sigclick/00090507/060D4E00/00010A4E/011…>
_____________________________________________________________________________________________________________________________________________
Bu e-posta mesaji kisiye ozel olup, gizli bilgiler iceriyor olabilir. Eger bu e-posta mesaji size yanlislikla ulasmissa, icerigini hic bir sekilde kullanmayiniz ve ekli dosyalari acmayiniz. Bu durumda lutfen e-posta mesajini kullaniciya hemen geri gonderiniz ve tum kopyalarini mesaj kutunuzdan siliniz. Bu e-posta mesaji, hic bir sekilde, herhangi bir amac icin cogaltilamaz, yayinlanamaz ve para karsiligi satilamaz. Bu e-posta mesaji viruslere karsi anti-virus sistemleri tarafindan taranmistir. Ancak yollayici, bu e-posta mesajinin - virus koruma sistemleri ile kontrol ediliyor olsa bile - virus icermedigini garanti etmez ve meydana gelebilecek zararlardan dogacak hicbir sorumlulugu kabul etmez.
This message is intended solely for the use of the individual or entity to whom it is addressed , and may contain confidential information. If you are not the intended recipient of this message or you receive this mail in error, you should refrain from making any use of the contents and from opening any attachment. In that case, please notify the sender immediately and return the message to the sender, then, delete and destroy all copies. This e-mail message, can not be copied, published or sold for any reason. This e-mail message has been swept by anti-virus systems for the presence of computer viruses. In doing so, however, sender cannot warrant that virus or other forms of data corruption may not be present and do not take any responsibility in any occurrence.
_____________________________________________________________________________________________________________________________________________
Hi,
Has anybody experience with eyeBeam 1.5?
I tested eyeBeam 1.5.7 build 31195 with the SER Presence Snapshot.
Basic Presence works O.K.
Presence Notes (e.g. Basic: Open, Note: Busy) are not processed by the SER PA module.
I traced and found the following differences to the old eyeBeam 1.1 (eyeBeam release 3014w stamp 26703).
eyeBeam 1.5.7 presence document in PUBLISH:
<?xml version='1.0' encoding='UTF-8'?>
<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:par ams:xml:ns:pidf:cipid'
entity='pres:sip:a.schula@10.241.143.158'>
<tuple id='td4760a41'>
<status>
<basic>open</basic>
</status>
</tuple>
<dm:person id='paf70ec41'>
<rpid:activities>
<rpid:busy/>
<rpid:unknown/>
</rpid:activities>
<dm:note>Busy</dm:note>
</dm:person>
</presence>
And here the working resence document from eyeBeam 1.1 PUBLISH:
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:pp="urn:ietf:params:xml:ns:pidf:person"
xmlns:et="urn:ietf:params:xml:ns:pidf:rpid:rpid-tuple"
xmlns:ep="urn:ietf:params:xml:ns:pidf:rpid:rpid-person"
xmlns:es="urn:ietf:params:xml:ns:pidf:rpid:status:rpid-status"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
entity="sip:T2@10.241.143.158">
<pp:person>
<status>
<ep:activities>
<ep:away/>
</ep:activities>
</status>
</pp:person>
<note>Away</note>
<tuple id="7520193f">
<contact priority="1">
sip:T2@10.241.143.158
</contact>
<status>
<basic>open</basic>
<es:user-input
since="2006-07-12T15:34:42Z">
idle
</es:user-input>
</status>
</tuple>
</presence>
Is there anything I can do to get presence notes working with eyeBeam 1.5.x?
Best regards
A. Schula
--
Echte DSL-Flatrate dauerhaft für 0,- Euro*!
"Feel free" mit GMX DSL! http://www.gmx.net/de/go/dsl