DNS SRV Crashes

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

DNS SRV Crashes

Brett Nemeroff
Hi All,
I'm using 1.4.2. I'm using rewritehost followed by a t_relay and I'm getting a crash. Happens every time.

Debug log shows:
Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out. buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(wholesaleorigination.acc.globalipcom.com, 35) failed
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR record found for wholesaleorigination.acc.globalipcom.com, trying direct SRV lookup...
Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid 7787 (shutting down?)
Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del (0x737640, 15, -1, 0x0) fd_no=20 called
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787 exited by a signal 11
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received

I know someone else asked this same question, but I never saw a resolution posted. I do a trace on port 53 at the same time and I most definately see a SRV record returned:

  0.000000 192.168.122.250 -> 192.168.122.132 SIP/SDP Request: INVITE [hidden email], with session description

  0.016831 192.168.122.132 -> 192.168.122.250 SIP Status: 100 Giving a try

  0.026370 192.168.122.132 -> 10.128.222.222 DNS Standard query NAPTR wholesaleorigination.acc.globalipcom.com

  0.059006 10.128.222.222 -> 192.168.122.132 DNS Standard query response

  0.059087 192.168.122.132 -> 10.128.222.222 DNS Standard query NAPTR wholesaleorigination.acc.globalipcom.com.sipinterchange.com

  0.091265 10.128.222.222 -> 192.168.122.132 DNS Standard query response, No such name

  0.091332 192.168.122.132 -> 10.128.222.222 DNS Standard query SRV _sip._udp.wholesaleorigination.acc.globalipcom.com

  0.126236 10.128.222.222 -> 192.168.122.132 DNS Standard query response SRV 100 50 5060 wholesaleoriginationc.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationb.acc.globalipcom.com

8 packets captured

(the packet capture doesn't return anything else past this because opensips is dead)

Any ideas?
Thanks,
Brett


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: DNS SRV Crashes

Sergio Gutierrez

Hi Brett.

This issue has been fixed in OpenSIPS 1.4.3.
I suggest, as much as possible update your installation.

You can download it from http://www.opensips.org/index.php?n=Resources.Downloads#svn

Please, let us know if you have further troubles.

Best regards.

Sergio Gutiérrez.


On Tue, Nov 11, 2008 at 5:19 PM, Brett Nemeroff <[hidden email]> wrote:
Mostly what I expected:
Core was generated by `opensips -Eddddd'.
Program terminated with signal 11, Segmentation fault.
[New process 7787]
#0  do_srv_lookup (name=0x734e20 "_sip._udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
810 else {crt2->next = crt->next;}
(gdb) bt
#0  do_srv_lookup (name=0x734e20 "_sip._udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
#1  0x0000000000455e55 in sip_resolvehost (name=0x7fff3de98e60, port=0x77b292, proto=0x77b294, is_sips=173, dn=0x77b2b8) at resolve.c:1247
#2  0x000000000043da45 in mk_proxy (name=0x7fff3de98e60, port=36288, proto=7787, is_sips=0) at proxy.c:252
#3  0x00007f59350bac67 in add_uac (t=0x7f5931c99e08, request=0x77eb20, uri=0x7fff3de99100, next_hop=0x7fff3de99110, path=<value optimized out>, proxy=0x0) at ut.h:111
#4  0x00007f59350bbed4 in t_forward_nonack (t=0x7f5931c99e08, p_msg=0x0, proxy=0x0) at t_fwd.c:615
#5  0x00007f59350b82b1 in t_relay_to (p_msg=0x77eb20, proxy=0x0, flags=0) at t_funcs.c:252
#6  0x00007f59350c9bfa in w_t_relay (p_msg=0x77eb20, proxy=0x0, flags=0x0) at tm.c:962
#7  0x000000000040f6b7 in do_action (a=0x777568, msg=0x77eb20) at action.c:845
#8  0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#9  0x000000000045fa12 in eval_expr (e=0x777638, msg=0x77eb20, val=0x7799a8) at route.c:1104
#10 0x000000000045f6fc in eval_expr (e=0x777680, msg=0x77eb20, val=0x0) at route.c:1417
#11 0x000000000045f717 in eval_expr (e=0x7776c8, msg=0x77eb20, val=0x0) at route.c:1422
#12 0x000000000040f7ee in do_action (a=0x777870, msg=0x77eb20) at action.c:700
#13 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#14 0x0000000000410881 in do_action (a=0x776fe8, msg=0x77eb20) at action.c:118
#15 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#16 0x0000000000411fc0 in run_top_route (a=0x773a70, msg=0x77eb20) at action.c:118
#17 0x00000000004506e4 in receive_msg (buf=0x1e6b <Address 0x1e6b out of bounds>, len=1038722304, rcv_info=0x7fff3de9a500) at receive.c:165
#18 0x00000000004924d7 in udp_rcv_loop () at udp_server.c:449
#19 0x000000000042928f in main (argc=1038722592, argv=0x20) at main.c:780

Any thoughts?
Thanks,
-Brett


On Tue, Nov 11, 2008 at 4:16 PM, Brett Nemeroff <[hidden email]> wrote:
I found it.. thanks.. maybe I'll run gdb on it and see  if I can make anything out of the backtrace..

Running on Ubuntu 8.04

Thanks for your help
-Brett


On Tue, Nov 11, 2008 at 4:15 PM, Sergio Gutierrez <[hidden email]> wrote:
Hi Brett.

Is not OpenSER creating a core file when fails? Maybe try to find it at /

By the way, what Operating System are you running on?

Check also in OpenSER configuration file to make sure that disable_core_dump is set to no.

Regards.

--
Sergio Gutiérrez




On Tue, Nov 11, 2008 at 5:10 PM, Brett Nemeroff <[hidden email]> wrote:
Well I definitely see it doing a SRV lookup. When it gets the reply it dies. I'm not really sure how to make it dump core or how to make that available to the developers.

The domain I'm using is hosted by Verizon and they control the DNS. Using DIG yields valid SRV records. 


On Tue, Nov 11, 2008 at 4:06 PM, Sergio Gutierrez <[hidden email]> wrote:

Hello Brett.

If you are trying to use SRV location, I suggest to do it this way: rewriteport("");

The last line is equivalente to define port as 0, which implies a SRV lookup.

Anyway, make sure your DNS defines wholesaleorigination.acc.globalipcom.com as a SRV RR for SIP.

Anyway, the issue you reported would be investigated. I suggest to paste to a backtrace from the corefile, so that developers can trace it.

Regards.

--
Sergio Gutiérrez


On Tue, Nov 11, 2008 at 5:02 PM, Brett Nemeroff <[hidden email]> wrote:
It's excessively boring:

main route block........{
...
        if ($rU==NULL) {
                # request with no Username in RURI
                sl_send_reply("484","Address Incomplete");
                exit;
        }


        rewritehost("wholesaleorigination.acc.globalipcom.com");

        route(1);
        exit;

}


route[1] {
        # for INVITEs enable some additional helper routes
        if (is_method("INVITE")) {
        #       t_on_branch("2");
                #t_on_reply("2");
                #t_on_failure("1");
        }

        if (!t_relay()) {
                sl_reply_error();
        };
        exit;
}


On Tue, Nov 11, 2008 at 3:56 PM, Sergio Gutierrez <[hidden email]> wrote:
Hello Brett.

could you paste the section of your config file where you are calling rewritehost?

Best regards.

Sergio Gutiérrez.

On Tue, Nov 11, 2008 at 4:55 PM, Brett Nemeroff <[hidden email]> wrote:
Hi All,
I'm using 1.4.2. I'm using rewritehost followed by a t_relay and I'm getting a crash. Happens every time.

Debug log shows:
Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out. buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(wholesaleorigination.acc.globalipcom.com, 35) failed
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR record found for wholesaleorigination.acc.globalipcom.com, trying direct SRV lookup...
Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid 7787 (shutting down?)
Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del (0x737640, 15, -1, 0x0) fd_no=20 called
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787 exited by a signal 11
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received

I know someone else asked this same question, but I never saw a resolution posted. I do a trace on port 53 at the same time and I most definately see a SRV record returned:

  0.000000 192.168.122.250 -> 192.168.122.132 SIP/SDP Request: INVITE [hidden email], with session description

  0.016831 192.168.122.132 -> 192.168.122.250 SIP Status: 100 Giving a try

  0.026370 192.168.122.132 -> 10.128.222.222 DNS Standard query NAPTR wholesaleorigination.acc.globalipcom.com

  0.059006 10.128.222.222 -> 192.168.122.132 DNS Standard query response

  0.059087 192.168.122.132 -> 10.128.222.222 DNS Standard query NAPTR wholesaleorigination.acc.globalipcom.com.sipinterchange.com

  0.091265 10.128.222.222 -> 192.168.122.132 DNS Standard query response, No such name

  0.091332 192.168.122.132 -> 10.128.222.222 DNS Standard query SRV _sip._udp.wholesaleorigination.acc.globalipcom.com

  0.126236 10.128.222.222 -> 192.168.122.132 DNS Standard query response SRV 100 50 5060 wholesaleoriginationc.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060 wholesaleoriginationb.acc.globalipcom.com

8 packets captured

(the packet capture doesn't return anything else past this because opensips is dead)

Any ideas?
Thanks,
Brett


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

















--
Sergio Gutiérrez

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: DNS SRV Crashes

Sergio Gutierrez
In reply to this post by Brett Nemeroff
Hi Brett.
 
I apologize for a error in my last mail. You would not update to 1.4.3, but you would update to SVN latest stable version 1.4
 
Best regards.
 
Sergio.

 
On 11/11/08, Sergio Gutierrez <[hidden email]> wrote:
Hi Brett.

Is it difficult to you update to 1.4.3?

As I can see comparing the sources, there are some changes which I think fix the crash you are facing.

Regards.

--
Sergio Gutiérrez


On Tue, Nov 11, 2008 at 5:19 PM, Brett Nemeroff <[hidden email]> wrote:
Mostly what I expected:
Core was generated by `opensips -Eddddd'.
Program terminated with signal 11, Segmentation fault.
[New process 7787]
#0  do_srv_lookup (name=0x734e20 "_sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
810 else {crt2->next = crt->next;}
(gdb) bt
#0  do_srv_lookup (name=0x734e20 "_sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
#1  0x0000000000455e55 in sip_resolvehost (name=0x7fff3de98e60, port=0x77b292, proto=0x77b294, is_sips=173, dn=0x77b2b8) at resolve.c:1247
#2  0x000000000043da45 in mk_proxy (name=0x7fff3de98e60, port=36288, proto=7787, is_sips=0) at proxy.c:252
#3  0x00007f59350bac67 in add_uac (t=0x7f5931c99e08, request=0x77eb20, uri=0x7fff3de99100, next_hop=0x7fff3de99110, path=<value optimized out>, proxy=0x0) at ut.h:111
#4  0x00007f59350bbed4 in t_forward_nonack (t=0x7f5931c99e08, p_msg=0x0, proxy=0x0) at t_fwd.c:615
#5  0x00007f59350b82b1 in t_relay_to (p_msg=0x77eb20, proxy=0x0, flags=0) at t_funcs.c:252
#6  0x00007f59350c9bfa in w_t_relay (p_msg=0x77eb20, proxy=0x0, flags=0x0) at tm.c:962
#7  0x000000000040f6b7 in do_action (a=0x777568, msg=0x77eb20) at action.c:845
#8  0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#9  0x000000000045fa12 in eval_expr (e=0x777638, msg=0x77eb20, val=0x7799a8) at route.c:1104
#10 0x000000000045f6fc in eval_expr (e=0x777680, msg=0x77eb20, val=0x0) at route.c:1417
#11 0x000000000045f717 in eval_expr (e=0x7776c8, msg=0x77eb20, val=0x0) at route.c:1422
#12 0x000000000040f7ee in do_action (a=0x777870, msg=0x77eb20) at action.c:700
#13 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#14 0x0000000000410881 in do_action (a=0x776fe8, msg=0x77eb20) at action.c:118
#15 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#16 0x0000000000411fc0 in run_top_route (a=0x773a70, msg=0x77eb20) at action.c:118
#17 0x00000000004506e4 in receive_msg (buf=0x1e6b <Address 0x1e6b out of bounds>, len=1038722304, rcv_info=0x7fff3de9a500) at receive.c:165
#18 0x00000000004924d7 in udp_rcv_loop () at udp_server.c:449
#19 0x000000000042928f in main (argc=1038722592, argv=0x20) at main.c:780

 
Any thoughts?
Thanks,
-Brett

 

On Tue, Nov 11, 2008 at 4:16 PM, Brett Nemeroff <[hidden email]> wrote:
I found it.. thanks.. maybe I'll run gdb on it and see  if I can make anything out of the backtrace..

 
Running on Ubuntu 8.04

 
Thanks for your help
-Brett


On Tue, Nov 11, 2008 at 4:15 PM, Sergio Gutierrez <[hidden email]> wrote:
Hi Brett.

Is not OpenSER creating a core file when fails? Maybe try to find it at /

By the way, what Operating System are you running on?

Check also in OpenSER configuration file to make sure that disable_core_dump is set to no.

Regards.

--
Sergio Gutiérrez




On Tue, Nov 11, 2008 at 5:10 PM, Brett Nemeroff <[hidden email]> wrote:
Well I definitely see it doing a SRV lookup. When it gets the reply it dies. I'm not really sure how to make it dump core or how to make that available to the developers.

 
The domain I'm using is hosted by Verizon and they control the DNS. Using DIG yields valid SRV records. 


On Tue, Nov 11, 2008 at 4:06 PM, Sergio Gutierrez <[hidden email]> wrote:

Hello Brett.

If you are trying to use SRV location, I suggest to do it this way:


rewritehost("<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com");
 
rewriteport("");

The last line is equivalente to define port as 0, which implies a SRV lookup.

Anyway, make sure your DNS defines <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com as a SRV RR for SIP.

Anyway, the issue you reported would be investigated. I suggest to paste to a backtrace from the corefile, so that developers can trace it.

Regards.

--
Sergio Gutiérrez


On Tue, Nov 11, 2008 at 5:02 PM, Brett Nemeroff <[hidden email]> wrote:
It's excessively boring:

 
main route block........{
...
        if ($rU==NULL) {
                # request with no Username in RURI
                sl_send_reply("484","Address Incomplete");
                exit;
        }

 

 
        rewritehost("<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com");

 
        route(1);
        exit;

 
}

 

 
route[1] {
        # for INVITEs enable some additional helper routes
        if (is_method("INVITE")) {
        #       t_on_branch("2");
                #t_on_reply("2");
                #t_on_failure("1");
        }

 
        if (!t_relay()) {
                sl_reply_error();
        };
        exit;
}

 

On Tue, Nov 11, 2008 at 3:56 PM, Sergio Gutierrez <[hidden email]> wrote:
Hello Brett.

could you paste the section of your config file where you are calling rewritehost?

Best regards.

Sergio Gutiérrez.

On Tue, Nov 11, 2008 at 4:55 PM, Brett Nemeroff <[hidden email]> wrote:
 
Hi All,
I'm using <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://1.4.2./" target="_blank">1.4.2. I'm using rewritehost followed by a t_relay and I'm getting a crash. Happens every time.

 
Debug log shows:
Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out. buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com, 35) failed
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR record found for <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com, trying direct SRV lookup...
Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid 7787 (shutting down?)
Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del (0x737640, 15, -1, 0x0) fd_no=20 called
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787 exited by a signal 11
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received

 
I know someone else asked this same question, but I never saw a resolution posted. I do a trace on port 53 at the same time and I most definately see a SRV record returned:

  0.000000 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.250/" target="_blank">192.168.122.250 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 SIP/SDP Request: INVITE [hidden email], with session description

  0.016831 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.250/" target="_blank">192.168.122.250 SIP Status: 100 Giving a try

  0.026370 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query NAPTR <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com

  0.059006 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response

  0.059087 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query NAPTR <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com.sipinterchange.com/" target="_blank">wholesaleorigination.acc.globalipcom.com.sipinterchange.com

  0.091265 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response, No such name

  0.091332 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query SRV _sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com

  0.126236 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationc.acc.globalipcom.com/" target="_blank">wholesaleoriginationc.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationd.acc.globalipcom.com/" target="_blank">wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationa.acc.globalipcom.com/" target="_blank">wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationb.acc.globalipcom.com/" target="_blank">wholesaleoriginationb.acc.globalipcom.com

8 packets captured

(the packet capture doesn't return anything else past this because opensips is dead)

Any ideas?
Thanks,
Brett


 
_______________________________________________
Users mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users



 




 

 




 

 

 



--
Sergio Gutiérrez



--
Sergio Gutiérrez
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Fwd: DNS SRV Crashes

Sergio Gutierrez

Hi Brett.
 
I apologize for a error in my last mail. You would not update to 1.4.3, but you would update to SVN latest stable version 1.4
 
Best regards.
 
Sergio.

 
On 11/11/08, Sergio Gutierrez <[hidden email]> wrote:
Hi Brett.

Is it difficult to you update to 1.4.3?

As I can see comparing the sources, there are some changes which I think fix the crash you are facing.

Regards.

--
Sergio Gutiérrez


On Tue, Nov 11, 2008 at 5:19 PM, Brett Nemeroff <[hidden email]> wrote:
Mostly what I expected:
Core was generated by `opensips -Eddddd'.
Program terminated with signal 11, Segmentation fault.
[New process 7787]
#0  do_srv_lookup (name=0x734e20 "_sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
810 else {crt2->next = crt->next;}
(gdb) bt
#0  do_srv_lookup (name=0x734e20 "_sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com", port=0x77b292, dn=0x77b2b8) at resolve.c:810
#1  0x0000000000455e55 in sip_resolvehost (name=0x7fff3de98e60, port=0x77b292, proto=0x77b294, is_sips=173, dn=0x77b2b8) at resolve.c:1247
#2  0x000000000043da45 in mk_proxy (name=0x7fff3de98e60, port=36288, proto=7787, is_sips=0) at proxy.c:252
#3  0x00007f59350bac67 in add_uac (t=0x7f5931c99e08, request=0x77eb20, uri=0x7fff3de99100, next_hop=0x7fff3de99110, path=<value optimized out>, proxy=0x0) at ut.h:111
#4  0x00007f59350bbed4 in t_forward_nonack (t=0x7f5931c99e08, p_msg=0x0, proxy=0x0) at t_fwd.c:615
#5  0x00007f59350b82b1 in t_relay_to (p_msg=0x77eb20, proxy=0x0, flags=0) at t_funcs.c:252
#6  0x00007f59350c9bfa in w_t_relay (p_msg=0x77eb20, proxy=0x0, flags=0x0) at tm.c:962
#7  0x000000000040f6b7 in do_action (a=0x777568, msg=0x77eb20) at action.c:845
#8  0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#9  0x000000000045fa12 in eval_expr (e=0x777638, msg=0x77eb20, val=0x7799a8) at route.c:1104
#10 0x000000000045f6fc in eval_expr (e=0x777680, msg=0x77eb20, val=0x0) at route.c:1417
#11 0x000000000045f717 in eval_expr (e=0x7776c8, msg=0x77eb20, val=0x0) at route.c:1422
#12 0x000000000040f7ee in do_action (a=0x777870, msg=0x77eb20) at action.c:700
#13 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#14 0x0000000000410881 in do_action (a=0x776fe8, msg=0x77eb20) at action.c:118
#15 0x000000000040e52a in run_action_list (a=<value optimized out>, msg=0x77eb20) at action.c:138
#16 0x0000000000411fc0 in run_top_route (a=0x773a70, msg=0x77eb20) at action.c:118
#17 0x00000000004506e4 in receive_msg (buf=0x1e6b <Address 0x1e6b out of bounds>, len=1038722304, rcv_info=0x7fff3de9a500) at receive.c:165
#18 0x00000000004924d7 in udp_rcv_loop () at udp_server.c:449
#19 0x000000000042928f in main (argc=1038722592, argv=0x20) at main.c:780

 
Any thoughts?
Thanks,
-Brett

 

On Tue, Nov 11, 2008 at 4:16 PM, Brett Nemeroff <[hidden email]> wrote:
I found it.. thanks.. maybe I'll run gdb on it and see  if I can make anything out of the backtrace..

 
Running on Ubuntu 8.04

 
Thanks for your help
-Brett


On Tue, Nov 11, 2008 at 4:15 PM, Sergio Gutierrez <[hidden email]> wrote:
Hi Brett.

Is not OpenSER creating a core file when fails? Maybe try to find it at /

By the way, what Operating System are you running on?

Check also in OpenSER configuration file to make sure that disable_core_dump is set to no.

Regards.

--
Sergio Gutiérrez




On Tue, Nov 11, 2008 at 5:10 PM, Brett Nemeroff <[hidden email]> wrote:
Well I definitely see it doing a SRV lookup. When it gets the reply it dies. I'm not really sure how to make it dump core or how to make that available to the developers.

 
The domain I'm using is hosted by Verizon and they control the DNS. Using DIG yields valid SRV records. 


On Tue, Nov 11, 2008 at 4:06 PM, Sergio Gutierrez <[hidden email]> wrote:

Hello Brett.

If you are trying to use SRV location, I suggest to do it this way:


rewritehost("<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com");
 
rewriteport("");

The last line is equivalente to define port as 0, which implies a SRV lookup.

Anyway, make sure your DNS defines <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com as a SRV RR for SIP.

Anyway, the issue you reported would be investigated. I suggest to paste to a backtrace from the corefile, so that developers can trace it.

Regards.

--
Sergio Gutiérrez


On Tue, Nov 11, 2008 at 5:02 PM, Brett Nemeroff <[hidden email]> wrote:
It's excessively boring:

 
main route block........{
...
        if ($rU==NULL) {
                # request with no Username in RURI
                sl_send_reply("484","Address Incomplete");
                exit;
        }

 

 
        rewritehost("<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com");

 
        route(1);
        exit;

 
}

 

 
route[1] {
        # for INVITEs enable some additional helper routes
        if (is_method("INVITE")) {
        #       t_on_branch("2");
                #t_on_reply("2");
                #t_on_failure("1");
        }

 
        if (!t_relay()) {
                sl_reply_error();
        };
        exit;
}

 

On Tue, Nov 11, 2008 at 3:56 PM, Sergio Gutierrez <[hidden email]> wrote:
Hello Brett.

could you paste the section of your config file where you are calling rewritehost?

Best regards.

Sergio Gutiérrez.

On Tue, Nov 11, 2008 at 4:55 PM, Brett Nemeroff <[hidden email]> wrote:
 
Hi All,
I'm using <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://1.4.2./" target="_blank">1.4.2. I'm using rewritehost followed by a t_relay and I'm getting a crash. Happens every time.

 
Debug log shows:
Nov 11 08:58:51 [7787] DBG:core:_shm_resize: resize(0) called
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: reply sent out. buf=0x77b278: SIP/2.0 1..., shmem=0x7f5931c9cda8: SIP/2.0 1
Nov 11 08:58:51 [7787] DBG:tm:_reply_light: finished
Nov 11 08:58:51 [7787] DBG:core:mk_proxy: doing DNS lookup...
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no port, no proto -> do NAPTR lookup!
Nov 11 08:58:51 [7787] DBG:core:get_record: lookup(<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com, 35) failed
Nov 11 08:58:51 [7787] DBG:core:sip_resolvehost: no valid NAPTR record found for <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com, trying direct SRV lookup...
Nov 11 08:58:51 [7794] CRITICAL:core:receive_fd: EOF on 15
Nov 11 08:58:51 [7794] DBG:core:handle_ser_child: dead child 8, pid 7787 (shutting down?)
Nov 11 08:58:51 [7794] DBG:core:io_watch_del: io_watch_del (0x737640, 15, -1, 0x0) fd_no=20 called
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: child process 7787 exited by a signal 11
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: core was generated
Nov 11 08:58:51 [7779] INFO:core:handle_sigs: terminating due to SIGCHLD
Nov 11 08:58:51 [7780] INFO:core:sig_usr: signal 15 received

 
I know someone else asked this same question, but I never saw a resolution posted. I do a trace on port 53 at the same time and I most definately see a SRV record returned:

  0.000000 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.250/" target="_blank">192.168.122.250 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 SIP/SDP Request: INVITE [hidden email], with session description

  0.016831 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.250/" target="_blank">192.168.122.250 SIP Status: 100 Giving a try

  0.026370 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query NAPTR <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com/" target="_blank">wholesaleorigination.acc.globalipcom.com

  0.059006 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response

  0.059087 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query NAPTR <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleorigination.acc.globalipcom.com.sipinterchange.com/" target="_blank">wholesaleorigination.acc.globalipcom.com.sipinterchange.com

  0.091265 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response, No such name

  0.091332 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 DNS Standard query SRV _sip._<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://udp.wholesaleorigination.acc.globalipcom.com/" target="_blank">udp.wholesaleorigination.acc.globalipcom.com

  0.126236 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://10.128.222.222/" target="_blank">10.128.222.222 -> <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://192.168.122.132/" target="_blank">192.168.122.132 DNS Standard query response SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationc.acc.globalipcom.com/" target="_blank">wholesaleoriginationc.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationd.acc.globalipcom.com/" target="_blank">wholesaleoriginationd.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationa.acc.globalipcom.com/" target="_blank">wholesaleoriginationa.acc.globalipcom.com SRV 100 50 5060 <a onclick="return top.js.OpenExtLink(window,event,this)" href="http://wholesaleoriginationb.acc.globalipcom.com/" target="_blank">wholesaleoriginationb.acc.globalipcom.com

8 packets captured

(the packet capture doesn't return anything else past this because opensips is dead)

Any ideas?
Thanks,
Brett


 
_______________________________________________
Users mailing list
[hidden email]
<a onclick="return top.js.OpenExtLink(window,event,this)" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" target="_blank">http://lists.opensips.org/cgi-bin/mailman/listinfo/users



 




 

 




 

 

 



--
Sergio Gutiérrez



--
Sergio Gutiérrez


--
Sergio Gutiérrez
_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Regarding watchers in OpenSIPS

mahesh.peddi
Hi all,
 
I need some clarifications regarding watchers in OpenSIPS. Actually i am registering as a bob and alice to the OpenSIPS. And bob is having alice in his buddy list and alice is having bob in his buddy list. while registering, both of them are sending SUBSCRIBE (presence.winfo) messages to OpenSIPS and also getting the NOTIFY (application/watcherinfo+xml) message.
 
 
My Question is "If bob changes his status lets say 'busy' then what type of NOTIFY alice will get? i mean application/watcherinfo+xml or application/pidf+xml".
 
 
Thanks & Regards,
Mahesh

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Reply | Threaded
Open this post in threaded view
|

Re: Regarding watchers in OpenSIPS

Anca Vamanu
Hi Mahesh,

OpenSIPS presence works as described in RFC 3856 for presence event and
RFC 3857 for presence.winfo. (Your questions are in fact about how this
protocol work.., but I will help you anyway).

So, to get the status of a buddy you need a SUBSCRIBE for 'presence'.
Look if there a a subscribe with Event: presence sent from alice to bob.
And if there is the when you change the status of bob to 'busy' you will
see a Notify sent to alice woth bob's new state.

The Subscribe for 'presence.winfo' is for a user to know who has
subscribed to their presence state. So if bob subscribed to
presence.winfo and alice subscribed for presence to bob,  the bob will
receive a Notify in which he will be announced that he has a watcher -
alice.

What client are you using? Make sure you have clicked the 'show status'
option for the contact in the buddy list. Watch the traces for Subscribe
with header 'Event:presence'.

regards,
Anca

[hidden email] wrote:

> Hi all,
>  
> I need some clarifications regarding watchers in OpenSIPS. Actually i
> am registering as a bob and alice to the OpenSIPS. And bob is having
> alice in his buddy list and alice is having bob in his buddy list.
> while registering, both of them are sending SUBSCRIBE (presence.winfo)
> messages to OpenSIPS and also getting the NOTIFY
> (application/watcherinfo+xml) message.
>  
>  
> My Question is "If bob changes his status lets say 'busy' then what
> type of NOTIFY alice will get? i mean application/watcherinfo+xml or
> application/pidf+xml".
>  
>  
> Thanks & Regards,
> Mahesh
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> [hidden email]
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>  

_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

anca.vcf (219 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Without watchers is it possible to get presence support in OpenSIPS

mahesh.peddi
Hi All,

I have some questions regarding OpenSIPS.

(1).without watchers is it possible to get presence support in OpenSIPS?

(2). lets say i have list of 10 buddies and i want to show my presence to
only 2 buddies. Is it possible to test this scenario with OpenSIPS. If it is
possible how to test and anything need to implement(any changes in watchers)
at client side for getting this test scenario.

Thanks & Regards,
Mahesh.


 


_______________________________________________
Users mailing list
[hidden email]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users