Hi,
After compiling the pre-release 0.10 , I still have the serctl not ser_ctl. How do i fix it
Jean R. Sigue
Senior Network Engineer CCNP, CSS1, NSA
OMX Global Services USA
Direct: 1 908-673-6004
Mobile: (917-257-9742)
Fax: 1 908-673-6057
Visiting address: 2 Connell Drive
Berkeley Heights, NJ 07922
<http://www.omxgroup.com/>www.omxgroup.com
No. 1 in marketplace solutions
********************************************************************************
This e-mail and the information it contains may be privileged and/or
confidential. It is for the intended addressee(s) only.
The unauthorised use, disclosure or copying of this e-mail, or any information it contains, is prohibited.
If you are not an intended recipient, please contact the sender and delete the material from your computer.
********************************************************************************
Thank you for your help and sorry for my English.
I have a problem with mipv6 and a server SIP, SER (SIP Express Router).
The mipv6 path is "mipv6-2.0.2" from http://www.mobile-ipv6.org/ ,in kernel 2.6.16.24-Ubuntu.
The problem occurs when a packet is too big (it must be
fragmented), and go to the node what makes function of P-CSCF (Proxy in
SIP) and Correspondent Node.
If the P-CSCF is not a CN, all is OK. But if the node is CN, then i have the problem. The SER logs are:
##############################################################
................
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: SER: new INVITE Nov 20
18:28:25 pcscfD /usr/sbin/ser[8051]: parse_headers: flags=-1 Nov 20
18:28:25 pcscfD /usr/sbin/ser[8051]:
check_via_address(2001:720:1500:1B:FCFD:FF:FE0C:103,
[2001:720:1500:1B:FCFD:FF:FE0C:103], 3) Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8051]: ERROR: warning_builder: buffer size exceeded Nov
20 18:28:25 pcscfD /usr/sbin/ser[8051]: WARNING: warning skipped -- too
big Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: WARNING:vqm_resize:
resize(0) called Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG:
reply sent out.
buf=0x8106270: SIP/2.0 1..., shmem=0xb5e8b330: SIP/2.0 1 Nov 20
18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG: _reply_light: finished Nov
20 18:28:25 pcscfD /usr/sbin/ser[8051]: DEBUG: mk_proxy: doing DNS
lookup... Nov 20 18:28:25 pcscfD /usr/sbin/ser[8051]:
check_via_address(2001:720:1500:1B:FCFD:FF:FE0C:103,
[2001:720:1500:1B:FCFD:FF:FE0C:103], 3) Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8068]: DBG: tcp_main_loop: dead child 2 (shutting down?)
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: child process 8051 exited
by a signal 11 Nov 20 18:28:25 pcscfD kernel: [4296472.851000]
<0>skb_under_panic: text:c02d2aad len:321 put:14 head:d62cfc00 data:d62cfbea tail:d62cfd2b end:d62cfd80 dev:eth0
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: core was not generated
Nov 20 18:28:25 pcscfD kernel: [4297162.639000] ------------[ cut here ]------------
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: INFO: terminating due to SIGCHLD
Nov 20 18:28:25
pcscfD kernel: [4297162.639000] kernel BUG at net/core/skbuff.c:112!
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8059]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8052]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8053]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8054]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8055]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8056]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8057]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8058]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8060]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8061]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8062]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8063]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8064]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8065]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8066]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8067]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8068]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8050]: INFO: signal 15 received
Nov 20 18:28:25 pcscfD kernel: [4297162.639000] invalid opcode: 0000 [#3]
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8059]: Memory status (pkg):
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8052]: Memory status (pkg):
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8053]: Memory status (pkg):
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8054]: Memory status (pkg):
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8055]: Memory status (pkg):
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8056]: Memory status (pkg):
.......................
Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]: hash =
2055 fragments no.: 1, unused: 0 ^I^I bucket size:
1048576 - 2097152 (first 1572864) Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8049]: hash = 2059 fragments no.: 1, unused: 0
^I^I bucket size: 16777216 - 33554432 (first 31934160) Nov 20
18:28:25 pcscfD /usr/sbin/ser[8049]: TOTAL: 26 free fragments =
33537656 free bytes Nov 20 18:28:25 pcscfD /usr/sbin/ser[8049]:
----------------------------- Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8049]: shm_mem_destroy Nov 20 18:28:25 pcscfD
/usr/sbin/ser[8049]: destroying the shared memory lock Nov 20 18:28:25
pcscfD /usr/sbin/ser[8049]: terminating due to SIGCHLD
##############################################################
The problem is in the MTU size, because if the packet is not fragmented, there is not a problem. But the INVITE packet
needs to fragment, what it means, i always have the same problem.
My SER version is version: ser 0.9.6 (i386/linux) and it's a vanilla version. The packets is sent over UDP.
My questions are:
- Have anybody the same o similar problem?
- The MTU size is a problem in SER?
- Have anybody sent fragmented packets with SER?
Thanks for your help.
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.es
Hi,
I've been through the OpenSER + RADIUS configuration tutorial many,
many times, and it works like a charm, except for the uri_radius
module which I can't get to detect user existence with the
radius_does_user_exist() function.
I'm trying to decide whether to send a 404 or a 480, as such:
if (!lookup("location")) {
if(radius_does_uri_exist()) {
sl_send_reply("480", "User offline");
} else {
sl_send_reply("404", "User not found");
};
};
It worked identically with the uri_db module's does_user_exist()
function. Now the RADIUS server doesn't seem to understand the
Call-Check request. I have a dump here:
http://tonih.iki.fi/temp/uri_radius.cap
Can anyone guess why OpenSER always gives a 404 even for users that
exist, but that are simply offline? The users are currently
hand-configured into freeradius's text configuration file users.conf.
PS. What have you found to be the best way to authenticate users from
a domain? FreeRADIUS using Kerberos 5, LDAP or relaying to a
Microsoft RADIUS (IAS) server?
--
http://tonih.iki.fi/ ~ http://blogit.helsinki.fi/toni.heinonen/
"The progress of a dynamic civilization depends on the special people
who make play out of work. In their all-absorbing passion, they create
the variations that, through trial and error, become the sources of
progress. They make the discoveries that drive the infinite series."
- Virginia Postrel
i am developping one sip dialer using Microsoft RTC in vb6 i want to register in my opnser server put no request of registration are send to my server any help
__________________________________________________
Do You Yahoo!?
En finir avec le spam? Yahoo! Mail vous offre la meilleure protection possible contre les messages non sollicités
http://mail.yahoo.fr Yahoo! Mail
Hello,
today was introduced in development version a framework for automatic
error handling. Based on past experiences and comments on the mailing
lists, error handling was a bit deficient from the configuration file.
Log files could get full of error messages when SIP messages were
incorrect, the processing continued even it should have stopped.
With the new framework, the administrator can write a error_route block
and there decide what to do when an error is encountered. Right now,
error_route is executed for parsing errors in sip requests - one can
send back now the appropriate reply. I use this email to start a
discussion about how to extend it, there could be system errors (e.g.,
memory, database access, ...) or errors in replies (here we can use same
route block and check the type of sip message not to force reply to
reply - a new more flexible and easier way to access pseudo-variables is
underway).
In the error_route are available 4 new pseudo-variables:
- $err.class - the class of error (now is ‘1’ for parsing errors)
- $err.level - severity level for the error
- $err.info - text describing the error
- $err.rcode - recommended reply code
- $err.rreason - recommended reply reason phrase
With the new sl_reply() from sl module you can reply with the
appropriate code and reason from error_route[] - here is an example:
error_route {
xlog("--- error route class=$(err.class) level=$(err.level)
info=$(err.info) rcode=$(err.rcode) rreason=$(err.rreason) ---\n");
xlog("--- error from [$si:$sp]\n+++++\n$mb\n++++\n");
sl_reply("$err.rcode", "$err.rreason");
exit;
}
In addition to sl_send_reply(), append_to_reply() and xlog functions can
be used in error_route. You have to use 'exit' if you do not want to
continue the execution when an error occurred. Error level is meant to
show if the processing can continue without any issue, or if the error
allows to send reply or not. Please note that malformed SIP messages can
still go through your proxy in the case the processing didn't discover
it (OpenSER has an incremental parser, it parses only what it needs).
If no error_route is defined, the functionality is same as before.
Looking forward to feedback about this new automatic error handling.
Cheers,
Daniel
Hi
After instaling serweb 0.10.0 for ser 0.10.99 when I try to log into user aplication I get the following error:
Fatal error: Allowed memory size of 8388608 bytes exhausted (tried to allocate 9699 bytes) in /home/ser/serweb/serweb-0.10.0/smarty/Smarty_Compiler.class.php on line 196
I configured serweb with the multidomain support according to README in modules/multidomain/.
What can I do with that? And what information do You need to investigate the probelem?
Bests
Tomasz
Rajesh Kalagarla wrote:
> Hi Klaus,
>
> As per rfc 3261, if the proxy is stateful the CANCEL request will be a
> hop-by-hop request. in that case Relay is not the correct option right?
It is the correct function to handle CANCEL.
t_relay will pass the CANCEL to openser's transaction modul. The
transaction module usualy will detect that this CANCEL is for an ongoing
transaction and takes care of the hop-by-hop CANCEL. This should also
take care of the hop-by-hop ACK to the 487 response.
regards
klaus
>
> Thanks & Regards,
> Rajesh
>
> ----- Original Message -----
> From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
> To: "Rajesh Kalagarla" <RajeshK(a)idnltd.com>
> Cc: <devel(a)openser.org>
> Sent: Tuesday, January 09, 2007 10:38 AM
> Subject: Re: [Devel] OpenSER not sending Ack on Request Cancel
>
>
>> Hi!
>>
>> This indeed looks strange. Are you using stateful forwarding (t_relay)?
>>
>> It loks like your are using lookup() also for CANCEL - try to avoid that
>> and just t_relay:
>>
>> if (is_method("CANCEL")) {
>> t_relay();
>> }
>>
>> regards
>> klaus
>>
>> Rajesh Kalagarla wrote:
>>> Hi Klaus,
>>>
>>> here is the log.
>>>
>>> Thanks & Regards,
>>> Rajesh
>>> ----- Original Message -----
>>> From: "Klaus Darilion" <klaus.mailinglists(a)pernau.at>
>>> To: "Rajesh Kalagarla" <RajeshK(a)idnltd.com>
>>> Cc: <devel(a)openser.org>
>>> Sent: Monday, January 08, 2007 1:00 PM
>>> Subject: Re: [Devel] OpenSER not sending Ack on Request Cancel
>>>
>>>
>>>> Rajesh Kalagarla wrote:
>>>>> Hello All,
>>>>>
>>>>> OpenSER is not responding with a Ack for the call that was terminated
>>> with CANCEL because of no response from remote user. because of this SIP
>>> client is keep retransmitting the 487 Response for the Invite request.
>>>>> is it a bug or something need to be enabled?
>>>> Please send a "ngrep -W byline port 5060" dump.
>>>>
>>>> regards
>>>> klaus
>>>>
>>>>
>>>>> Thanks,
>>>>> Rajesh
>>>>>
>>>>>
>>>>>
>>>>>
>>>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> Devel mailing list
>>>>> Devel(a)openser.org
>>>>> http://openser.org/cgi-bin/mailman/listinfo/devel
>>>> --
>>>> Klaus Darilion
>>>> nic.at
>>>>
>>>>
>>
>> --
>> Klaus Darilion
>> nic.at
>>
>>
>
>
--
Klaus Darilion
nic.at
Behind a PIX, it works
Behind a SonicWall without the SIP_aware option, it doesn't work
Behind a Watchguard, it doesn't work too (and there is no SIP_aware option)
In fact, I have a centrex IP and many clients in the country with, many different configurations and I have to be sure that all works. It's why I have no enable the SIP_aware option in the sonicwall.
Thanks for your help,
Thomas
-----Message d'origine-----
De : users-bounces(a)openser.org [mailto:users-bounces@openser.org] De la part de Thomas Deillon
Envoyé : mercredi, 3. janvier 2007 17:06
À : daniel(a)voice-system.ro
Cc : users(a)openser.org
Objet : RE: [Users] SER as proxy in front of Asterisk
Hi,
In fact, now, every phone does not response.
The options didn't go thought the FW, so, the phone cannot answer.
I don't understand why the traffic don't go thought it !!
I have test this configuration with two firewall: a sonicwall and a soho.
Cheers,
Thomas
-----Message d'origine-----
De : Daniel-Constantin Mierla [mailto:daniel@voice-system.ro]
Envoyé : mercredi, 3. janvier 2007 14:52
À : Thomas Deillon
Cc : users(a)openser.org
Objet : Re: [Users] SER as proxy in front of Asterisk
Hello,
what is the type of NAT/Firewall you have in front of Thomson? As I can
see from the diagram, the phone does not reply to OPTIONS request, and I
guess, the nat/firewall needs outward traffic to keep the pinhole open.
Check why thomson ignores the options requests.
Cheers,
Daniel
On 01/03/07 15:17, Thomas Deillon wrote:
>
> Hi,
>
> I have made more tries and now, all my phones don't work ...
>
> The firewall opens a connection to REGISTER phone but after a while
> the OPTION message from the Asterisk will be DROP by the FW ...
>
> You can find a diagram of the exchange here:
> http://deillon.eu/tmp/exchange_sip.png
>
> A list of all exchange: http://deillon.eu/tmp/ip_sip.txt
>
> And all sip message: http://deillon.eu/tmp/message.txt
>
> Thanks a lot for your help,
>
> Thomas
>
> ------------------------------------------------------------------------
>
> *De :* users-bounces(a)openser.org [mailto:users-bounces@openser.org]
> *De la part de* Thomas Deillon
> *Envoyé :* mardi, 2. janvier 2007 11:44
> *À :* users(a)openser.org
> *Objet :* [Users] SER as proxy in front of Asterisk
>
> Hi all,
>
> I wish you first a happy new year !!
> One again, I ask you some help. Thanks a lot for your patience and
> your answers that really helped me.
>
> So, I want to put a SER in front of one Asterisk for the moment (more
> after).
> All Servers have public IP address and so, I don't care about the
> RTP/SDP messages.
> All phones are behind NAT somewhere in Switerland :)
>
>
> I have the configuration below in openser:
>
>
> modparam("dispatcher", "list_file", "/etc/openser/dispatcher.list")
> #modparam("dispatcher", "force_dst", 1)
> modparam("dispatcher", "flags", 2)
>
> modparam("usrloc", "db_mode", 0)
> #modparam("rr", "enable_full_lr", 1)
>
> route{
>
>
> xlog("L_ALERT", "[$rm] from [$fu] to [$tu]\n");
>
> if (!mf_process_maxfwd_header("10")) {
> sl_send_reply("483","Too Many Hops");
> exit;
> };
>
> if (msg:len >= 2048 ) {
> sl_send_reply("513", "Message too big");
> exit;
> };
>
> # if (search("User-Agent:.*Thomson.*")) {
> # };
>
>
> if ((src_ip==212.xxx.xxx.152) || (src_ip==212.xxx.xxx.153)) {
> if(method=="OPTIONS") {
> };
> avp_pushto("$ru","$tu");
> forward();
>
> }else {
> fix_nated_contact();
> force_rport();
> if(method=="REGISTER"){
> ds_select_dst("4", "0");
> t_relay();
> }
> else {
> ds_select_dst("0", "4");
> forward();
> }
> }
> }
>
>
> And in my dispatcher.list I have:
>
> 0 sip:212.xxx.xxx.153:5060
> 4 sip:212.xxx.xxx.153:5060
>
>
>
> With this configuration, a snom phone, a X-lite phone and a Cisco
> phone seams to work ....
> But with the Thomson ST2030, it doesn't work.
> In fact, the Thomson REGISTER on asterisk, the Asterisk send a OPTION
> message to the FW IP adress and the right port where the thomson is
> and then, after a while, the FW close the connection. The thomson
> phone is so "UNREACHABLE" on asterisk status and nobody can call it.
> I'm not sure that my configuration is ok in ser but I think that is a
> problem with the Thomson2030. Do you had the same kind of problem or
> do you understand the problem here ?
>
>
> Thanks for your help,
>
> Thomas Deillon
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users(a)openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
>
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users
Hi list.
I try to use the module dispatcher like failover, when the call is established and after the proxy is down then resend the BYE message at the next proxy using ds_select_dst("2", "4") and forward the message, but I obtain the message 503 of the failure_route[2], Any idea??
Thanks in advance
In my route seccion I made the next:
if (loose_route()) {
if (search("Path")) {
route(1);
};
if (!add_path_received()) {
sl_send_reply("503", "Internal Path Error");
exit;
};
route(5);
};
route[5] {
t_on_failure("2");
t_relay();
exit;
}
failure_route[2] {
#500, 503, 504
if ( t_check_status("408") | t_check_status("500") | t_check_status("503") | t_check_status("504") ) {
if (ds_next_domain()) {
#if (ds_next_dst()) {
# On Failure: Choose next Proxy
t_on_failure("2");
# Relay to Proxy
t_relay();
} else {
t_reply("503", "Service not available");
return;
}
};
}
__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis!
Regístrate ya - http://correo.yahoo.com.mx/