3 Nov
2007
3 Nov
'07
3:07 a.m.
Hi all,
I have an issue, where the sip user dials 911 number and hangs up. The 911
operator then calls back to the user using the call back command provided
earlier say 8911 (there is a b2bua that interprets the call back number and
routes the call to the specific user). This number is to be routed via the
openser proxy to the b2bua. However, when the 911 calls back, proxy treats
this number as a username and since there are no registrations to this 8911
number (though this entry is present at the proxy, no device has registered
with this number), it sends back "404 Not found". How can this be
circumvented?
Thanks,
Padmaja
----- Original Message -----
From: <users-request(a)lists.openser.org>
To: <users(a)lists.openser.org>
Sent: Saturday, November 03, 2007 3:46 AM
Subject: Users Digest, Vol 30, Issue 6
> Send Users mailing list submissions to
> users(a)lists.openser.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-request(a)lists.openser.org
>
> You can reach the person managing the list at
> users-owner(a)lists.openser.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Users digest..."
>
>
> Today's Topics:
>
> 1. Core dumped when deploying presence module (Sergio Gutierrez)
> 2. Re: MediaProxy 1.9.0 - Radius (Brian Heath)
> 3. Re: Forking Madness (Chris Heiser)
> 4. Re: MediaProxy 1.9.0 - Radius (Mike O'Connor)
> 5. Re: MediaProxy 1.9.0 - Radius (Ovidiu Sas)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Nov 2007 15:59:56 -0500
> From: "Sergio Gutierrez" <saguti(a)gmail.com>
> Subject: [OpenSER-Users] Core dumped when deploying presence module
> To: users(a)lists.openser.org, users(a)openser.org
> Message-ID:
> <8a4af3e20711021359p3327c719t4ae680de4ac3e155(a)mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hello to all members.
>
> Currently we are trying to deploy presence module in the following
> environment:
>
> 1. Openser 1.2.1
> 2. Solaris 10 on Sparc System
> 3. libxml 2.6.30
>
> Openser starts up fine, but when happens any event as a Status change of a
> user agent, Openser crashes.
> Below I send an extract from the logfile, and the backtrace of the core.
> Thanks in advance for your attention.
>
> Sergio Guti?rrez
> EPM Telecomunicaciones
> Medellin - Colombia
>
> ****************************************************
>>From Openser logfile.
>
> 0(5493) Nuevo Requerimiento - M=SUBSCRIBE
> RURI=sip:5192901@200.13.225.250F=
> sip:5192902@200.13.225.250 T=sip:5192901@200.13.225.250
> IP=200.116.28.88ID=YmE2MGVhMGQzMTI3ZmU0YTkzMDJjNjIxODNmMGIwOWE.
> 0(5493) comp_scriptvar: str 20 : 5192901
> 0(5493) DEBUG:maxfwd:is_maxfwd_present: value = 70
> 0(5493) parse_headers: flags=ffffffffffffffff
> 0(5493) get_hdr_field: cseq <CSeq>: <1> <SUBSCRIBE>
> 0(5493) DEBUG: get_hdr_body : content_length=0
> 0(5493) found end of header
> 0(5493) PRESENCE: handle_subscribe: 'expires' found
> 0(5493) PRESENCE: handle_subscribe: lexpire= 3600
> 0(5493) PRESENCE: handle_subscribe: 'To' header ALREADY PARSED: <
> sip:5192901@200.13.225.250>
> 0(5493) PRESENCE:handle_subscribe: generating to_tag
> 0(5493)
> [p_user]= 5192901 [p_domain]= 200.13.225.250
> [w_user]= 5192902 [w_domain]= 200.13.225.250
> 0(5493) [event]= presence
> [staus]= pending
> [expires]= 3600
> 0(5493) [to_tag]= 10.5493.1194034490.40
> [from_tag]= 1f783845
> 0(5493) PRESENCE: update_subscription ...
> 0(5493)
> [p_user]= 5192901 [p_domain]= 200.13.225.250
> [w_user]= 5192902 [w_domain]= 200.13.225.250
> 0(5493) [event]= presence
> [staus]= pending
> [expires]= 3600
> 0(5493) [to_tag]= 10.5493.1194034490.40
> [from_tag]= 1f783845
> 0(5493) expires: 3600
> 0(5493) PRESENCE:update_subscription:Inserting into database:
> n_query_cols:14
> 0(5493) [0] = to_user 5192901
> 0(5493) [1] = to_domain 200.13.225.250
> 0(5493) [2] = from_user 5192902
> 0(5493) [3] = from_domain 200.13.225.250
> 0(5493) [4] = event presence
> 0(5493) [5] = event_id
> 0(5493) [6] = callid YmE2MGVhMGQzMTI3ZmU0YTkzMDJjNjIxODNmMGIwOWE.
> 0(5493) [7] = to_tag 10.5493.1194034490.40
> 0(5493) [8] = from_tag 1f783845
> 0(5493) [9] = contact sip:5192902@200.116.28.88:47166
> 0(5493) [10] = status pending
> 0(5493) [11] = cseq 1
> 0(5493) [12] = expires 1194038090
> 0(5493) [13] = version 0
> 0(5493) parse_headers: flags=ffffffffffffffff
> 0(5493) check_via_address(200.116.28.88, 192.168.0.13, 0)
> 0(5493) DBG:sl:run_sl_callbacks: callback id 0 entered
> 0(5493) trace_sl_onreply_out: trace off...
> 0(5493) PRESENCE: get_subs_dialog:n= 1
> 0(5493) PRESENCE:notify:dialog informations:
> 0(5493)
> [p_user]= 5192901 [p_domain]= 200.13.225.250
> [w_user]= 5192901 [w_domain]= 200.13.225.250
> 0(5493) [event]= presence.winfo
> [staus]= active
> [expires]= 3518
> 0(5493) [to_tag]= 10.5493.1194034408.34
> [from_tag]= 39320458
> 0(5493) presence:uandd_to_uri: uri=sip:5192901@200.13.225.250
> 0(5493) presence:uandd_to_uri: uri=sip:5192902@200.13.225.250
> 0(5493) presence:uandd_to_uri: uri=sip:5192901@200.13.225.250
> 0(5493) PRESENCE: notify: build notify to user= 5192901 domain=
> 200.13.225.250 for event= presence.winfo
> 0(5493)
> [p_user]= 5192901 [p_domain]= 200.13.225.250
> [w_user]= 5192901 [w_domain]= 200.13.225.250
> 0(5493) [event]= presence.winfo
> [staus]= active
> [expires]= 3518
> 0(5493) [to_tag]= 10.5493.1194034408.34
> [from_tag]= 39320458
> 0(5493) PRESENCE:build_str_hdr: expires = 3518
> 0(5493) PRESENCE:build_str_hdr: subs_expires : 3518
> 0(5493) PRESENCE: build_str_hdr: headers:
> Event: presence.winfo
> Contact: <sip:200.13.225.250:5060>
> Subscription-State: active;expires=3518
> Content-Type: application/watcherinfo+xml
>
> 0(5493) PRESENCE:notify: headers:Event: presence.winfo
> Contact: <sip:200.13.225.250:5060>
> Subscription-State: active;expires=3518
> Content-Type: application/watcherinfo+xml
>
> 0(5493) CONTACT = sip:5192901@200.13.254.180:17116
> 0(5493) presence:uandd_to_uri: uri=sip:5192901@200.13.225.250
> 0(5493) parse_rr_body(): No body for record-route
> 0(5493) PRESENCE: notify:Send notify for presence on callback 1(5494)
> DEBUG: timer routine:4,tl=fc5c9a80 next=0, timeout=353600000
> 1(5494) DEBUG: retransmission_handler : request resending (t=fc5c9910,
> NOTIFY si ... )
> 1(5494) DEBUG:tm:set_timer: relative timeout is 1000000
> 1(5494) DEBUG: add_to_tail_of_timer[5]: fc5c9a80 (354600000)
> 1(5494) DEBUG: retransmission_handler : done
> 1(5494) DEBUG: timer routine:5,tl=fc5c9a80 next=0, timeout=354600000
> 1(5494) DEBUG: retransmission_handler : request resending (t=fc5c9910,
> NOTIFY si ... )
> 1(5494) DEBUG:tm:set_timer: relative timeout is 2000000
> 1(5494) DEBUG: add_to_tail_of_timer[6]: fc5c9a80 (356600000)
> 1(5494) DEBUG: retransmission_handler : done
> 1(5494) DEBUG: timer routine:6,tl=fc5c9a80 next=0, timeout=356600000
> 1(5494) DEBUG: retransmission_handler : request resending (t=fc5c9910,
> NOTIFY si ... )
> 1(5494) DEBUG:tm:set_timer: relative timeout is 4000000
> 1(5494) DEBUG: add_to_tail_of_timer[7]: fc5c9a80 (360600000)
> 1(5494) DEBUG: retransmission_handler : done
>
>
> ********************************************************************************
> Backtrace of the core:
>
> #0 0xfe7f77bc in shm_dup_subs (subs=0xffbff1b0, to_tag=Cannot access
> memory
> at address 0x96
> ) at notify.c:1819
> 1819 cb_param->wi_subs->to_user.s = (char*)cb_param + size;
> (gdb) bt
> #0 0xfe7f77bc in shm_dup_subs (subs=0xffbff1b0, to_tag=Cannot access
> memory
> at address 0x96
> ) at notify.c:1819
> #1 0xfe7f8238 in notify (subs=0x1779c8, watcher_subs=0x15, n_body=0x0,
> force_null_body=1024) at notify.c:1562
> #2 0xfe7f8f18 in query_db_notify (p_user=0x234, p_domain=0xdff08,
> event=0xfe809a28 "presence.winfo", watcher_subs=0xffbff1b0, etag=0x0)
> at notify.c:957
> #3 0xfe8028a8 in update_subscription (msg=0x175fd8, subs=0xffbff1b0,
> rtag=0xffbff228, to_tag_gen=1) at subscribe.c:476
> #4 0xfe805080 in handle_subscribe (msg=0x175fd8, str1=0xffbff0e0 "",
> str2=0x800 <Address 0x800 out of bounds>) at subscribe.c:1252
> #5 0x00018378 in do_action (a=0x145270, msg=0x175fd8) at action.c:883
> #6 0x00019bb8 in run_action_list (a=0x145270, msg=0x175fd8) at
> action.c:131
> #7 0x000192bc in do_action ()
> #8 0x00019bb8 in run_action_list (a=0x1452c8, msg=0x175fd8) at
> action.c:131
> #9 0x00019df8 in run_top_route (a=0x143e10, msg=0x175fd8) at action.c:111
> #10 0x00043b60 in receive_msg (buf=0x12dc00 "", len=1024,
> rcv_info=0xe0400)
> at receive.c:156
> #11 0x0006f294 in udp_rcv_loop () at udp_server.c:465
> #12 0x000338bc in main_loop () at main.c:834
> #13 0x00035c44 in main (argc=9, argv=0xe7800) at main.c:1399
> (gdb) quit
>
6 Nov
6 Nov
10:57 a.m.
Hi Padmaja,
There is no other way around but just to implement a call back service
on your proxy. Save in DB the last caller hitting the 911 service and
when receiving the 8911, just load it and fwd to it.
regards,
bogdan
Padmaja wrote:
Hi all,
I have an issue, where the sip user dials 911 number and hangs up. The 911
operator then calls back to the user using the call back command provided
earlier say 8911 (there is a b2bua that interprets the call back number and
routes the call to the specific user). This number is to be routed via the
openser proxy to the b2bua. However, when the 911 calls back, proxy treats
this number as a username and since there are no registrations to this 8911
number (though this entry is present at the proxy, no device has registered
with this number), it sends back "404 Not found". How can this be
circumvented?
Thanks,
Padmaja
12 Nov
12 Nov
2:27 a.m.
Hi Bogdan,
Thanks for your answers. I am however, new to openser.
I tried the solution provided by Christian today but there are some errors
coming up saying there is no function like forward(). Can you elaborate the
steps for the solution you provided?
Thanks again,
Padmaja
----- Original Message -----
From: "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro>
To: "Padmaja" <padmaja.rv(a)vodcalabs.com>
Cc: <users(a)lists.openser.org>
Sent: Tuesday, November 06, 2007 6:27 PM
Subject: Re: [OpenSER-Users] Reg. conditional processing of invite
Hi Padmaja,
There is no other way around but just to implement a call back service on
your proxy. Save in DB the last caller hitting the 911 service and when
receiving the 8911, just load it and fwd to it.
regards,
bogdan
Padmaja wrote:
Hi all,
I have an issue, where the sip user dials 911 number and hangs up. The
911 operator then calls back to the user using the call back command
provided earlier say 8911 (there is a b2bua that interprets the call back
number and routes the call to the specific user). This number is to be
routed via the openser proxy to the b2bua. However, when the 911 calls
back, proxy treats this number as a username and since there are no
registrations to this 8911 number (though this entry is present at the
proxy, no device has registered with this number), it sends back "404 Not
found". How can this be circumvented?
Thanks,
Padmaja
2:29 a.m.
Hi Christian,
Thanks for your reply. I could not check the solution you provided earlier.
Just tried the code you provided but the proxy is giving some errors like
there is no forward() function defined etc., .Any other suggestions?
Thank You,
Padmaja
----- Original Message -----
From: "Bogdan-Andrei Iancu" <bogdan(a)voice-system.ro>
To: "Padmaja" <padmaja.rv(a)vodcalabs.com>
Cc: <users(a)lists.openser.org>
Sent: Tuesday, November 06, 2007 6:27 PM
Subject: Re: [OpenSER-Users] Reg. conditional processing of invite
Hi Padmaja,
There is no other way around but just to implement a call back service on
your proxy. Save in DB the last caller hitting the 911 service and when
receiving the 8911, just load it and fwd to it.
regards,
bogdan
Padmaja wrote:
Hi all,
I have an issue, where the sip user dials 911 number and hangs up. The
911 operator then calls back to the user using the call back command
provided earlier say 8911 (there is a b2bua that interprets the call back
number and routes the call to the specific user). This number is to be
routed via the openser proxy to the b2bua. However, when the 911 calls
back, proxy treats this number as a username and since there are no
registrations to this 8911 number (though this entry is present at the
proxy, no device has registered with this number), it sends back "404 Not
found". How can this be circumvented?
Thanks,
Padmaja
6156
days inactive
6165
days old
3 comments
2 participants
participants (2)
-
Bogdan-Andrei Iancu -
Padmaja