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
>>
Hello,
I'm wondering if its a good idea to tie dispatcher module with GeoIP.
The point is to select gateway group depending on IP from which user
making a call. In such way you can select the gateway which should be
closed to the user. E.g. some users will use USA gateways another EU or
Asia gateways.
Victor
Hi everybody,
Is it possible for OpenSER to use XML Schema for CPL instead of DTD file ?
It would be more interesting use XLM schema, isn't it?
Thanx
daniel
--
Daniel Grotti
________________________
e-mail : d.grotti(a)gmail.com
Hi Anca
Thank you, it works with pua.so and db parameter for pua included.
Regards
Sebastian
-----Original Message-----
From: Anca Vamanu [mailto:anca@voice-system.ro]
Sent: Tuesday, November 06, 2007 12:11 PM
To: Schumann Sebastian
Cc: users(a)openser.org
Subject: Re: [OpenSER-Users] Presence RLS module: initialization error
Hello,
The bind_libxml_command is from pua modules, that rls depends on. You
must load this also.
There was a miss out in the documentation that is now fixed.
regards,
Anca Vamanu
Schumann Sebastian wrote:
> Dear all
>
> I tried to configure OpenSER as RLS. I have error message using rls
> module. I did setting acc. openser.org module documentation for rls,
> including library functionality of presence and so on.
>
> Trying to start OpenSER, I get the follwing error regarding RLS:
>
> Nov 5 17:29:57 [22819] DBG:core:find_cmd_export_t: <bind_libxml_api>
> not found
> Nov 5 17:29:57 [22819] ERROR:rls:mod_init: can't import
bind_libxml_api
> Nov 5 17:29:57 [22819] ERROR:core:init_mod: failed to initialize
> module rls
> Nov 5 17:29:57 [22819] ERROR:core:main: error while initializing
modules
>
> Can anyone help, where to get bind_libxml_api ?
>
> Thank you.
> Sebastian
>
------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>
Dear all
I tried to configure OpenSER as RLS. I have error message using rls
module. I did setting acc. openser.org module documentation for rls,
including library functionality of presence and so on.
Trying to start OpenSER, I get the follwing error regarding RLS:
Nov 5 17:29:57 [22819] DBG:core:find_cmd_export_t: <bind_libxml_api> not
found
Nov 5 17:29:57 [22819] ERROR:rls:mod_init: can't import bind_libxml_api
Nov 5 17:29:57 [22819] ERROR:core:init_mod: failed to initialize module
rls
Nov 5 17:29:57 [22819] ERROR:core:main: error while initializing modules
Can anyone help, where to get bind_libxml_api ?
Thank you.
Sebastian
Hello,
i'm happy to announce that the 'devel.openser.org' server, sponsored from my
company 1&1 Internet AG, is now available.
This machine hosts services for developers, but some of them are probably also
useful for users:
1. Daily creation of debian builds (etch i386 and amd64) of the trunk for
easily testing.
2. A read only svn mirror of the complete repository for better subversion
performance especially outside the USA.
3. The build and testing framework "buildbot" for continous monitoring of the
status from trunk and branches.
4. Doxygen code documentation with graph generation for better understanding
of the code and module dependencies.
You'll find at http://devel.openser.org/ the indivdual addresses of the
services. This page will probably be moved to www.openser.org after the
migration of these server.
Best regards,
Henning Westerholt
--
Henning Westerholt - Development Consumer Products / DSL Core
1&1 Internet AG, Ernst-Frey-Str. 9, 76135 Karlsruhe, Deutschland
Amtsgericht Montabaur HRB 6484 * Vorstand: Henning Ahlert, Ralph Dommermuth,
Matthias Ehrlich, Andreas Gauger, Thomas Gottschlich, Matthias Greve, Robert
Hoffmann, Norbert Lang, Achim Weiss * Aufsichtsratsvorsitzender: Michael
Scheeren
Hi Bogdan, all,
I've made more digging and I need your opinion on my findings.
Pre-condition: run an AS in forked mode with 2 children.
1. AS sends a request (RQ).
2. AS receives a "408 Request Timeout" reply (RPL) for RQ.
3. After some time (about 30 seconds) AS receives another "408 Request Timeout", initiated at another network node.
4. At this point, you want to send another request from AS.
Result: Very often, the replies for the last request cannot be matched with its transaction in "tm" module, so
request retransmissions occur.
After a few days I've found that in "t_reply_matching" function from "t_lookup.c" file, just before returning
(at the end of the function, not in the case when the reply gets matched) T is set to zero (set_t(0)).
So, at step 3, the reply cannot be matched with an existing transaction and T is set to zero in a child process.
If a reply of the request sent at step 4 gets handled by exactly the child process that last set T to zero, the
transaction will not get matched (see t_check() and reply_received() functions), so the retransmission
timer will hit => request retransmissions!!!
I think the problem is that T is set to zero in t_reply_matching() when a reply cannot be matched.
I've changed that to set_t(T_UNDEFINED) and everything seems to work just fine.
What do you say Bogdan? Is this change safe? Is this the fix for my problem?
Thanks,
Sica.
----- Original Message ----
From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
To: Vasile Zaharia <sicavz(a)yahoo.com>
Cc: users(a)openser.org
Sent: Tuesday, October 30, 2007 9:49:38 AM
Subject: Re: [OpenSER-Users] retransmissions after final response
Salut Sica,
So you say that openser does retransmission even after receiving the
200 OK for the request? are you sure it is about the same transaction?
Could you provide the debug log showing also the retransmission events?
(just send me the entire log).
Salutari,
Bogdan
Vasile Zaharia wrote:
> Salut Bogdan,
>
> Thank you for your response.
> I think the reply is correct, because in the log file I can see:
>
> 2007-10-15 06:28:48.545|t_lookup.c:824|t_reply_matching|DEBUG:
t_reply_matching: reply matched (T=0xb5e98bd8)!\n
> 2007-10-15 06:28:48.545|t_lookup.c:924|t_check|DEBUG: t_check:
end=0xb5e98bd8\n
> 2007-10-15 06:28:48.546|t_hooks.c:203|run_trans_callbacks|DBG:
trans=0xb5e98bd8, callback type 256, id 0 entered\n
> 2007-10-15 06:28:52.754|timer.c:434|wait_handler|DEBUG: wait_handler
: removing 0xb5e98bd8 from table \n
> 2007-10-15 06:28:52.754|timer.c:714|remove_timer_unsafe|DEBUG:
unlinking timer: tl=0xb5e98d54, timeout=364, group=0\n
> 2007-10-15 06:28:52.753|timer.c:239|delete_cell|DEBUG: delete
transaction 0xb5e98bd8\n
> 2007-10-15 06:28:52.753|timer.c:443|wait_handler|DEBUG: wait_handler
: done\n
>
> 2007-10-15 06:29:15.378|t_lookup.c:824|t_reply_matching|DEBUG:
t_reply_matching: reply matched (T=0xb5e98bd8)!\n
> 2007-10-15 06:29:15.378|t_lookup.c:924|t_check|DEBUG: t_check:
end=0xb5e98bd8\n
> 2007-10-15 06:29:15.378|t_hooks.c:203|run_trans_callbacks|DBG:
trans=0xb5e98bd8, callback type 256, id 0 entered\n
> 2007-10-15 06:29:19.871|timer.c:434|wait_handler|DEBUG: wait_handler
: removing 0xb5e98bd8 from table \n
> 2007-10-15 06:29:19.871|timer.c:714|remove_timer_unsafe|DEBUG:
unlinking timer: tl=0xb5e98d54, timeout=391, group=0\n
> 2007-10-15 06:29:19.871|timer.c:239|delete_cell|DEBUG: delete
transaction 0xb5e98bd8\n
> 2007-10-15 06:29:19.871|timer.c:443|wait_handler|DEBUG: wait_handler
: done\n
>
> 2007-10-15 06:29:21.853|t_lookup.c:824|t_reply_matching|DEBUG:
t_reply_matching: reply matched (T=0xb5e98bd8)!\n [22569]
> 2007-10-15 06:29:21.853|t_lookup.c:924|t_check|DEBUG: t_check:
end=0xb5e98bd8\n [22569]
> 2007-10-15 06:29:25.894|timer.c:434|wait_handler|DEBUG: wait_handler
: removing 0xb5e98bd8 from table \n
> 2007-10-15 06:29:25.894|timer.c:714|remove_timer_unsafe|DEBUG:
unlinking timer: tl=0xb5e98d54, timeout=397, group=0\n
> 2007-10-15 06:29:25.894|timer.c:239|delete_cell|DEBUG: delete
transaction 0xb5e98bd8\n
> 2007-10-15 06:29:25.894|timer.c:443|wait_handler|DEBUG: wait_handler
: done\n
>
> 2007-10-15 06:29:50.049|t_lookup.c:824|t_reply_matching|DEBUG:
t_reply_matching: reply matched (T=0xb5e98bd8)!\n
> 2007-10-15 06:29:50.049|t_lookup.c:924|t_check|DEBUG: t_check:
end=0xb5e98bd8\n
> 2007-10-15 06:29:50.051|t_hooks.c:203|run_trans_callbacks|DBG:
trans=0xb5e98bd8, callback type 256, id 0 entered\n
> 2007-10-15 06:29:55.014|timer.c:434|wait_handler|DEBUG: wait_handler
: removing 0xb5e98bd8 from table \n
> 2007-10-15 06:29:55.014|timer.c:714|remove_timer_unsafe|DEBUG:
unlinking timer: tl=0xb5e98d54, timeout=425, group=0\n
> 2007-10-15 06:29:55.014|timer.c:239|delete_cell|DEBUG: delete
transaction 0xb5e98bd8\n
> 2007-10-15 06:29:55.014|timer.c:443|wait_handler|DEBUG: wait_handler
: done\n
>
> 2007-10-15 06:31:45.071|t_lookup.c:824|t_reply_matching|DEBUG:
t_reply_matching: reply matched (T=0xb5e98bd8)!\n
> 2007-10-15 06:31:45.071|t_lookup.c:924|t_check|DEBUG: t_check:
end=0xb5e98bd8\n
> 2007-10-15 06:31:45.071|t_hooks.c:203|run_trans_callbacks|DBG:
trans=0xb5e98bd8, callback type 256, id 0 entered\n
> 2007-10-15 06:31:49.834|timer.c:434|wait_handler|DEBUG: wait_handler
: removing 0xb5e98bd8 from table \n
> 2007-10-15 06:31:49.834|timer.c:714|remove_timer_unsafe|DEBUG:
unlinking timer: tl=0xb5e98d54, timeout=540, group=0\n
> 2007-10-15 06:31:49.834|timer.c:239|delete_cell|DEBUG: delete
transaction 0xb5e98bd8\n
> 2007-10-15 06:31:49.834|timer.c:443|wait_handler|DEBUG: wait_handler
: done\n
>
> Maybe I don't understand it correctly? It's about T=0xb5e98bd8. It
gets matched, removed, deleted. Many times.
>
> The situation was reproduced using 2 different clients: sipp and a
proprietary client (using two opensource libraries: osip and exosip).
>
> What do you think?
>
> Thanks,
> Sica.
>
>
> ----- Original Message ----
> From: Bogdan-Andrei Iancu <bogdan(a)voice-system.ro>
> To: Vasile Zaharia <sicavz(a)yahoo.com>
> Cc: users(a)openser.org
> Sent: Tuesday, October 30, 2007 6:35:10 AM
> Subject: Re: [OpenSER-Users] retransmissions after final response
>
>
> Salut Sica,
>
> The problem may reside in two places:
> 1) the reply is not correct and the client is not able to match
it
> to the sent request (and keeps retransmitting)
> 2) the client is not able to match (due whatever other bugs) the
> reply.
>
> Salutari,
> Bogdan
>
> Vasile Zaharia wrote:
>
>> Hi all,
>>
>>
>> I'm developing a Presence AS OpenSER module (derived from the
OpenSER
>>
> Presence module)
>
>> and, from time to time, it happens the next situation:
>> - AS sends a NOTIFY message
>> - the client receives the NOTIFY and responds with 200 OK
>> - AS receives 200 OK response, but it starts to retransmit the
>>
> original NOTIFY and it
>
>> retransmits it until it gets back a 408 Request timeout.
>>
>> Please note that I use "tm" module for sending SIP messages, so I
>>
> don't
>
>> handle retransmissions explicitly in my module.
>> Also, note that it does not happen all the time, but from time to
>>
> time.
>
>> Does anyone else met a similar situation?
>>
>>
>> Thanks,
>> Sica.
>>
>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>>
>> _______________________________________________
>> Users mailing list
>> Users(a)openser.org
>> http://openser.org/cgi-bin/mailman/listinfo/users
>>
>>
>>
>
>
>
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Trying to send a user's call to their cellphone can be problematic,
especially when their phone is off, bad signal, etc... I know some
carriers send q931 messages back when a call is redirected (sometimes),
but not all do.
Is it possible to make a determination in OpenSER (if we know we're
sending to a cell phone) that the call was picked up too quickly? That's
really the ugly problem. If I could say, "Oh yeah, you're cellphone
picked up in less than 1 second, a real person probably didn't do that."
and drop that fork, that would be awesome.
--Chris
We've been looking recently at RFC 3326 (Reason header fields for SIP)
primarily to help with logging in some of our UAs. While I know that SER
can essentially tack on any header anywhere, I'm wondering if anyone's
come up with a solution for handling something like the Call Completed
Elsewhere reason tag:
Reason: SIP ;cause=200 ;text="Call completed elsewhere"
Essentially, this would be sent in a CANCEL message to all clients that
did NOT pick up the SIP call. Since SER forks off a separate INVITE to
any contact in the location table matching the intended recipient, it
would be nice to fire off a reason for a cancel to some UAs which would
then know not to bother logging a call as 'missed' in the case of
another phone picking it up.
I'm sure there's a way to hack this using the current functionality (or
if not, a slight modification of current functionality), but if anyone's
done it and has a code snippet, that would make life easier.
N.
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...
Thanks,
Brian
----- Original Message -----
From: "Jeremy McNamara" <jj(a)nufone.net>
To: "Mike O'Connor" <mike(a)pineview.net>
Cc: <users(a)lists.openser.org>
Sent: Friday, November 02, 2007 7:30 AM
Subject: Re: [OpenSER-Users] MediaProxy 1.9.0 - Radius
> Mike O'Connor wrote:
>> Hi Guys
>>
>> I really think there is something wrong with MediaProxy, I can not get
>> the radius or the mysql accounting to report any details, as best as I
>> can see there is never any attempt to even try.
>>
>
>
>
> I totally scratched MediaProxy off of the list when the author of the
> code told me to take my questions to the openser mailing list.
> Good luck finding support - I even offered to pay and was completely
> ignored.
>
>
> My suggestion would be to use Asterisk as your media proxy and use one
> of the various radius connectors (if you absolutely require radius)
>
>
>
>
> Jeremy
>
> _______________________________________________
> Users mailing list
> Users(a)lists.openser.org
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
