Re: [OpenSIPS-Users] b2b_init_request('top hiding')
Hi Dani, As Ovidiu said - b2b doesn't work with nat_traversal. The main limitation comes from the fact that nat_traversal uses dialog module and b2b does not work with dialog module yet. The reason is that dialog module was designed to store proxied dialog, not the ones where opensips is an endpoint. Indeed there isn't a clear note in documentation about this limitation - I will add it now. Regards, -- Anca Vamanu OpenSIPS Developer On 04/20/2011 06:26 PM, Anca Vamanu wrote: Hi Dani, Seems similar to something that we also hit.. but still not the same. Can you please paste the output of 'bt'** http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/tm/uac.c?revision=7747view=markup in gdb? Regards, -- Anca Vamanu OpenSIPS Developer On 04/20/2011 03:11 PM, Dani Popa wrote: Hi, I have a problem using b2b_init_request with top hiding. When i receive 200 ok for invite, opensips crash with ERROR:nat_traversal:__dialog_confirmed: FAKED reply - exit. In core dump this is where opensips crash: #0 get_source_uri (dlg=0xb2b4bc84, type=8, _params=0xb70b3c20) at nat_traversal.c:968 968 snprintf(uri, 64, sip:%s:%d, ip_addr2a(msg-rcv.src_ip), msg-rcv.src_port); opensips info: version: opensips 1.6.4-2-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, 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 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 7530 2010-12-13 19:07:53Z bogdan_iancu $ main.c compiled on 06:23:09 Apr 20 2011 with gcc 4.5.2 Can someone give me a hint? Thanks, Dani ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] b2b_init_request('top hiding')
ok, Thanks, Dani On 04/21/11 11:10, Anca Vamanu wrote: Hi Dani, As Ovidiu said - b2b doesn't work with nat_traversal. The main limitation comes from the fact that nat_traversal uses dialog module and b2b does not work with dialog module yet. The reason is that dialog module was designed to store proxied dialog, not the ones where opensips is an endpoint. Indeed there isn't a clear note in documentation about this limitation - I will add it now. Regards, -- Anca Vamanu OpenSIPS Developer On 04/20/2011 06:26 PM, Anca Vamanu wrote: Hi Dani, Seems similar to something that we also hit.. but still not the same. Can you please paste the output of 'bt'** http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.6/modules/tm/uac.c?revision=7747view=markup in gdb? Regards, -- Anca Vamanu OpenSIPS Developer On 04/20/2011 03:11 PM, Dani Popa wrote: Hi, I have a problem using b2b_init_request with top hiding. When i receive 200 ok for invite, opensips crash with ERROR:nat_traversal:__dialog_confirmed: FAKED reply - exit. In core dump this is where opensips crash: #0 get_source_uri (dlg=0xb2b4bc84, type=8, _params=0xb70b3c20) at nat_traversal.c:968 968 snprintf(uri, 64, sip:%s:%d, ip_addr2a(msg-rcv.src_ip), msg-rcv.src_port); opensips info: version: opensips 1.6.4-2-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, 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 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: unknown @(#) $Id: main.c 7530 2010-12-13 19:07:53Z bogdan_iancu $ main.c compiled on 06:23:09 Apr 20 2011 with gcc 4.5.2 Can someone give me a hint? Thanks, Dani ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Future of 1.6 and 2.0
Il 19/04/11 23.30, Brett Nemeroff: Simon, I think it's about a 100% bet that the 1.6 and 2.0 configs will not be compatible due to some pretty significant architectural changes. However, I wouldn't expect that the coming 2.0 release is going to obsolete 1.6 configurations. I suspect that it will take a few iterations of 2.0 releases before it becomes a preferred standard. For now, I'd plan on 1.6 configs unless your deployment is many months out. That's just my $0.02 from the perspective of a consultant supporting these systems and not designing them. Hi Brett, I agree. But I think it is important to know these dates in order to understand how much time an infrastructure based on 1.6 could be supported (expecially bug fixes). I'm planning a new installation but I can postpone it. I think people from Voice-system (Bogdan) could clarify this topic. Best regards, Simon ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
Hi, Thanks for the report, I was able to reproduce this on a Squeeze system. We need to adapt to changes in latest libnetfilter-conntrack. Did you try to install the Debian package from our repository? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
Hi, yes, i was able to install it and run it, but i have some issues. I dont have stream statistics: caller_bytes,callee_bytes,caller_packets and callee_packets. Also, if i'm not sure if media timeout is working, because i tried to simulate a hang call (in the middle of call, i restart my hardphone) and call was not terminated with timeout after stream_timeout seconds. Indeed, i saw rtp packets in one way. Dani On 04/21/11 13:37, Saúl Ibarra Corretgé wrote: Hi, Thanks for the report, I was able to reproduce this on a Squeeze system. We need to adapt to changes in latest libnetfilter-conntrack. Did you try to install the Debian package from our repository? Regards, ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
On 04/21/2011 12:44 PM, Dani Popa wrote: Hi, yes, i was able to install it and run it, but i have some issues. I dont have stream statistics: caller_bytes,callee_bytes,caller_packets and callee_packets. Also, if i'm not sure if media timeout is working, because i tried to simulate a hang call (in the middle of call, i restart my hardphone) and call was not terminated with timeout after stream_timeout seconds. Indeed, i saw rtp packets in one way. MediaProxy will not terminate the session is there are RTP packets flowing in at least one direction. Stream timeout only kicks in if RTP stops from both sides. About the statistics, can you paste what you get on syslog after a successful call with RTP? Regards, -- Saúl Ibarra Corretgé AG Projects ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
sure, Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50014 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50015 Apr 21 06:06:50 test media-relay[4903]: (Port 50012 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50013 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50014 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50015 Closed) s Also, i'm not very sure when(i'll make more tests and i'll come with updates) and what conditions i get next kernel errors: Apr 19 05:53:36 test kernel: [ 209.838816] ctnetlink v0.93: registering with nfnetlink. Apr 19 05:53:36 test kernel: [ 209.838957] [ cut here ] Apr 19 05:53:36 test kernel: [ 209.838971] WARNING: at /build/buildd-linux-2.6_2.6.37-1-i386-vxjyZA/linux-2.6-2.6.37/debian/build/source_i38 6_none/mm/page_alloc.c:1990 __alloc_pages_nodemask+0x17c/0x5ff() Apr 19 05:53:36 test kernel: [ 209.838978] Hardware name: PowerEdge R310 Apr 19 05:53:36 test kernel: [ 209.838980] Modules linked in: nf_conntrack_netlink xt_NOTRACK xt_tcpudp iptable_raw nfnetlink iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables loop snd_pcm snd_timer snd soundcore snd_page_alloc evdev button tpm_tis tpm processor pcspkr dcdbas ghes thermal_sys hed tpm_bios power_meter ext3 jbd mbcache sd_mod crc_t10dif sg sr_mod cdrom ata_generic ata_piix libata mptsas mptscsih mptbase ehci_hcd scsi_transport_sas usbcore scsi_mod bnx2 nls_base [last unloaded: scsi_wait_scan] Apr 19 05:53:36 test kernel: [ 209.839030] Pid: 2521, comm: media-relay Not tainted 2.6.37-1-686-bigmem #1 Apr 19 05:53:36 test kernel: [ 209.839033] Call Trace: Apr 19 05:53:36 test kernel: [ 209.839041] [c1036005] ? warn_slowpath_common+0x6a/0x7b Apr 19 05:53:36 test kernel: [ 209.839047] [c10986c8] ? __alloc_pages_nodemask+0x17c/0x5ff Apr 19 05:53:36 test kernel: [ 209.839052] [c1036023] ? warn_slowpath_null+0xd/0x10 Apr 19 05:53:36 test kernel: [ 209.839058] [c10986c8] ? __alloc_pages_nodemask+0x17c/0x5ff Apr 19 05:53:36 test kernel: [ 209.839068] [c102cd47] ? select_task_rq_fair+0x326/0x604 Apr 19 05:53:36 test kernel: [ 209.839071] [c1098b57] ? __get_free_pages+0xc/0x17 Apr 19 05:53:36 test kernel: [ 209.839074] [c10be2c7] ? __kmalloc_track_caller+0x32/0x127 Apr 19 05:53:36 test kernel: [ 209.839077] [f8d6c4da] ? nlmsg_new+0xf/0x11 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839080] [c11fbb07] ? __alloc_skb+0x4c/0xda Apr 19 05:53:36 test kernel: [ 209.839082] [f8d6c4da] ? nlmsg_new+0xf/0x11 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839085] [f8d6e228] ? ctnetlink_conntrack_event+0x11e/0x3f2 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839087] [f8d6c303] ? nf_conntrack_eventmask_report+0x98/0xfb [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839090] [f8d6c468] ? ctnetlink_del_conntrack+0xee/0x142 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839094] [f8d36222] ? nfnetlink_rcv_msg+0x12b/0x15c [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839097] [f8d360f7] ? nfnetlink_rcv_msg+0x0/0x15c [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839102] [c121bd58] ? netlink_rcv_skb+0x2d/0x72 Apr 19 05:53:36 test kernel: [ 209.839105] [f8d360f1] ? nfnetlink_rcv+0x18/0x1e [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839107] [c121bbac] ? netlink_unicast+0xba/0x10e Apr 19 05:53:36 test kernel: [ 209.839109] [c121c6b0] ? netlink_sendmsg+0x23d/0x256 Apr 19 05:53:36 test kernel: [ 209.839112] [c11f5326] ? __sock_sendmsg+0x48/0x4e Apr 19 05:53:36 test kernel: [ 209.839114] [c11f558f] ? sock_sendmsg+0x78/0x8f Apr 19 05:53:36 test kernel: [ 209.839117] [c11c3cc4] ? extract_entropy+0x62/0x101 Apr 19 05:53:36 test kernel: [ 209.839119] [c10bc6d0] ? add_partial+0xe/0x40 Apr 19 05:53:36 test kernel: [ 209.839122] [c1093b34] ? find_get_page+0x19/0x5e Apr 19 05:53:36 test kernel: [ 209.839124] [c10952e4] ? filemap_fault+0x196/0x33f Apr 19 05:53:36 test kernel: [ 209.839127] [c1027195] ? __kunmap_atomic+0x61/0x79 Apr 19 05:53:36 test kernel: [ 209.839129] [c114fc19] ? _copy_from_user+0x2b/0x10e Apr 19 05:53:36 test kernel: [ 209.839131] [c11f6015] ? sys_sendto+0xed/0x121 Apr 19 05:53:36 test kernel: [ 209.839134] [c10c3e13] ? alloc_file+0xf/0x89 Apr 19 05:53:36 test kernel: [ 209.839138] [c12a0793] ? do_page_fault+0x353/0x36f Apr 19 05:53:36 test kernel: [ 209.839140] [c12a0780] ? do_page_fault+0x340/0x36f Apr 19 05:53:36 test kernel: [ 209.839142] [c11f6f88] ? sys_socketcall+0x10a/0x1cb Apr 19 05:53:36 test kernel: [ 209.839145] [c1008b1f] ? sysenter_do_call+0x12/0x28 Apr 19 05:53:36
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
On 04/21/2011 01:06 PM, Dani Popa wrote: sure, Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50014 Apr 21 06:06:41 test media-relay[4903]: mediaproxy.mediacontrol.StreamListenerProtocol starting on 50015 Apr 21 06:06:50 test media-relay[4903]: (Port 50012 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50013 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50014 Closed) Apr 21 06:06:50 test media-relay[4903]: (Port 50015 Closed) Don't you get teh statistics printed here? s Also, i'm not very sure when(i'll make more tests and i'll come with updates) and what conditions i get next kernel errors: Apr 19 05:53:36 test kernel: [ 209.838816] ctnetlink v0.93: registering with nfnetlink. Apr 19 05:53:36 test kernel: [ 209.838957] [ cut here ] Apr 19 05:53:36 test kernel: [ 209.838971] WARNING: at /build/buildd-linux-2.6_2.6.37-1-i386-vxjyZA/linux-2.6-2.6.37/debian/build/source_i38 6_none/mm/page_alloc.c:1990 __alloc_pages_nodemask+0x17c/0x5ff() Apr 19 05:53:36 test kernel: [ 209.838978] Hardware name: PowerEdge R310 Apr 19 05:53:36 test kernel: [ 209.838980] Modules linked in: nf_conntrack_netlink xt_NOTRACK xt_tcpudp iptable_raw nfnetlink iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4 ip_tables x_tables loop snd_pcm snd_timer snd soundcore snd_page_alloc evdev button tpm_tis tpm processor pcspkr dcdbas ghes thermal_sys hed tpm_bios power_meter ext3 jbd mbcache sd_mod crc_t10dif sg sr_mod cdrom ata_generic ata_piix libata mptsas mptscsih mptbase ehci_hcd scsi_transport_sas usbcore scsi_mod bnx2 nls_base [last unloaded: scsi_wait_scan] Apr 19 05:53:36 test kernel: [ 209.839030] Pid: 2521, comm: media-relay Not tainted 2.6.37-1-686-bigmem #1 Apr 19 05:53:36 test kernel: [ 209.839033] Call Trace: Apr 19 05:53:36 test kernel: [ 209.839041] [c1036005] ? warn_slowpath_common+0x6a/0x7b Apr 19 05:53:36 test kernel: [ 209.839047] [c10986c8] ? __alloc_pages_nodemask+0x17c/0x5ff Apr 19 05:53:36 test kernel: [ 209.839052] [c1036023] ? warn_slowpath_null+0xd/0x10 Apr 19 05:53:36 test kernel: [ 209.839058] [c10986c8] ? __alloc_pages_nodemask+0x17c/0x5ff Apr 19 05:53:36 test kernel: [ 209.839068] [c102cd47] ? select_task_rq_fair+0x326/0x604 Apr 19 05:53:36 test kernel: [ 209.839071] [c1098b57] ? __get_free_pages+0xc/0x17 Apr 19 05:53:36 test kernel: [ 209.839074] [c10be2c7] ? __kmalloc_track_caller+0x32/0x127 Apr 19 05:53:36 test kernel: [ 209.839077] [f8d6c4da] ? nlmsg_new+0xf/0x11 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839080] [c11fbb07] ? __alloc_skb+0x4c/0xda Apr 19 05:53:36 test kernel: [ 209.839082] [f8d6c4da] ? nlmsg_new+0xf/0x11 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839085] [f8d6e228] ? ctnetlink_conntrack_event+0x11e/0x3f2 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839087] [f8d6c303] ? nf_conntrack_eventmask_report+0x98/0xfb [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839090] [f8d6c468] ? ctnetlink_del_conntrack+0xee/0x142 [nf_conntrack_netlink] Apr 19 05:53:36 test kernel: [ 209.839094] [f8d36222] ? nfnetlink_rcv_msg+0x12b/0x15c [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839097] [f8d360f7] ? nfnetlink_rcv_msg+0x0/0x15c [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839102] [c121bd58] ? netlink_rcv_skb+0x2d/0x72 Apr 19 05:53:36 test kernel: [ 209.839105] [f8d360f1] ? nfnetlink_rcv+0x18/0x1e [nfnetlink] Apr 19 05:53:36 test kernel: [ 209.839107] [c121bbac] ? netlink_unicast+0xba/0x10e Apr 19 05:53:36 test kernel: [ 209.839109] [c121c6b0] ? netlink_sendmsg+0x23d/0x256 Apr 19 05:53:36 test kernel: [ 209.839112] [c11f5326] ? __sock_sendmsg+0x48/0x4e Apr 19 05:53:36 test kernel: [ 209.839114] [c11f558f] ? sock_sendmsg+0x78/0x8f Apr 19 05:53:36 test kernel: [ 209.839117] [c11c3cc4] ? extract_entropy+0x62/0x101 Apr 19 05:53:36 test kernel: [ 209.839119] [c10bc6d0] ? add_partial+0xe/0x40 Apr 19 05:53:36 test kernel: [ 209.839122] [c1093b34] ? find_get_page+0x19/0x5e Apr 19 05:53:36 test kernel: [ 209.839124] [c10952e4] ? filemap_fault+0x196/0x33f Apr 19 05:53:36 test kernel: [ 209.839127] [c1027195] ? __kunmap_atomic+0x61/0x79 Apr 19 05:53:36 test kernel: [ 209.839129] [c114fc19] ? _copy_from_user+0x2b/0x10e Apr 19 05:53:36 test kernel: [ 209.839131] [c11f6015] ? sys_sendto+0xed/0x121 Apr 19 05:53:36 test kernel: [ 209.839134] [c10c3e13] ? alloc_file+0xf/0x89 Apr 19 05:53:36 test kernel: [ 209.839138] [c12a0793] ? do_page_fault+0x353/0x36f Apr 19 05:53:36 test kernel: [ 209.839140] [c12a0780] ? do_page_fault+0x340/0x36f Apr 19 05:53:36 test kernel: [ 209.839142] [c11f6f88] ? sys_socketcall+0x10a/0x1cb Apr 19 05:53:36 test kernel: [ 209.839145] [c1008b1f] ? sysenter_do_call+0x12/0x28 Apr 19 05:53:36 test kernel: [ 209.839147] ---[ end
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
On 04/21/11 14:13, Saúl Ibarra Corretgé wrote:
On 04/21/2011 01:06 PM, Dani Popa wrote:
sure,
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50012
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50013
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50014
Apr 21 06:06:41 test media-relay[4903]:
mediaproxy.mediacontrol.StreamListenerProtocol starting on 50015
Apr 21 06:06:50 test media-relay[4903]: (Port 50012 Closed)
Apr 21 06:06:50 test media-relay[4903]: (Port 50013 Closed)
Apr 21 06:06:50 test media-relay[4903]: (Port 50014 Closed)
Apr 21 06:06:50 test media-relay[4903]: (Port 50015 Closed)
Don't you get teh statistics printed here?
I'm not talking abut binding ports for streams, i'm talking about stream
packets and bytes info on telnet localhost 25060.
[{from_tag: 4fc7812b, start_time: 1303386789.09, call_id:
f233072fb063d5c554bebffe80248eba@0:0:0:0:0:0:0:0, duration: 24,
streams: [{status: active, caller_codec: G711u,
post_dial_delay: 3.49981117249, callee_codec: G711u,
caller_bytes: 0, start_time: 0, callee_packets: 0, callee_bytes:
0, caller_packets: 0, callee_remote: X.X.X.X:8752, end_time: 24,
caller_remote: X.X.X.X:5014, media_type: audio, callee_local:
X.X.X.X:50006, timeout_wait: 0, caller_local: X.X.X.X:50004}],
to_tag: a94c095b773be1dd6e8d668a785a9c848e314110, to_uri:
123456...@gigi.ro, caller_ua:
Jitsi1.0-beta1-nightly.build.3408Linux, callee_ua: Cantata,
from_uri: dani.p...@gigi.ro}]
And also, when mediaproxy send radius acounting request, it send with :
caller_bytes: 0, callee_packets: 0, callee_bytes: 0,
caller_packets: 0
s
Also, i'm not very sure when(i'll make more tests and i'll come with
updates) and what conditions i get next kernel errors:
Apr 19 05:53:36 test kernel: [ 209.838816] ctnetlink v0.93: registering
with nfnetlink.
Apr 19 05:53:36 test kernel: [ 209.838957] [ cut here
]
Apr 19 05:53:36 test kernel: [ 209.838971] WARNING: at
/build/buildd-linux-2.6_2.6.37-1-i386-vxjyZA/linux-2.6-2.6.37/debian/build/source_i38
6_none/mm/page_alloc.c:1990 __alloc_pages_nodemask+0x17c/0x5ff()
Apr 19 05:53:36 test kernel: [ 209.838978] Hardware name: PowerEdge R310
Apr 19 05:53:36 test kernel: [ 209.838980] Modules linked in:
nf_conntrack_netlink xt_NOTRACK xt_tcpudp iptable_raw nfnetlink
iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack nf_defrag_ipv4
ip_tables x_tables loop snd_pcm snd_timer snd soundcore snd_page_alloc
evdev button tpm_tis tpm processor pcspkr dcdbas ghes thermal_sys hed
tpm_bios power_meter ext3 jbd mbcache sd_mod crc_t10dif sg sr_mod cdrom
ata_generic ata_piix libata mptsas mptscsih mptbase ehci_hcd
scsi_transport_sas usbcore scsi_mod bnx2 nls_base [last unloaded:
scsi_wait_scan]
Apr 19 05:53:36 test kernel: [ 209.839030] Pid: 2521, comm: media-relay
Not tainted 2.6.37-1-686-bigmem #1
Apr 19 05:53:36 test kernel: [ 209.839033] Call Trace:
Apr 19 05:53:36 test kernel: [ 209.839041] [c1036005] ?
warn_slowpath_common+0x6a/0x7b
Apr 19 05:53:36 test kernel: [ 209.839047] [c10986c8] ?
__alloc_pages_nodemask+0x17c/0x5ff
Apr 19 05:53:36 test kernel: [ 209.839052] [c1036023] ?
warn_slowpath_null+0xd/0x10
Apr 19 05:53:36 test kernel: [ 209.839058] [c10986c8] ?
__alloc_pages_nodemask+0x17c/0x5ff
Apr 19 05:53:36 test kernel: [ 209.839068] [c102cd47] ?
select_task_rq_fair+0x326/0x604
Apr 19 05:53:36 test kernel: [ 209.839071] [c1098b57] ?
__get_free_pages+0xc/0x17
Apr 19 05:53:36 test kernel: [ 209.839074] [c10be2c7] ?
__kmalloc_track_caller+0x32/0x127
Apr 19 05:53:36 test kernel: [ 209.839077] [f8d6c4da] ?
nlmsg_new+0xf/0x11 [nf_conntrack_netlink]
Apr 19 05:53:36 test kernel: [ 209.839080] [c11fbb07] ?
__alloc_skb+0x4c/0xda
Apr 19 05:53:36 test kernel: [ 209.839082] [f8d6c4da] ?
nlmsg_new+0xf/0x11 [nf_conntrack_netlink]
Apr 19 05:53:36 test kernel: [ 209.839085] [f8d6e228] ?
ctnetlink_conntrack_event+0x11e/0x3f2 [nf_conntrack_netlink]
Apr 19 05:53:36 test kernel: [ 209.839087] [f8d6c303] ?
nf_conntrack_eventmask_report+0x98/0xfb [nf_conntrack_netlink]
Apr 19 05:53:36 test kernel: [ 209.839090] [f8d6c468] ?
ctnetlink_del_conntrack+0xee/0x142 [nf_conntrack_netlink]
Apr 19 05:53:36 test kernel: [ 209.839094] [f8d36222] ?
nfnetlink_rcv_msg+0x12b/0x15c [nfnetlink]
Apr 19 05:53:36 test kernel: [ 209.839097] [f8d360f7] ?
nfnetlink_rcv_msg+0x0/0x15c [nfnetlink]
Apr 19 05:53:36 test kernel: [ 209.839102] [c121bd58] ?
netlink_rcv_skb+0x2d/0x72
Apr 19 05:53:36 test kernel: [ 209.839105] [f8d360f1] ?
nfnetlink_rcv+0x18/0x1e [nfnetlink]
Apr 19 05:53:36 test kernel: [ 209.839107] [c121bbac] ?
netlink_unicast+0xba/0x10e
Apr 19 05:53:36 test kernel: [ 209.839109] [c121c6b0] ?
netlink_sendmsg+0x23d/0x256
Apr 19 05:53:36 test kernel: [ 209.839112] [c11f5326] ?
__sock_sendmsg+0x48/0x4e
Apr 19 05:53:36 test kernel: [ 209.839114] [c11f558f] ?
sock_sendmsg+0x78/0x8f
Apr 19 05:53:36 test kernel:
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
I'm not talking abut binding ports for streams, i'm talking about stream
packets and bytes info on telnet localhost 25060.
I meant the statisticas that get printed in syslog after the call is closed.
[{from_tag: 4fc7812b, start_time: 1303386789.09, call_id:
f233072fb063d5c554bebffe80248eba@0:0:0:0:0:0:0:0, duration: 24,
streams: [{status: active, caller_codec: G711u,
post_dial_delay: 3.49981117249, callee_codec: G711u,
caller_bytes: 0, start_time: 0, callee_packets: 0, callee_bytes:
0, caller_packets: 0, callee_remote: X.X.X.X:8752, end_time: 24,
caller_remote: X.X.X.X:5014, media_type: audio, callee_local:
X.X.X.X:50006, timeout_wait: 0, caller_local: X.X.X.X:50004}],
to_tag: a94c095b773be1dd6e8d668a785a9c848e314110, to_uri:
123456...@gigi.ro, caller_ua:
Jitsi1.0-beta1-nightly.build.3408Linux, callee_ua: Cantata,
from_uri: dani.p...@gigi.ro}]
And also, when mediaproxy send radius acounting request, it send with :
caller_bytes: 0, callee_packets: 0, callee_bytes: 0,
caller_packets: 0
This could be due to the bug with the netfilter integration which I need
to look into.
--
Saúl Ibarra Corretgé
AG Projects
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] mediaproxy build fail: libiptc.c:63:8: error: redefinition of â
OK,
Thanks,
Dani
On 04/21/11 15:14, Saúl Ibarra Corretgé wrote:
I'm not talking abut binding ports for streams, i'm talking about stream
packets and bytes info on telnet localhost 25060.
I meant the statisticas that get printed in syslog after the call is
closed.
[{from_tag: 4fc7812b, start_time: 1303386789.09, call_id:
f233072fb063d5c554bebffe80248eba@0:0:0:0:0:0:0:0, duration: 24,
streams: [{status: active, caller_codec: G711u,
post_dial_delay: 3.49981117249, callee_codec: G711u,
caller_bytes: 0, start_time: 0, callee_packets: 0, callee_bytes:
0, caller_packets: 0, callee_remote: X.X.X.X:8752, end_time: 24,
caller_remote: X.X.X.X:5014, media_type: audio, callee_local:
X.X.X.X:50006, timeout_wait: 0, caller_local: X.X.X.X:50004}],
to_tag: a94c095b773be1dd6e8d668a785a9c848e314110, to_uri:
123456...@gigi.ro, caller_ua:
Jitsi1.0-beta1-nightly.build.3408Linux, callee_ua: Cantata,
from_uri: dani.p...@gigi.ro}]
And also, when mediaproxy send radius acounting request, it send with :
caller_bytes: 0, callee_packets: 0, callee_bytes: 0,
caller_packets: 0
This could be due to the bug with the netfilter integration which I
need to look into.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips didn't take messages
Hi, A few things that you can check : 1. if BYE received on right interface and port 2. if opensips is blocked: - check in top the processor usage - check the received queue in netstat( Recv-Q) for OpenSIPS - to see if it has difficulties processing traffic - look in the logs for ERROR or CRITICAL messages Regards, -- Anca Vamanu OpenSIPS Developer On 04/20/2011 11:52 AM, Denis Putyato wrote: Hello! I found a big problem with Opensips in my installation. Once I started receive acc record in acc table which had a big duration (more than time conversation which is ). During analyzing these calls I found that Opensips didn`t take BYE which was send by another sip endpoints. I initiated debug 5 in log file and result of the debug you can see in debug.txt which I attached to the letter In debug from 08:08:39 and till 08:21:40 I have only one type of messages dealing with mi_fifo and nothing more. In the time range Opensips didn’t take any messages including BYE. After 08:41 everything seems began fine, because I see in log more information dialing with messages, parsing and so on. During problem: Opensips didn’t restart All processes running Opensips 1.6.4-2 Thank you for any help ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Opensips crashing due to out of memory error
Hi John,
yes.. it is something in libxml library ( this is what presence uses). I
will try to find it.
Thanks,
--
Anca Vamanu
OpenSIPS Developer
On 04/20/2011 06:51 PM, John Khvatov wrote:
Hi Anca,
On 20.04.2011, at 13:24, Anca Vamanu wrote:
Hi John,
Thanks for the logs.
Do you get the memory statistics from opensips statistics or from top?
In the logs I don't see a shared memory leak..
Hm... Maybe the memory leak in the system libraries?
Memory usage is calculated as follows:
# ps aux | head -n 1
USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND
# ps aux | grep -E /usr/sbin/opensips -[P]
opensips 8389 0.0 0.0 451444 9880 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8395 0.2 0.0 451448 5216 ?SApr19 2:06
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8396 0.0 0.0 451448 5184 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8398 0.0 0.0 451452 5160 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8399 0.0 0.1 451684 12732 ?SApr19 0:10
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8400 0.0 0.1 451704 12708 ?SApr19 0:09
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8402 0.0 0.1 451708 12644 ?SApr19 0:09
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8403 0.0 0.1 451708 12640 ?SApr19 0:10
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8405 0.0 0.0 451448 5088 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8406 0.0 0.0 451448 5088 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8409 0.0 0.0 451448 5088 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8410 0.0 0.0 451448 5088 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8411 0.0 0.0 450644 3148 ?SApr19 0:07
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8412 0.0 0.1 451448 11572 ?SApr19 0:11
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8413 0.0 0.0 451444 5304 ?SApr19 0:05
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8414 0.0 0.0 451452 9660 ?SApr19 0:01
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8418 0.0 0.0 451452 9336 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8426 0.0 0.0 451452 9684 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8428 0.0 0.0 451452 5920 ?SApr19 0:00
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
opensips 8429 0.0 0.0 451416 6544 ?SApr19 0:01
/usr/sbin/opensips -P /var/run/opensips/opensips.pid -m 256 -u opensips -g
opensips
# ps aux | grep -E /usr/sbin/opensips -[P] | awk '{a += $6} END {print a}'
157684
i.e. sum of RSS value, where RSS (man ps)
RSS - resident set size, the non-swapped physical memory that a task has used
(in kiloBytes). (alias rssize, rsz).
How can I help?
On 04/20/2011 10:18 AM, John Khvatov wrote:
Hello Anca,
On 19.04.2011, at 13:21, Anca Vamanu wrote:
Hi John,
That looks very bad...
Please help me investigate this.
What you can do is to compile with memory debugging support - in Makefile.defs
search -DDBG_QM_MALLOC line, uncomment it, move it above -DF_MALLOC line and
comment this line with -DF_MALLOC. Then recompile and reinstall all. Also set
mem_dump=1 in your config.
I've built OpenSIPS from latest SVN head (branch 1.6) as you said.
After a couple of hours, when you see that the memory is high - you can either
shutdown opensips or ask it to dump the memory by calling 'kill -SIGUSR1
lowest_pid' , where lowest_pid is the smallest pid when doing 'ps aux | grep
opensips'. It will dump lots of info in the log file(this why is better to do
this quite soon - maybe after 1-2 hours in the rhythm the memory increases for
you). In the logs you will see all the chunks of memory and where they were
allocated. Look from the end if there is a function repeated many times. You
can also send the part of the
[OpenSIPS-Users] db_postgres: no private memory left
I'm trying to track down the source of the following errors in syslog: /usr/local/sbin/opensips[25490]: WARNING:core:fm_malloc: Not enough free memory, will atempt defragmenation /usr/local/sbin/opensips[25490]: ERROR:core:db_allocate_rows: no memory left /usr/local/sbin/opensips[25490]: ERROR:db_postgres:db_postgres_convert_rows: no private memory left What makes this even more unusual is that it will print these errors at almost exactly 30-min intervals for several hours and then just stop. For example, last night, it printed the above errors at: 23:56:00 00:26:08 00:56:08 01:26:03 01:56:05 02:26:03 02:56:01 03:26:02 and then it stopped... I see no errors in postgresql logs and I haven't yet found any issues with the actual performance of OpenSIPS. I have increased private memory to 100MB and continue to see this randomly. This OpenSIPS instance is using drouting module with about 16,000 lines in the dr_rules table. Any advice would be appreciated to help narrow down the source of these messages. Thanks, Ryan ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] New acc module for cdr generation over Radius
Hello, The new CDRs type of accounting in OpenSIPS 1.6.4 only produces one entry per call for every type of backend, whether it's a DB, Radius or Syslog. So it's natural to only have a single STOP entry per call, and not two, a start and stop entry as in the old type of accounting. The STOP packet should also contain the Sip-Call-Duration and Sip-Call-Duration attributes, defined in the 'etc/dictionary.opensips' dictionary that comes with the OpenSIPS sources. Are you using that provided dictionary ? Regards, Vlad On 04/17/2011 11:38 PM, Maciej Bylica wrote: Dear OS Fans, I've just managed to configure new acc with dialog cdr generation feature with Mysql.etc/dictionary.opensipset It looks fine and realy help to do accouting for some of us. In my scenario there is a need to use Radius. As stated in acc module description, there is a need to use cdr_flag and setflag in initial invite. Once it is set there i do receive only STOP radius acc packet. In case i do not have setflag set anywere in my script Opensips produce START and STOP packet properly. Does anyone knows where to look for the problem? Last question does standard STOP packet incorporate call duration attr anyhow or should i use aaa_extra in my config. My STOP packet is as follows: Sun Apr 17 21:08:38 2011 Acct-Status-Type = Stop Service-Type = IAPP-Register Sip-Response-Code = 200 Sip-Method = Bye Event-Timestamp = \266:\253M\374\212\256 Sip-From-Tag = eb759c18 Sip-To-Tag = 00-07350-027f5afd-492940963 Acct-Session-Id = b0790b4443102642ZTMzOWZlNGU0Njg4MDMwM2EzZjI1NTY5NTllNWFiYjk. User-Name = 11122233@66.66.66.66 Calling-Station-Id = sip:11122233@66.66.66.66 Called-Station-Id = sip:999887766@66.66.66.66 Sip-Translated-Request-URI = sip:77.77.77.77:5060 User-Agent = X-Lite release 1003l stamp 30942 Contact = sip:11122233@10.119.204.184:15950 NAS-Port-Id = 5060 Acct-Delay-Time = 0 NAS-IP-Address = 127.0.0.1 Client-IP-Address = 127.0.0.1 Acct-Unique-Session-Id = 7e6e2ace14ff4970 Timestamp = 1303067318 I do have the latest OS 1.6.4-2-notls revision 7872. Thx in advance for help, Maciej. ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
[OpenSIPS-Users] doubled-up connection IP with use_media_proxy()
Hi list, I ended up with a very strange connection IP in the SDP after using use_media_proxy(): c=IN IP4 65.64.63.365.64.63.2 where 65.64.63.2 and 65.64.63.3 are my obfuscated media relay IP addresses. Could this have been caused by calling use_media_proxy() twice in the same request? Or is that operation benign, and I should be looking for another problem? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy()
I have called Mediaproxy more than once by config error in my setup and have seen it put the mediaproxy IP twice. Looks like you might have the same issue. On Thu, Apr 21, 2011 at 3:00 PM, Jeff Pyle jp...@fidelityvoice.com wrote: Hi list, I ended up with a very strange connection IP in the SDP after using use_media_proxy(): c=IN IP4 65.64.63.365.64.63.2 where 65.64.63.2 and 65.64.63.3 are my obfuscated media relay IP addresses. Could this have been caused by calling use_media_proxy() twice in the same request? Or is that operation benign, and I should be looking for another problem? - Jeff ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- -- *--*--*--*--*--* Duane *--*--*--*--*--* -- ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy()
I went over my config and I think the logic is sound. I'll verify it on a dev box tonight once traffic is low. The call flow is serial forking from one carrier gateway to another when the first sends a 503. * load prefs for first gateway * use_media_proxy() * t_relay() INVITE to first gateway * receive 503 * end_media_session() in failure_route[] * load carrier prefs for second gateway * use_media_proxy() * t_relay() INVITE to second gateway * receive 400 (because of jacked up c= line) * end_media_session() The dispatcher log seems to jive with this. I've got a remove command from the end_media_session() after the first gateway, and the subsequent stats (all 0s), and a remove command from the second end_media_session() and more stats. I think the commands are hitting correctly. Is it not correct to use(), end(), use(), end()? Once I use(), is it impossible to end()?* - Jeff * not referring to a substance abuse issue. really. From: Duane Larson duane.lar...@gmail.commailto:duane.lar...@gmail.com Reply-To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Date: Thu, 21 Apr 2011 16:02:30 -0400 To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy() I have called Mediaproxy more than once by config error in my setup and have seen it put the mediaproxy IP twice. Looks like you might have the same issue. On Thu, Apr 21, 2011 at 3:00 PM, Jeff Pyle jp...@fidelityvoice.commailto:jp...@fidelityvoice.com wrote: Hi list, I ended up with a very strange connection IP in the SDP after using use_media_proxy(): c=IN IP4 65.64.63.365.64.63.2 where 65.64.63.2 and 65.64.63.3 are my obfuscated media relay IP addresses. Could this have been caused by calling use_media_proxy() twice in the same request? Or is that operation benign, and I should be looking for another problem? - Jeff ___ Users mailing list Users@lists.opensips.orgmailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- -- *--*--*--*--*--* Duane *--*--*--*--*--* -- ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy()
I can't reproduce this error now. What a kick in the teeth. I'm using dialog flags , not scripting flags, to indicate whether media proxy is in use. Would there be any delay involved here that might cause the flag to be missed further in the script? I feel like I'm grasping at straws here. I may rewrite the script to use a script flag internally, reading the dialog flag into the script flag on ingress and exporting the script flag's value to the dialog flag on egress. Could this give any possible advantage? - Jeff From: Jeff Pyle jp...@fidelityvoice.commailto:jp...@fidelityvoice.com Reply-To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Date: Thu, 21 Apr 2011 17:14:05 -0400 To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy() I went over my config and I think the logic is sound. I'll verify it on a dev box tonight once traffic is low. The call flow is serial forking from one carrier gateway to another when the first sends a 503. * load prefs for first gateway * use_media_proxy() * t_relay() INVITE to first gateway * receive 503 * end_media_session() in failure_route[] * load carrier prefs for second gateway * use_media_proxy() * t_relay() INVITE to second gateway * receive 400 (because of jacked up c= line) * end_media_session() The dispatcher log seems to jive with this. I've got a remove command from the end_media_session() after the first gateway, and the subsequent stats (all 0s), and a remove command from the second end_media_session() and more stats. I think the commands are hitting correctly. Is it not correct to use(), end(), use(), end()? Once I use(), is it impossible to end()?* - Jeff * not referring to a substance abuse issue. really. From: Duane Larson duane.lar...@gmail.commailto:duane.lar...@gmail.com Reply-To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Date: Thu, 21 Apr 2011 16:02:30 -0400 To: OpenSIPS users mailling list users@lists.opensips.orgmailto:users@lists.opensips.org Subject: Re: [OpenSIPS-Users] doubled-up connection IP with use_media_proxy() I have called Mediaproxy more than once by config error in my setup and have seen it put the mediaproxy IP twice. Looks like you might have the same issue. On Thu, Apr 21, 2011 at 3:00 PM, Jeff Pyle jp...@fidelityvoice.commailto:jp...@fidelityvoice.com wrote: Hi list, I ended up with a very strange connection IP in the SDP after using use_media_proxy(): c=IN IP4 65.64.63.365.64.63.2 where 65.64.63.2 and 65.64.63.3 are my obfuscated media relay IP addresses. Could this have been caused by calling use_media_proxy() twice in the same request? Or is that operation benign, and I should be looking for another problem? - Jeff ___ Users mailing list Users@lists.opensips.orgmailto:Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- -- *--*--*--*--*--* Duane *--*--*--*--*--* -- ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
