Hi all,
Can any one tell me if the same running instance of Openser can be configured as a stateful proxy for some user accounts and for some numbers like emergency services, it acts like a stateless proxy, just forwarding the request to the destination?
Thanks, Padmaja ----- Original Message ----- From: users-request@lists.openser.org To: users@lists.openser.org Sent: Saturday, November 03, 2007 10:36 AM Subject: Users Digest, Vol 30, Issue 7
Send Users mailing list submissions to users@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@lists.openser.org
You can reach the person managing the list at users-owner@lists.openser.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..."
Today's Topics:
- proper call tear down (Miles Scruggs)
- gateway aspect of LCR module (Miles Scruggs)
- Re: gateway aspect of LCR module (Ovidiu Sas)
- Re: MediaProxy 1.9.0 - Radius (Jeremy McNamara)
- Reg. conditional processing of invite (Padmaja)
Message: 1 Date: Fri, 2 Nov 2007 14:11:56 -0700 From: Miles Scruggs miles.scruggs@wideideas.com Subject: [OpenSER-Users] proper call tear down To: users@lists.openser.org Message-ID: 10FE258E-087F-4736-9D18-AF367F358C8C@wideideas.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi,
This is probably more SIP related than openSER, but I'll ask it here anyway
When we were at VON I brought up the subject of accounting and verifying proper call tear down, and it seems the ideal solution from a sip perspective is RFC 4028 (SIP session timers) which tracks the actual sip session with the UA. What I'm starting to realize is that support for this is very limited and I haven't found much evidence if any in the devices where network failures are most likely to occur ATAs and end user devices.
This seems to leave me relying on the media stream, but this also has its issues with network issues occurring when calls are placed on hold. Does anyone have any good suggestions for accurate accounting when dealing with end users, or is what I described as good as I'm going to get, until I find some solutions that support 4028?
Cheers
Miles Scruggs Wide Ideas | Operations | miles.scruggs@wideideas.com | 509.525.6522 ext 4880
Message: 2 Date: Fri, 2 Nov 2007 14:15:30 -0700 From: Miles Scruggs miles.scruggs@wideideas.com Subject: [OpenSER-Users] gateway aspect of LCR module To: users@lists.openser.org Message-ID: 7051067C-FB06-43AB-841F-227A7AC5C138@wideideas.com Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Hi guys,
Great to meet many of you this week at VON and looking forward to getting together again soon.
We have a question about the gateway aspect which is part of the LCR module. We are needing to route to various carriers which the module handles great, but we are trying to figure out if there is an elegant way to handle the situation where a carrier provides us with multiple proxies. For instance if carrier A provides proxy1 and proxy2, carrier B etc.... When we get the AVP back which will be our stack to do serial forking the sequence is dependent on the proxy response (or lack of response)
For instance if we get a 400 error back from either proxy there isn't much use in trying the other proxy we need to more along to a completely different carrier. For 500 errors or time outs will continue on using the same carrier. The obvious ways to do this: to abandon the gateway aspect all together and just build logic which we could use to process what would appear to be a multi demential array instead of single diminutional array. I'm just writing to see if there is a nice out of the box way to handle this scenario, also if not, is this something which developers would be interested in having added to the module?
Cheers
Miles Scruggs Wide Ideas | Operations | miles.scruggs@wideideas.com | 509.525.6522 ext 4880
Message: 3 Date: Fri, 2 Nov 2007 19:33:44 -0400 From: "Ovidiu Sas" sip.nslu@gmail.com Subject: Re: [OpenSER-Users] gateway aspect of LCR module To: "Miles Scruggs" miles.scruggs@wideideas.com Cc: users@lists.openser.org Message-ID: 6f497e130711021633r5aa07f69u1d0e5410fd27abef@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1
Hi Miles,
It was nice meeting you at VoN.
With respect to your question, there are a few options. First option would be to mess with the avp. As soon as you get a reply back that should discard the entire gateway group, remove all the remaining gateway (belonging to that particular group) from the avp before calling next_gw(). The second option would be to create a new function: next_gw_group().
This is just the top of my head (so there might be some details that needs to be worked out).
On the other hand, there is a new module called carrierroute: http://www.openser.org/docs/modules/1.3.x/carrierroute.html Check this module out. It may provide some extra flexibility.
Regards, Ovidiu Sas
On 11/2/07, Miles Scruggs miles.scruggs@wideideas.com wrote:
Hi guys,
Great to meet many of you this week at VON and looking forward to getting together again soon.
We have a question about the gateway aspect which is part of the LCR module. We are needing to route to various carriers which the module handles great, but we are trying to figure out if there is an elegant way to handle the situation where a carrier provides us with multiple proxies. For instance if carrier A provides proxy1 and proxy2, carrier B etc.... When we get the AVP back which will be our stack to do serial forking the sequence is dependent on the proxy response (or lack of response)
For instance if we get a 400 error back from either proxy there isn't much use in trying the other proxy we need to more along to a completely different carrier. For 500 errors or time outs will continue on using the same carrier. The obvious ways to do this: to abandon the gateway aspect all together and just build logic which we could use to process what would appear to be a multi demential array instead of single diminutional array. I'm just writing to see if there is a nice out of the box way to handle this scenario, also if not, is this something which developers would be interested in having added to the module?
Cheers
Miles Scruggs Wide Ideas | Operations | miles.scruggs@wideideas.com | 509.525.6522 ext 4880
Users mailing list Users@lists.openser.org http://lists.openser.org/cgi-bin/mailman/listinfo/users
Message: 4 Date: Fri, 02 Nov 2007 22:08:06 -0400 From: Jeremy McNamara jj@nufone.net Subject: Re: [OpenSER-Users] MediaProxy 1.9.0 - Radius To: Brian Heath brian@telethra.com Cc: users@lists.openser.org Message-ID: 472BD806.80506@nufone.net Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Brian Heath wrote:
If you've stopped using MediaProxy, what do you use now? I'mcurrently seeking an alternative to MediaProxy, and would appreciate some ideas. All I need is NAT traversal - but something does doesn't route media (voice) through the OpenSER server...
As I suggested to Mike, use Asterisk. You get full transcoding support, proper call accounting and the ability to do calling applications (ivr, etc) , if you want.
You can fix the NAT problems in the SDP from within openser.cfg.
Jeremy
Message: 5 Date: Sat, 3 Nov 2007 10:37:52 +0530 From: "Padmaja" padmaja.rv@vodcalabs.com Subject: [OpenSER-Users] Reg. conditional processing of invite To: users@lists.openser.org Message-ID: 002201c81dd7$7e32ed20$0f32a8c0@systemtest3 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
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@lists.openser.org To: users@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@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@lists.openser.org
You can reach the person managing the list at users-owner@lists.openser.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..."
Today's Topics:
- Core dumped when deploying presence module (Sergio Gutierrez)
- Re: MediaProxy 1.9.0 - Radius (Brian Heath)
- Re: Forking Madness (Chris Heiser)
- Re: MediaProxy 1.9.0 - Radius (Mike O'Connor)
- Re: MediaProxy 1.9.0 - Radius (Ovidiu Sas)
Message: 1 Date: Fri, 2 Nov 2007 15:59:56 -0500 From: "Sergio Gutierrez" saguti@gmail.com Subject: [OpenSER-Users] Core dumped when deploying presence module To: users@lists.openser.org, users@openser.org Message-ID: 8a4af3e20711021359p3327c719t4ae680de4ac3e155@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:
- Openser 1.2.1
- Solaris 10 on Sparc System
- 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