Re: [OpenSIPS-Users] uac_replace_from not restoring displayname
Hi Bogdan, Hmm, that would be just as confusing i think, i might be able to pull it off by storing the original displayname in an AVP ? Regards, Erik Op 8-7-2010 9:55, Bogdan-Andrei Iancu schreef: Hi Erik, by design, the display name is not restored at all as it is not relevant from SIP point of view in the sequential requests. To avoid confusions, a simple hack I do in script, is, for sequential requests, to completely remove the display name part (also with uac_replace_from). Regards, Bogdan E. Versaevel wrote: Hi all, Is there a reason why uac_replace_from() is not restoring the displayname back to the sipclient? i'm doing a uac_replace_from() to mange the displayname/uri so my asterisk machine wil use the correct sip peer, however packages back to the sipclient only have their URI restored and keep the displayname set with the uac_replace_from() Is this expected behaviour? It's confusing for both me and the end users because you suddenly recieve packages with another displayname. Kind regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] uac_replace_from not restoring displayname
Hi bogdan, a config snippet would be appreciated, i am using the dialog module at the moment to limit concurrent calls Regards, Erik Op 8-7-2010 11:19, Bogdan-Andrei Iancu schreef: AVPs are not dialog persistent, but you can use dialog module with dialog persistent vars to store the displayname from the original INVITE and apply it in all sequential requests. If you are not familiar with how to use the dialog support, just let me know. Regards, Bogdan Erik Versaevel - InfoPact Netwerkdiensten wrote: Hi Bogdan, Hmm, that would be just as confusing i think, i might be able to pull it off by storing the original displayname in an AVP ? Regards, Erik Op 8-7-2010 9:55, Bogdan-Andrei Iancu schreef: Hi Erik, by design, the display name is not restored at all as it is not relevant from SIP point of view in the sequential requests. To avoid confusions, a simple hack I do in script, is, for sequential requests, to completely remove the display name part (also with uac_replace_from). Regards, Bogdan E. Versaevel wrote: Hi all, Is there a reason why uac_replace_from() is not restoring the displayname back to the sipclient? i'm doing a uac_replace_from() to mange the displayname/uri so my asterisk machine wil use the correct sip peer, however packages back to the sipclient only have their URI restored and keep the displayname set with the uac_replace_from() Is this expected behaviour? It's confusing for both me and the end users because you suddenly recieve packages with another displayname. Kind regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashes with db_virtual
Hi Bogdan, I'm currently not using db_virtual as i don't want the server to crash :) I do have the core file from the 2nd crash, but if i understand you we can't use that because of the destroy_modules() ? If opensips crashes on me again (without using db_virtual) i'll recomple it without the destroy_modules. Kind regards, Erik Versaevel Op 7-5-2010 18:10, Bogdan-Andrei Iancu schreef: Hi Erik, To avoid the core file to be overwritten, try to go in main.c file, function void cleanup(int show_status) (around line 329) and comment the destroy_modules(); line (336) . If you have the real backtrace, please post it here. Regards, bogdan Erik Versaevel wrote: Hi all, I've had some sort of migration yesterday but i ran into a couple of problems, first of which, opensips crashed at random, i've made the following backtraces (core file of the 1st has been overwritten by the 2nd so i won't be able to do anything with the 1st). Switching back to the regular mysql module instead of db_virtual seemed to solve the issue. I've had about 1800 accounts registrered on the server and calling around when it went down. (gdb) bt #0 0xb77b4430 in __kernel_vsyscall () #1 0xb7661651 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7664a82 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0xb769849d in ?? () from /lib/tls/i686/cmov/libc.so.6 #4 0xb76a2591 in ?? () from /lib/tls/i686/cmov/libc.so.6 #5 0xb76a5395 in ?? () from /lib/tls/i686/cmov/libc.so.6 #6 0xb76a6f9c in malloc () from /lib/tls/i686/cmov/libc.so.6 #7 0xb7696bf6 in open_memstream () from /lib/tls/i686/cmov/libc.so.6 #8 0xb77006f5 in __vsyslog_chk () from /lib/tls/i686/cmov/libc.so.6 #9 0xb7700c46 in __syslog_chk () from /lib/tls/i686/cmov/libc.so.6 #10 0xb760d93d in syslog (_h=0x81be420, _s=0x8189660) at /usr/include/bits/syslog.h:32 #11 db_mysql_submit_query (_h=0x81be420, _s=0x8189660) at dbase.c:136 #12 0x0811acfd in db_do_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21, val2str=0xb76108b5 db_mysql_val2str, submit_query=0xb760d60c db_mysql_submit_query) at db/db_query.c:177 #13 0xb760d4c5 in db_mysql_insert (_h=0x81be420, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:868 #14 0xb762b894 in db_virtual_insert (_h=0x81be3e0, _k=0xbf85fc98, _v=0xbf85faf4, _n=21) at dbase.c:482 #15 0xb7255036 in dialog_update_db (ticks=0, param=0x0) at dlg_db_handler.c:960 #16 0xb724c809 in mod_destroy () at dialog.c:694 #17 0x080bdce0 in destroy_modules () at sr_module.c:370 #18 0x0806ad7a in cleanup (show_status=1) at main.c:336 #19 0x0806b8c7 in handle_sigs () at main.c:533 #20 0x0806efb3 in main_loop (argc=5, argv=0xbf85ff24) at main.c:913 #21 main (argc=5, argv=0xbf85ff24) at main.c:1388 Core was generated by `/usr/local/opensips/sbin/opensips -m 2048 -P /var/run/opensips.pid'. Program terminated with signal 11, Segmentation fault. #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 587 d_entry = (d_table-entries[dlg-h_entry]); (gdb) bt #0 0xb726b522 in unref_dlg (dlg=0x373e6b38, cnt=1) at dlg_hash.c:587 #1 0xb725e724 in tmcb_unreference_dialog (t=0x373bed94, type=8192, param=0xb73642d4) at dlg_handlers.c:518 #2 0xb733dd32 in run_trans_callbacks (type=8192, trans=0x373bed94, req=0x0, rpl=0x0, code=0) at t_hooks.c:208 #3 0xb732c91b in free_cell (dead_cell=0x373bed94) at h_table.c:124 #4 0xb732c9c2 in free_hash_table () at h_table.c:342 #5 0xb7339797 in tm_shutdown () at t_funcs.c:99 #6 0x080bdce0 in destroy_modules () at sr_module.c:370 #7 0x0806ad7a in cleanup (show_status=1) at main.c:336 #8 0x0806b8c7 in handle_sigs () at main.c:533 #9 0x0806efb3 in main_loop (argc=5, argv=0xbfc71174) at main.c:913 #10 main (argc=5, argv=0xbfc71174) at main.c:1388 (gdb) Kind Regards, Erik ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users Erik Versaevel -- Core Network Engineer Infopact Network Solutions Hoogvlietsekerkweg 170 3194 AM Rotterdam Hoogvliet Telefoon+31 (0)88 - 4636777 Fax +31 (0)88 - 4636799 Mobile +31 (0)6 - 6070 e.versae...@infopact.nl www.infopact.nl ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Strange errors forwarding requests
That might be :)
I'm now running into problems with the dialog module (which i use to limit
concurrent calls).
Calls seem to stick in the dialog module (thus denying additional calls) while
the endpoint isn't
listing the same amount of calls :/
Regards,
Erik
Op 6-5-2010 11:02, Bogdan-Andrei Iancu schreef:
So, after all, it was a network layer configuration issue... :)
Regards,
Bogdan
Erik Versaevel wrote:
The destination (in this case) is the 1st server in the loadbalancer
list (as there are no other calls).
I've upgraded this machine to ubuntu 10 (from 8) and started getting
Connection Tracking drop messages in my
syslog. I've disabled connection tracking and the issue hasn't
appeared since...
Op 5-5-2010 12:24, Bogdan-Andrei Iancu schreef:
Hi Erik,
have you tried to print the destination of the requests that fail?
regards,
Bogdan
Erik Versaevel wrote:
Hi All,
I attempted an migration last night (from our current environment to
this new setup) but i ran into this
problem as soon as i tried to make some test calls, funny thing is i
can't get it reproduced :/ Any clues
on how to debug this any further?
Kind regards,
Erik
Op 27-4-2010 15:17, Erik Versaevel schreef:
Hi all,
I'm building a setup in which opensips is acting as registar for my
endpoints and loadbalancing
calls made by those endpoint over an cluster of asterisk machines.
(so that if we need more asterisk
power, we just have to add another destination to the loadbalancer
module)
Opensips is listening on multiple IP addresses and uses the
loadbalancer module to poll my asterisk
machines and select the destination.
My problem is that every now and then opensips fails to forward an
invite to my asterisk cluster and
generates
ERROR:core:udp_send:
sendto(sock,0x77b81280,1353,0,0x77b81b04,16): Operation not
permitted(1)
there is some iptables filtering on this machine, however it is not
showing drops in the logfile (and it keeps
occuring even without any iptable rules).
I tried stracing opensips but all i get is:
opensipstrace.7423:sendto(6, INVITE
sip:e164_dst_phone...@opensips_ip_address SIP/2.0
Record-Route:
sip:OPENSIPS_IP_ADDRESS;lr=on;ftag=AI05ED431A05432EB8;nat=yes;did=fd6.e1f16fe3;vsf=AAMIBgl3AggLFgF5HAAFGhwBHzE3NC44MQ--
Via: SIP/2.0/UDP OPENSIPS_IP_ADDRESS;branch=z9hG4bK3177.1e0e38b7.0
Via: SIP/2.0/UDP
192.168.178.44:5060;received=CPE_IP_ADDRESS;rport=61008;branch=z9hG4bK2010Apr222938466E164_DST_PHONE_NR
To: sip:e164_dst_phone...@opensips_ip_address
From: \3961\
sip:3...@opensips_ip_address;tag=AI05ED431A05432EB8
Call-ID: aif001c45e85f79...@192.168.178.44
CSeq: 2 INVITE
Max-Forwards: 69
Contact:
sip:e164phone...@cpe_ip_address:61008;line=AIF8F01E8DF866D7CB
Accept: application/sdp
Allow: ACK,BYE,CANCEL,INVITE,NOTIFY,OPTIONS,REFER
Allow-Events: dialog,message-summary
P-Preferred-Identity: sip:e164phone...@opensips_ip_address
Privacy: none
User-Agent: SomeStrangeDude
Content-Type: application/sdp
Content-Length: 324
I-FromDisp: null
I-FromUri: E164PHONE_NR
I-CustId: 3961
v=0
o=intelligate 1133701155 1133701155 IN IP4 192.168.178.44
s=call
c=IN IP4 CPE_IP_ADDRESS
t=0 0
m=audio 5004 RTP/AVP 18 8 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
a=direction:active
a=oldmediaip:192.168.178.44
, 1253, 0, {sa_family=AF_INET, sin_port=htons(5060),
sin_addr=inet_addr(ASTERISK_IP_ADDRESS)}, 16) = -1 EPERM
(Operation not permitted)
I also use the uac_replace_from() to mangle the from header so
asterisk uses the correct user/peer/client to connect the call
(codec/dialplan etc).
I'm having trouble reproducing the error as it's not allways
occuring, the errors i straced where mainly the initial invite
towards my asterisk
cluster and a few 200 OK's which didn't get processed correctly.
Any clues on how to debug this further?
Kind regards,
Erik Versaevel
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Erik Versaevel
Erik Versaevel
--
Core Network Engineer
Infopact Network Solutions
Hoogvlietsekerkweg 170
3194 AM Rotterdam Hoogvliet
Telefoon+31 (0)88 - 4636777
Fax +31 (0)88 - 4636799
Mobile +31 (0)6 - 6070
e.versae...@infopact.nl
www.infopact.nl
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
