3 Nov
2007
3 Nov
'07
8:30 a.m.
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(a)lists.openser.org>
To: <users(a)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(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. proper call tear down (Miles Scruggs)
> 2. gateway aspect of LCR module (Miles Scruggs)
> 3. Re: gateway aspect of LCR module (Ovidiu Sas)
> 4. Re: MediaProxy 1.9.0 - Radius (Jeremy McNamara)
> 5. Reg. conditional processing of invite (Padmaja)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 2 Nov 2007 14:11:56 -0700
> From: Miles Scruggs <miles.scruggs(a)wideideas.com>
> Subject: [OpenSER-Users] proper call tear down
> To: users(a)lists.openser.org
> Message-ID: <10FE258E-087F-4736-9D18-AF367F358C8C(a)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(a)wideideas.com | 509.525.6522
> ext 4880
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 2 Nov 2007 14:15:30 -0700
> From: Miles Scruggs <miles.scruggs(a)wideideas.com>
> Subject: [OpenSER-Users] gateway aspect of LCR module
> To: users(a)lists.openser.org
> Message-ID: <7051067C-FB06-43AB-841F-227A7AC5C138(a)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(a)wideideas.com | 509.525.6522
> ext 4880
>
>
>
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 2 Nov 2007 19:33:44 -0400
> From: "Ovidiu Sas" <sip.nslu(a)gmail.com>
> Subject: Re: [OpenSER-Users] gateway aspect of LCR module
> To: "Miles Scruggs" <miles.scruggs(a)wideideas.com>
> Cc: users(a)lists.openser.org
> Message-ID:
> <6f497e130711021633r5aa07f69u1d0e5410fd27abef(a)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(a)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(a)wideideas.com | 509.525.6522
>> ext 4880
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)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(a)nufone.net>
> Subject: Re: [OpenSER-Users] MediaProxy 1.9.0 - Radius
> To: Brian Heath <brian(a)telethra.com>
> Cc: users(a)lists.openser.org
> Message-ID: <472BD806.80506(a)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'm
>> currently
>> 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(a)vodcalabs.com>
> Subject: [OpenSER-Users] Reg. conditional processing of invite
> To: <users(a)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(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
>>