Dear all,
I have problem in my aliases. every user that subscribe always get the sama aliases. how could it be?.
please help me!! any idea??
this is my script at ser.cfg:
#
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
debug=7
fork=yes
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
listen=192.168.10.64
listen=127.0.0.1
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so"
loadmodule "/usr/lib/ser/modules/registrar.so"
loadmodule "/usr/lib/ser/modules/textops.so"
loadmodule "/usr/lib/ser/modules/auth.so"
loadmodule "/usr/lib/ser/modules/auth_db.so"
loadmodule "/usr/lib/ser/modules/nathelper.so"
loadmodule "/usr/lib/ser/modules/msilo.so"
loadmodule "/usr/lib/ser/modules/acc.so"
loadmodule "/usr/lib/ser/modules/group.so"
loadmodule "/usr/lib/ser/modules/vm.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database
# for persistent storage and comment the previous line
modparam("usrloc", "db_mode", 2)
modparam("usrloc", "timer_interval", 10)
#mod acc
modparam("acc", "log_missed_flag", 3)
modparam("acc", "log_level", 1)
modparam("acc", "log_flag", 1)
#rrparams
modparam("rr", "enable_full_lr", 1)
#tm params
modparam("tm", "fr_timer", 12)
modparam("tm", "fr_inv_timer", 24)
# -- auth params --
# Uncomment if you are using auth module
#
modparam("auth_db", "calculate_ha1", yes)
#
# If you set "calculate_ha1" parameter to yes (which true in this config),
# uncomment also the following parameter)
#
modparam("auth_db", "password_column", "password")
# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
alias="sip.pcr.ac.id"
alias="gateway.sip.pcr.ac.id"
alias="192.168.10.64"
route{
# initial sanity checks -- messages with
# max_forwards==0, or excessively long requests
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
# loose-route processing
if (loose_route()) {
t_relay();
break;
};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
if (method=="REGISTER") {
# Uncomment this if you want to use digest authentication
if (!www_authorize("sip.pcr.ac.id", "subscriber")) {
www_challenge("sip.pcr.ac.id", "0");
break;
};
save("location");
break;
# -- aliases --
lookup("aliases");
if (!uri==myself)
{
append_hf("P-hint: outbound alias\r\n");
route(1);
break;
};
};
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
sl_send_reply("404", "Not Found");
break;
};
};
# forward to current uri now; use stateful forwarding; that
# works reliably even if we forward from TCP to UDP
if (!t_relay()) {
sl_reply_error();
};
}
route[1]
{if (!t_relay())
{
sl_reply_error();
};
}
Sita Rosita
___________________________________________________
Build your own website, it's easy and fun.
http://www.homemaster.net - Homemaster. Come Together. Online.
Hi all,
I'm using the last month SER with SEMS and one CAPI card and works fine,
well almost fine since I was not able to handle any kind of transfer (blind
or supervised) between PSTN and SIP .
Has anyone done it? I'm a little bit confused and I was wondering if I
should hack sems/isdngw module to handle it or I can do it with a config
file alone.
Looking forward for your answers
Sotiris
PS: I'm using the default isdngw file, with one split(1) command to extract
the 0 before forwarding it via the vm command to the isdngw module.
Dear all,
I have problem in my aliases. every user that subscribe always get the sama aliases. how could it be?.the aliases can't up counter automatically when user subscribe.
please help me!! any idea??
this is my script at ser.cfg:
#
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
#
# simple quick-start config script
>#
>
># ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (cmd line: -E)
/* Uncomment these lines to enter debugging mode
debug=7
fork=yes
log_stderror=yes
*/
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
port=5060
children=4
fifo="/tmp/ser_fifo"
listen=192.168.10.64
listen=127.0.0.1
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
loadmodule "/usr/lib/ser/modules/mysql.so"
loadmodule "/usr/lib/ser/modules/sl.so"
loadmodule "/usr/lib/ser/modules/tm.so"
loadmodule "/usr/lib/ser/modules/rr.so"
loadmodule "/usr/lib/ser/modules/maxfwd.so"
loadmodule "/usr/lib/ser/modules/usrloc.so">loadmodule "/usr/lib/ser/modules/registrar.so"
>loadmodule "/usr/lib/ser/modules/textops.so"
>loadmodule "/usr/lib/ser/modules/auth.so"
>loadmodule "/usr/lib/ser/modules/auth_db.so"
>loadmodule "/usr/lib/ser/modules/nathelper.so"
>loadmodule "/usr/lib/ser/modules/msilo.so"
>loadmodule "/usr/lib/ser/modules/acc.so"
>loadmodule "/usr/lib/ser/modules/group.so"
>loadmodule "/usr/lib/ser/modules/vm.so"
>
>
>
># ----------------- setting module-specific parameters ---------------
>
># -- usrloc params --
>
>#modparam("usrloc", "db_mode", 0)
>
># Uncomment this if you want to use SQL database
># for persistent storage and comment the previous line
>
>modparam("usrloc", "db_mode", 2)
>modparam("usrloc", "timer_interval", 10)
>
>
>#mod acc
>modparam("acc", "log_missed_flag", 3)
>modparam("acc", "log_level", 1)
>modparam("acc", "log_flag", 1)
>
>#rrparams
>modparam("rr", "enable_full_lr", 1)
>
>#tm params
>
>modparam("tm", "fr_timer", 12)
>modparam("tm", "fr_inv_timer", 24)
>
># -- auth params --
># Uncomment if you are using auth module
>#
>
>modparam("auth_db", "calculate_ha1", yes)
>
>#
># If you set "calculate_ha1" parameter to yes (which true in this config),
># uncomment also the following parameter)
>#
>modparam("auth_db", "password_column", "password")
>
># -- rr params --
># add value to ;lr param to make some broken UAs happy
>modparam("rr", "enable_full_lr", 1)
>
>
># ------------------------- request routing logic -------------------
>
># main routing logic
>
>alias="sip.pcr.ac.id"
>alias="gateway.sip.pcr.ac.id"
>alias="192.168.10.64"
>
>route{
>
> # initial sanity checks -- messages with
> # max_forwards==0, or excessively long requests
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> break;
> };
> if ( msg:len > max_len ) {
> sl_send_reply("513", "Message too big");
> break;
> };
>
> # we record-route all messages -- to make sure that
> # subsequent messages will go through our proxy; that's
> # particularly good if upstream and downstream entities
> # use different transport protocol
> record_route();
> # loose-route processing
> if (loose_route()) {
> t_relay();
> break;
> };
>
> # if the request is for other domain use UsrLoc
> # (in case, it does not work, use the following command
> # with proper names and addresses in it)
> if (uri==myself) {
>
> if (method=="REGISTER") {
>
># Uncomment this if you want to use digest authentication
> if (!www_authorize("sip.pcr.ac.id", "subscriber")) {
> www_challenge("sip.pcr.ac.id", "0");
> break;
> };
>
> save("location");
> break;
>
> # -- aliases --
> lookup("aliases");
> if (!uri==myself)
> {
> append_hf("P-hint: outbound alias\r\n");
> route(1);
> break;
> };
> };
>
> # native SIP destinations are handled using our USRLOC DB
> if (!lookup("location")) {
> sl_send_reply("404", "Not Found");
> break;
> };
> };
> # forward to current uri now; use stateful forwarding; that
> # works reliably even if we forward from TCP to UDP
> if (!t_relay()) {
> sl_reply_error();
> };
>
>}
>route[1]
>{if (!t_relay())
> {
> sl_reply_error();
> };
>}
>
>
>Sita Rosita
>
>___________________________________________________
>Build your own website, it's easy and fun.
>
>http://www.homemaster.net - Homemaster. Come Together. Online.
>
Sita Rosita
___________________________________________________
Have your own email and web address for life.
http://www.homemaster.net - Homemaster. Come Together. Online.
Just noticed exec_dset only submits to: uri to the script you plan on
running, any quicks ways to pass the from: also? I was thinking a couple
ideas, one exec_msg, output to a file then right after exec_dset and
read the file, yada yada. or two, simply rewriting exec.c ...
Matt
Thanks Greger!
Yes, I'd love another set of eyes. Attached is my entire ser.cfg (bogus IPs of course).
Regards Paul.
--- "Greger V. Teigre" <greger(a)teigre.com> wrote:
> Paul,
> I'm not sure if this went on the list? I get digests...
>
> Thanks for your answer on content-length, I'll try it out. I went back to
> your original message on ACK and Route. I cannot understand how ser should
> process an ACK with STUN differently from without. If this assumption is
> correct, you would probably have a different execution path in your ser.cfg
> dependent on STUN or not. It could have something to do with what I wrote
> in my last email with regards to the error in Grandstream when behind
> symmetric NAT. I use nat_uac_test("19") to catch Grandstreams with firmware
> 10.0.5.16 as the contact and via will be public_ip:portfromstun while the
> request comes from public_ip:portfromsiprequest.
>
> I'm not confident I can help here as this is at the edge of my knowledge of
> the topic, but if you want an external look at your config, I'll be happy to
> have a look at it.
> g-)
>
>
> Java Rockx wrote:
> > I am using
> >
> > if(!(search("^Content-Length:\ 0")) {}
> >
> > in my ser.cfg and it seems to have eliminated all errors. Honestly, I
> > still have yet to test this with inbound calls from our PSTN
> > provider's Sonus equipment.
> >
> > My bigger issue is why would SER add "Route:" headers correctly to
> > ACK messages that flow from my SER proxy to their Sonus box only when
> > my IP phone is configured to use STUN?
> >
> > I am using nathelper and rtpproxy and everthing seems to work just
> > fine inside or outside of our firewall and no IP phones seem to need
> > STUN for SIP messages and RTP to play nice with our firewall or
> > client's firewalls as as far as I can tell my ser.cfg is good.
> >
> > So IMHO one of two things is happening;
> >
> > * I have an error that I'm not aware of in my ser.cfg related to
> > NATed versus non-NATed UACs * nathelper/rtpproxy is not usable when
> > SER is interacting with other SIP proxies and STUN must be used.
> >
> > Has anyone ever gotten SER to talk with other SIP proxies using NATed
> > clients?
> >
> > Regards,
> > Paul
> >
> > --- "Greger V. Teigre" <greger(a)teigre.com> wrote:
> >
> >> Hi,
> >> I've been following this thread as I have experienced the same
> >> problems myself. When I get incoming calls (both from Cisco IP-PSTN
> >> gateway and from other SIP phones) to a Grandstream behind symmetric
> >> NAT, the messages you have noted can be seen in the log when hanging
> >> up.
> >>
> >> I was not certain as to the conclusion you ended with. Do you use
> >> the filter:
> >> if (!(search("^Content-Length:\ 0")) {
> >> force_rtp_proxy();
> >> };
> >>
> >> to avoid the errors? I have been thinking about testing on method
> >> and not call force on BYE and ACK. Have you tried this?
> >>
> >> I also saw your question on RFC compliance and the Sonus equipment:
> >> In order to make Grandstream phones register properly when using
> >> STUN behind symmetric NAT, I had to patch nathelper with the rport
> >> != port of received address check. (I use 0.8.14 and I guess you
> >> already have the patch with the development version). The reason is
> >> that Grandstream attempts to rewrite the address using STUN even
> >> though it correctly detects a symmetric NAT. I have seen that this
> >> was introduced in a new firmware not long ago (release notes). This
> >> pussles me as sources I have seen claims this to be invalid behavior
> >> (which seems correct to me).
> >>
> >> Best regards,
> >> Greger
> >>
> >>
> >> Java Rockx wrote:
> >>> Hi All.
> >>>
> >>> I've hacked my ser.cfg but can someone comment on why I would be
> >>> recieving a "200 OK" with a
> >>>
> >>> The change I made to my onreply_route is below. The only thing I can
> >>> see about these messages versus others is that the CSeq says "CSeq:
> >>> {some digits} BYE" with "Content-Length: 0".
> >>>
> >>> So for these messages I'm just not calling force_rtp_proxy().
> >>>
> >>> I don't know if this is a symptom of my Grandstream BT100 only of if
> >>> other ATAs or IP phones do this.
> >>>
> >>> Regards,
> >>> Paul
> >>>
> >>> onreply_route[1] {
> >>>
> >>>
> >>> if (isflagset(2) && status =~ "(183)|2[0-9][0-9]") {
> >>>
> >>>
> >>> fix_nated_contact();
> >>>
> >>>
> >>> if (!(search("^Content-Length:\ 0")) {
> >>> force_rtp_proxy();
> >>> };
> >>>
> >>>
> >>> } else if (nat_uac_test("1")) {
> >>>
> >>>
> >>> fix_nated_contact();
> >>> };
> >>> }
> >>>
> >>>
> >>> --- Java Rockx <javarockx(a)yahoo.com> wrote:
> >>>
> >>>> Hi all.
> >>>>
> >>>> I've got nathelper and rtpproxy working very well with my firewall.
> >>>> However I do still recieve these messages in my syslog. I am only
> >>>> catching 183 and 2xx errors in my onreply_route so I'm very
> >>>> confused how to prevent these errors.
> >>>>
> >>>> I'm using ser-0.8.99-dev12. Can anyone give me some advise?
> >>>> Cheers,
> >>>> Paul
> >>>>
> >>>> NOTE: The SIP message that caused these errors is at the bottom of
> >>>> this message.
> >>>>
> >>>> 0(27011) ERROR: extract_body: message body has length zero
> >>>> 0(27011) ERROR: force_rtp_proxy2: can't extract body from the
> >>>> message 0(27011) ERROR: on_reply processing failed
> >>>>
> >>>> My onreply_route is here:
> >>>>
> >>>> onreply_route[1] {
> >>>>
> >>>>
> >>>>
> >>>> if (isflagset(2) && status =~ "(183)|2[0-9][0-9]") {
> >>>>
> >>>>
> >>>>
> >>>> fix_nated_contact();
> >>>>
> >>>>
> >>>>
> >>>> xlog("L_ERR", "%mb");
> >>>> force_rtp_proxy();
> >>>>
> >>>>
> >>>>
> >>>> } else if (nat_uac_test("1")) {
> >>>>
> >>>>
> >>>>
> >>>> fix_nated_contact();
> >>>> };
> >>>> }
> >>>>
> >>>>
> >>>>
> >>>> 0(27011) SIP/2.0 200 OK
> >>>> Via: SIP/2.0/UDP 67.184.42.101;branch=z9hG4bKe7ac.628388e2.0
> >>>> Via: SIP/2.0/UDP
> >>>> 192.168.0.83;rport=5060;received=68.184.42.171;branch=z9hG4bKb4bfc6084f306712
> >>>> From:
> >>>> <sip:9990010001@sip.mycompany.com;user=phone>;tag=0d5452e4bee210e3
> >>>> To: "Andrew"
> >>>> <sip:9990010002@sip.mycompany.com;user=phone>;tag=b73c75ac247b63db
> >>>> Call-ID: 0d5bc1fb337cd7eb(a)68.184.40.199 CSeq: 26976 BYE User-Agent:
> >>>> Grandstream BT100 1.0.5.11 Contact:
> >>>> <sip:9990010002@68.184.40.199;user=phone> Allow:
> >>>> INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
> >>>> Content-Length: 0
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> __________________________________
> >>>> Do you Yahoo!?
> >>>> The all-new My Yahoo! - Get yours free!
> >>>> http://my.yahoo.com
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Serusers mailing list
> >>>> serusers(a)lists.iptel.org
> >>>> http://lists.iptel.org/mailman/listinfo/serusers
> >>>>
> >>>
>
=== message truncated ===
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
What kind of UA are you using? Some ua's don't like qop from what I'm told.
-----Original Message-----
From: Nicolas Fauvel [mailto:n_fauvel@yahoo.fr]
Sent: Wednesday, November 24, 2004 11:28 AM
To: serusers(a)lists.iptel.org
Subject: [Serusers] Digest Authentification pb
Hi,
I have a problem with the digest authentification: here is my ser.cfg:
_________________________________________________
modparam("usrloc", "db_mode", 2)
modparam("auth", "password_column", "HA1")
modparam("auth", "password_column_2", "ha1b")
.....
if (method=="REGISTER") {
if (!www_authorize("192.168.3.1", "subscriber")) {
www_challenge("192.168.3.1", "1");
break;
};
save("location");
break;
};
..............
________________________________________________
Here are the server auth. request:
WWW-Authenticate: Digest realm="192.168.3.1", nonce="41a4bc4b000000005991791bfd119f83463ba82e93c3e1cc", qop="auth", algorithm=MD5
and the client reply:
Authorization: Digest username="nico",realm="192.168.3.1",
nonce="41a4bc4b000000005991791bfd119f83463ba82e93c3e1cc",
response="469f787618a743f08dd6e8768df3173f",uri="sip:192.168.3.1",
algorithm=MD5,qop=auth,cnonce="A8858AF297CE4CE5AC94ADE4467C8A9B",nc=00000134
______________________________________________________
Please !!! helpme, I've spent 2 days on it and... nothing !
Thanks
Vous manquez d'espace pour stocker vos mails ?
Yahoo! Mail vous offre GRATUITEMENT 100 Mo !
Créez votre Yahoo! Mail sur http://fr.benefits.yahoo.com/
Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis. A télécharger gratuitement sur http://fr.messenger.yahoo.com
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Hi All,
Is it possible to avoid duplicate phone registration
in SER.
I tried to use same number on 2 different phones and
pointed them to single SIP proxy (SER) both of them
seem to get registered.
Is there any way to stop this?
Waiting for your valuable inputs/suggestions.
Thanks & Regards,
Suvendu.
________________________________________________________________________
Yahoo! India Matrimony: Find your life partner online
Go to: http://yahoo.shaadi.com/india-matrimony
Hello.
Regarding this issue, i would like to add some comments. I was
trying to do some similar treatment for my registered endpoints, this is
limit the number of contacts that a user can have to one (i have the stable
0.8.14 from CVS). For this, y tried to use :
modparam("registrar","append_branches", 0)
modparam("registrar","desc_time_order", 1)
this cause me some problems in my locations table. The discuss is explained
with more detail in
http://lists.iptel.org/pipermail/serusers/2004-October/012553.html
The threading is a little bit in disorder, my apologize, but you can easily
follow the subject.
So, i was hopping that someone can confirm me the problem that i posted
there is a bug or is just a simple matter of misconfiguration.
Thanks in advance.
Best regards,
Ricardo.
-----Mensaje original-----
De: Daniel-Constantin Mierla
[mailto:Daniel-Constantin.Mierla@fokus.fraunhofer.de]
Enviado el: Miércoles, 24 de Noviembre de 2004 8:40
Para: Bruno Lopes F. Cabral
CC: serusers(a)lists.iptel.org
Asunto: Re: [Serusers] Duplicate phone registration
On 11/24/04 12:20, Bruno Lopes F. Cabral wrote:
> Hi
>
> thanks for the tip, but would all the registered
> contacts ring at same time when a call arrives?
> and SER would still be able to direct the call
> to who answer first? :~(
>
> it seems a good reason to jump pro 0.8.14 to
> -dev17. does anyone have an ETA on next SER stable
> release? ;-)
The proceedings already started:
http://lists.iptel.org/pipermail/serusers/2004-November/012820.html
Current phase is "cvs frozen":
http://lists.iptel.org/pipermail/serdev/2004-November/003324.html
We plan to have it before Christmas, but you never know ... :-) If
people from mailing list help with testing, give feedback, report bugs,
we will be in time and new stable ser will fly before next year.
Otherwise it will turn in a kind of testing release (debian approach).
Daniel
>
> Cheers
> !3runo
>
> Marian Dumitru wrote:
>
>> Hi Bruno,
>>
>> Not really. MAX_BRANCHES controls the maximum number of branches when
>> you fork a request. Be limiting this value, you can still register as
>> many contacts as you want, and lookup() will return only one contact.
>>
>> Best regards,
>> Marian
>>
>> Bruno Lopes F. Cabral wrote:
>>
>>> on SER 0.8.14, would config.h's MAX_BRANCHES do this trick?
>>>
>>> Marian Dumitru wrote:
>>>
>>>> If I'm not wrong, in the cvs head version you can limit the number
>>>> of contacts registered for an subscriber. See "max_contacts"
>>>> parameter in registrar module.
>>>
>
> _______________________________________________
> 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
I'm think that I'm wanting to go above and beyond aliases at this point,
could anyone suggest a way to have multiple URI's attached to one
username? ie: For the sake of having multiple phone lines. User aliases
can of course receive the URI but you're translating it back to the
original registered userid/uri .. Ideas?
I think asterisk spoiled me in this sense because on that
platform you can send any URI to users via digest.. :/ I know this
should be possible, just not sure how difficult it will be. Thanks
Matt
