Hi:
I want to insert a header field without the script. Instead I
insert it in the tm module's t_relay() function. Next is my code.
The first time I use the pkg_malloc(), but ser report that:
BUG: qm_*: prev. fragm. tail overwritten(c0c0c000, abcdefed)
so I changed the pkg_malloc to the shm_malloc();
this time the error happend again in the different place.
typedef int(*local_fp)(struct sip_msg *msg, str *txt, int flags);
str *str1;
char *tmp = "P-Security-Nobody: this is a test header for \r\n";
local_fp append_to_reply = NULL;
str1 = (str*)shm_malloc(sizeof(str));
if(str1)
{
str1->len = strlen(tmp);
str1->s = (char*)shm_malloc(str1->len);
strcpy(str1->s, tmp);
append_to_reply = (local_fp)find_export("append_hf", 1, 0);
if(append_to_reply){
DBG("DEBUG: SUNZJ find apppend_to_reply\n");
append_to_reply(p_msg, str1, NULL);
}
}
the next is gdb's output.
Program received signal SIGABRT, Aborted.
[Switching to Thread -1208486208 (LWP 6439)]
0x00ad77a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb)
(gdb) where
#0 0x00ad77a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00b1b955 in raise () from /lib/tls/libc.so.6
#2 0x00b1d319 in abort () from /lib/tls/libc.so.6
#3 0x0808cb9d in qm_debug_frag (qm=0xb5f7e000, f=0x6) at mem/q_malloc.c:156
#4 0x0808d1ab in qm_malloc (qm=0xb5f7e000, size=4107, file=0x13fb49
"h_table.c", func=0x13fb1e "build_cell", line=231)
at mem/q_malloc.c:379
#5 0x0011b654 in build_cell (p_msg=0x814bec0) at shm_mem.h:135
#6 0x0012c23e in t_newtran (p_msg=0x814bec0) at t_lookup.c:988
#7 0x00123f4e in t_relay_to (p_msg=0x814bec0, proxy=0x0, proto=0,
replicate=0) at t_funcs.c:241
#8 0x0012f450 in w_t_relay (p_msg=0x814bec0, _foo=0x0, _bar=0x0) at
tm.c:893
#9 0x0804fe41 in do_action (a=0x814a4ac, msg=0x814bec0) at action.c:611
#10 0x08050bad in run_actions (a=0x814a4ac, msg=0x814bec0) at action.c:719
#11 0x08074fe8 in eval_elem (e=0x814a4fc, msg=0x814bec0) at route.c:605
#12 0x08075482 in eval_expr (e=0x814a4fc, msg=0x814bec0) at route.c:654
#13 0x080754be in eval_expr (e=0x814a540, msg=0x814bec0) at route.c:670
#14 0x0804edd5 in do_action (a=0x814a684, msg=0x814bec0) at action.c:587
#15 0x08050bad in run_actions (a=0x814a684, msg=0x814bec0) at action.c:719
#16 0x0805019f in do_action (a=0x814a3ac, msg=0x814bec0) at action.c:376
#17 0x08050bad in run_actions (a=0x814a3ac, msg=0x814bec0) at action.c:719
#18 0x0806de90 in receive_msg (
buf=0x80db480 "INVITE sip:862222@sip.suntest.com SIP/2.0\r\nVia:
SIP/2.0/UDP 192.168.0.19:5500;branch=z9hG4bK958088909\r\nFrom:
<sip:861111@sip.suntest.com>;tag=1137899792;tag=1613933050\r\nTo:
<sip:862222@sip.suntest.com"..., len=1018,
rcv_info=0xbffe1590) at receive.c:162
#19 0x080858dc in udp_rcv_loop () at udp_server.c:458
#20 0x0805d77f in main_loop () at main.c:1032
#21 0x0805ece5 in main (argc=2, argv=0xbffe1754) at main.c:1569
Anyone who tell me what the problem is will be appreciated.
Thanks for your kind help
Best Regards.
Sun Zongjun
Hi Dana!
Also take a look at the following paramaters and fucntions from the
registrar module:
desc_time_order (integer)
append_branches (integer)
registered(domain)
regards,
Klaus
PS: Please always send emails to the mailing list
Dana Olson wrote:
> Thanks for your reply. I wasn't sure about the URI and the To/From
> thing. I looked at the packet and when you register, the username is
> in both To and From. I guess I mistook the URI for that or something.
> Thanks for your clarification on that.
>
> I'm trying to limit the number of people using each username to a
> single person at a time. I read the mailing list of people trying to
> do this before me, and everyone, including Jiri, didn't understand why
> someone would want this.
>
> Well, I have a bunch inbound agents logging into my SER proxy with
> softphones, receiving calls from an AudioCodes Mediant 2000 (T1 <->
> SIP) that is getting calls from an Avaya PBX. These inbound calls have
> to go to whoever is logged in as that agent name, and only to them. We
> can't have multiple people logged into the same name, because each
> name corresponds to a certain phone number on the Avaya PBX. I hope
> this makes sense. It's not really a normal SIP application in this
> sense, which is why I need to remove the ability of a normal SIP
> application.
>
> I'm using the latest stable release of SER, and can't be putting
> anything less into production. I know that the next release has the
> max_contacts option, but until it goes stable, I don't have a green
> light to use it.
>
> I'll look into the avpops module, as I haven't really heard of it until now.
>
> --
> Dana
>
>
>
> On Fri, 11 Mar 2005 09:00:36 +0100, Klaus Darilion
> <klaus.mailinglists(a)pernau.at> wrote:
>
>>Hi!
>>
>>Lookup takes the request URI und looks up the location table. In
>>REGISTER messages, the address-of-record is in the To: header.
>>Therefore, lookup() will fail always.
>>
>>Maybe you can overcome this by copying the To: URI into an AVP and then
>>copying this AVP into the request URI. (avpops module).
>>
>>Btw: Why do you need this feature?
>>
>>regards,
>>klaus
>>
>>Dana Olson wrote:
>>
>>>I want to look up the username in the location table during the
>>>method==register if block.
>>>
>>>The reason I wish to do this is to see if there is another location
>>>currently registered in the database for this particular username. How
>>>can I do this? Do I have to use exec_msg() or exec_dset(), or does
>>>lookup() work?
>>>
>>>I've tried lookup("location") but it failed to work, it seems.
>>>
>>>Can anyone help me out? Here is the block of code that I'm trying to use:
>>>
>>> if (method=="REGISTER") {
>>> if (!search("^Expires: 0")) {
>>> if (lookup("location")) {
>>> sl_send_reply("200","Another registration.");
>>> } else {
>>> sl_send_reply("200", "First registration.");
>>> }
>>> } else {
>>> sl_send_reply("200", "Unregistration.");
>>> }
>>> save_noreply("location");
>>> break;
>>> }
>>>
>>>Note that it is sending the proper replies for "First registrations"
>>>and "Unregistrations," but not for "Another registrations."
>>>
>>>Thanks in advance,
>>>
>>>Dana
>>>
>>>_______________________________________________
>>>Serusers mailing list
>>>serusers(a)lists.iptel.org
>>>http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>>
>>
>>
>
>
Hello,
I started SER performance test with sipp traffic generator on FreeBSD 5.3. After starting 300 calls per second I got the following error:
Mar 14 16:35:09 devel ser[1506]: msg_send: ERROR: udp_send failed
Mar 14 16:35:09 devel ser[1506]: ERROR: udp_send: sendto(sock,0x2a258ae0,568,0,0x286be26c,16): No buffer space available(55)
SER send "503" the service not available. I don't use mediaproxy/rtpproxy to exclude problems there.
Could someone help me with this?
Thank you,
Tina
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
I think I have my problem solved. I am using a Cisco CSS11800 to load
balance to two SER servers. This seems to cause issues with digest
authentication. Anyone have experience with load balancing SER and
using digest auth at the same time?
I have had SER working with radius authentication on a previous server
with no problems. Now that I am trying to build up a few more servers,
I can not get SER to talk to radiusclient. I can run radiusclient
successfully from the command line, but the last things I see when I
try to authenticate against SER is:
0(17829) qm_free(0x810aa80, 0x8167bc0), called from sterman.c:
radius_authorize_sterman(101)
0(17829) qm_free: freeing frag. 0x8167ba8 alloc'ed from sterman.c:
radius_authorize_sterman(87)
Any ideas? Im guessing it might be a library problem, but nothing is
standing out to me.
Ray,
I solved it but using B2BUA from vovida.org
I'm not doing accounting with ser itself.
Some say it introduces some delay in between the calls. At least, it do
works for me.
B2BUA does manage properly the ACCT-RADIUS messages.
Regards,
Lucas
> -----Mensaje original-----
> De: Raymond Chen [mailto:rchen@broadz.com]
> Enviado el: Lunes, 14 de Marzo de 2005 03:21 p.m.
> Para: 'Lucas Aimaretto'; 'Bruno Lopes F. Cabral'; serusers(a)lists.iptel.org
> Asunto: RE: [Serusers] SER+Radius Accounting Not Working
>
>
> Guys,
>
> I am having the same problem as you described. Did you get it solved?
>
> Ray
>
> -----Original Message-----
> From: serusers-bounces(a)lists.iptel.org
> [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Lucas Aimaretto
> Sent: Friday, December 31, 2004 6:00 AM
> To: 'Bruno Lopes F. Cabral'; serusers(a)lists.iptel.org
> Subject: RE: [Serusers] SER+Radius Accounting Not Working
>
> Bruno,
>
> Thanx for answering ...
>
> > can you please post me a
> > grep Bye /etc/radiusclient/dictionary
> > you're using? ...
>
> [root@radius root]# grep Bye /etc/radiusclient/dictionary
> VALUE Sip-Method Bye 4
> VALUE Sip-Response-Code Bye 4
> VALUE Sip-Method Bye 4
> VALUE Sip-Response-Code Bye 4
>
> > I managed to get double Starts and single
> > Stops, but not much more.
>
> That's what I want to get (at least) ... but it makes no
> sense to me. I receive 2 Starts (but the first corresponds to
> an INVITE message and the 2nd to a BYE message :-s ). And
> when any of the users hang up, I receive nothing.
>
> > Cheers
>
> Regards,
>
> Lucas
>
> > P.S. BTW, are you using 0.8.14 or other SER version?
>
> version: 0.8.14 (i386/linux)
> flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE,
> DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC,
> FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024,
> MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE
> 1024, BUF_SIZE 65535
> @(#) $Id: main.c,v 1.168.4.3 2004/06/28 15:41:21 andrei Exp $
> main.c compiled on 16:02:31 Nov 10 2004 with gcc 2.96
>
>
>
> > Lucas Aimaretto wrote:
> > > Hi list. I have this problem. There's something that's
> not working,
> > > because, when ever I set up a call, I receive both messages
> > INVITE and
> > > BYE instantly. I think the correct way would it be to send Start
> > > messages (Acct-Status-Type = Start) upon INVITEs and Stop
> messages
> > > (Acct-Status-Type = Stop) upon BYEs. But this is not
> > happening. Look
> > > ...
> > >
> > > radrecv: Accounting Request from host c0a801fd code=4, id=205,
> > > length=270
> > > Acct-Status-Type = Start
> > > Service-Type = Sip-Session
> > > Sip-Response-Code = 200
> > > Sip-Method = Invite
> > > User-Name = "1992001(a)192.168.1.253"
> > > Calling-Station-Id =
> "sip:1992001@192.168.1.253:5060;user=phone"
> > > Called-Station-Id =
> "sip:1992005@192.168.1.253:5060;user=phone"
> > > Sip-Translated-Request-URI = "sip:1992005@192.168.1.178:11005"
> > > Acct-Session-Id = "6dfb6640367b1ab7(a)192.168.1.113"
> > > Sip-To-Tag = "54061171"
> > > Sip-From-Tag = "39eeac148f846cb9"
> > > Sip-CSeq = "1544"
> > > NAS-IP-Address = 192.168.1.253
> > > NAS-Port-Id = 5060
> > > Acct-Delay-Time = 0
> > > Sending Accounting Ack of id 205 to c0a801fd (nas linux)
> > >
> > > radrecv: Accounting Request from host c0a801fd code=4, id=206,
> > > length=270
> > > Acct-Status-Type = Start
> > > Service-Type = Sip-Session
> > > Sip-Response-Code = 200
> > > Sip-Method = Bye
> > > User-Name = "1992001(a)192.168.1.253"
> > > Calling-Station-Id =
> "sip:1992001@192.168.1.253:5060;user=phone"
> > > Called-Station-Id =
> "sip:1992005@192.168.1.253:5060;user=phone"
> > > Sip-Translated-Request-URI = "sip:1992005@192.168.1.178:11005"
> > > Acct-Session-Id = "6dfb6640367b1ab7(a)192.168.1.113"
> > > Sip-To-Tag = "54061171"
> > > Sip-From-Tag = "39eeac148f846cb9"
> > > Sip-CSeq = "1544"
> > > NAS-IP-Address = 192.168.1.253
> > > NAS-Port-Id = 5060
> > > Acct-Delay-Time = 0
> > > Sending Accounting Ack of id 206 to c0a801fd (nas linux)
> > >
> > > Do you see? ...Both outputs show an Acct-Status-Type = Start, but
> > > first output refers to an INVITE and second output refers to BYE
> > > message. And the strange thing is that both messages arrive
> > instantly,
> > > as soon as the peer answers the phone. Why??? I don't
> think this is
> > > correct, isn't it?
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
> >
> > --
> > No virus found in this incoming message.
> > Checked by AVG Anti-Virus.
> > Version: 7.0.296 / Virus Database: 265.6.6 - Release Date:
> 28/12/2004
> >
> >
>
> --
> No virus found in this outgoing message.
> Checked by AVG Anti-Virus.
> Version: 7.0.296 / Virus Database: 265.6.6 - Release Date: 28/12/2004
>
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.308 / Virus Database: 266.7.1 - Release Date: 09/03/2005
>
>
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.1 - Release Date: 09/03/2005
Hi
I would like to know if its possible to comunicate SIP Clients betwen
them when they are behind the same nat, I am using
Nathelper/RTPProxy...
thanks
Rafael
--
rrgv
Hi list. I have this problem. There's something that's not working,
because, when ever I set up a call, I receive both messages INVITE and
BYE instantly. I think the correct way would it be to send Start
messages (Acct-Status-Type = Start) upon INVITEs and Stop messages
(Acct-Status-Type = Stop) upon BYEs. But this is not happening. Look ...
radrecv: Accounting Request from host c0a801fd code=4, id=205,
length=270
Acct-Status-Type = Start
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = Invite
User-Name = "1992001(a)192.168.1.253"
Calling-Station-Id = "sip:1992001@192.168.1.253:5060;user=phone"
Called-Station-Id = "sip:1992005@192.168.1.253:5060;user=phone"
Sip-Translated-Request-URI = "sip:1992005@192.168.1.178:11005"
Acct-Session-Id = "6dfb6640367b1ab7(a)192.168.1.113"
Sip-To-Tag = "54061171"
Sip-From-Tag = "39eeac148f846cb9"
Sip-CSeq = "1544"
NAS-IP-Address = 192.168.1.253
NAS-Port-Id = 5060
Acct-Delay-Time = 0
Sending Accounting Ack of id 205 to c0a801fd (nas linux)
radrecv: Accounting Request from host c0a801fd code=4, id=206,
length=270
Acct-Status-Type = Start
Service-Type = Sip-Session
Sip-Response-Code = 200
Sip-Method = Bye
User-Name = "1992001(a)192.168.1.253"
Calling-Station-Id = "sip:1992001@192.168.1.253:5060;user=phone"
Called-Station-Id = "sip:1992005@192.168.1.253:5060;user=phone"
Sip-Translated-Request-URI = "sip:1992005@192.168.1.178:11005"
Acct-Session-Id = "6dfb6640367b1ab7(a)192.168.1.113"
Sip-To-Tag = "54061171"
Sip-From-Tag = "39eeac148f846cb9"
Sip-CSeq = "1544"
NAS-IP-Address = 192.168.1.253
NAS-Port-Id = 5060
Acct-Delay-Time = 0
Sending Accounting Ack of id 206 to c0a801fd (nas linux)
Do you see ? ...Both outputs show an Acct-Status-Type = Start, but first
output refers to an INVITE and second output refers to BYE message. And
the strange thing is that both messages arrive instantly, as soon as the
peer answers the phone. Why ??? I don't think this is correct, isn't it
?
Any hint ?
here goes my ser.cfg ...
[...]
# -- RADIUS ACC --
modparam("acc", "radius_config", "/etc/radiusclient.conf")
modparam("acc", "radius_flag", 1) modparam("acc", "radius_missed_flag",
2) modparam("acc", "log_level", 1) modparam("acc", "service_type", 15)
[...]
if (loose_route())
{
t_relay();
break;
};
if (uri==myself)
{
if (method=="REGISTER")
{
# Lo siguiente es para auth con RADIUS
if (!radius_www_authorize(""))
{
www_challenge("", "0");
break;
};
save("location");
break;
};
if (method=="INVITE")
{
setflag(1);
};
# native SIP destinations are handled using our USRLOC
DB
if (!lookup("location"))
{
sl_send_reply("404", "Not Found");
break;
};
};
t_relay();
[...]
Regards,
Lucas
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.296 / Virus Database: 265.6.6 - Release Date: 28/12/2004
Hi all,
Just to confirm the cpl module should be compatible with stable ser
version 0.8.14,shouldnt it?? I have installed the cpl module
according to the following howto:
http://www.kom.tu-darmstadt.de/~jschmitt/HowToSER_CPL.htm
However when i try ot load the cpl-c module in ser.cfg,I get the
following error. Any ideas??:
ERROR: module version mismatch for /usr/lib/ser/modules/cpl-c.so;
core: 0.8.14; module: 0.8.14-5
Thanks,
Aisling.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.