[Serusers] a question about "cancel"inforwardingscenario
Greger V. Teigre
greger at teigre.com
Thu Feb 16 09:31:24 CET 2006
Yes, and my point is that sending a debug trace from another config with
significant changes is completely worthless in trying to find out what's
wrong with another config. For example by rewriting the uri with ip with no
UA listening automatically changes the scenario (and I won't even mention
your little trick in handling 487s) and WILL generate a timeout. That's
like sending a debug trace from a Cisco 5200 when you have a problem with an
AudioCodes GW...
SER's behavior is not constant, it's controlled by the config file (just
like apache). Making significant changes requires quite some understanding
of SIP, as well as the workings of SER. That's the whole point about the
onsip.org config files, making it easy to get started and as you understand
more you can do more changes.
So, if you want further help, use the vanilla ONsip.org
callfwd-features.cfg, create your test scenario and see if you have the same
problem, add whatever debugging you need, and post the *SIP trace* (ngrep),
as well as the debug output.
g-)
----- Original Message -----
From: "zhangshuai" <zhangshuai at goldentek.biz>
To: "serusers" <serusers at lists.iptel.org>
Sent: Thursday, February 16, 2006 2:58 AM
Subject: Re: Re: Re: Re: Re: [Serusers] a question about
"cancel"inforwardingscenario
> Dear Greger V. Teigre,
>
>
> Take it easy. I really appreciate your spending time to help me figure it
> out. Of course I have tested the onr.cfg, a non-altered version of the
> onsip.org script, for many times. As I said before, the following lines:
>
> #when caller cancel, terminate the call
> if (t_check_status("487")) {
> log("cancel received\n");
> t_reply("487", "Request Terminated");
> break;
> };
>
> in failure_route[1] never took effect in my test, because there is no
> corresponding log in debug info at all! Those lines only work under this
> circumstance: when ua1 calls ua2, ua1 cancels the call before timer hits.
> So, please check the debug info, I sent out last time, again
> to confirm my thought.
>
> Thanks a million.
>
>
>
>>Your INVITE to seturi() to 200@ times out:
>>0(20167) receive_msg: cleaning up
>> 1(20168) DEBUG: timer routine:4,tl=0x422b9e50 next=(nil)
>> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>>INVITE si ... )
>> 1(20168) DEBUG: add_to_tail_of_timer[5]: 0x422b9e50
>> 1(20168) DEBUG: retransmission_handler : done
>> 1(20168) DEBUG: timer routine:5,tl=0x422b9e50 next=(nil)
>> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>>INVITE si ... )
>> 1(20168) DEBUG: add_to_tail_of_timer[6]: 0x422b9e50
>> 1(20168) DEBUG: retransmission_handler : done
>> 1(20168) DEBUG: timer routine:6,tl=0x422b9e50 next=(nil)
>> 1(20168) DEBUG: retransmission_handler : request resending (t=0x422b9d38,
>>INVITE si ... )
>> 1(20168) DEBUG: add_to_tail_of_timer[7]: 0x422b9e50
>> 1(20168) DEBUG: retransmission_handler : done
>> 1(20168) DEBUG: timer routine:0,tl=0x422b9e60 next=(nil)
>> 1(20168) DEBUG: final_response_handler:stop retr. and send CANCEL
>>(0x422b9d38)
>> 1(20168) ->>>>>>>>> T_code=100, new_code=408
>> 1(20168) DEBUG: t_check: msg id=0 global id=0 T start=0x422b9d38
>> 1(20168) DEBUG: t_check: T already found!
>> 1(20168) DEBUG:t_check_status: checked status is <408>
>>
>>then it's forwarded in t_on_failure to 300@
>>
>>The CANCEL is received ok, forwarded ok and the 487 should NOT be met with
>>a
>>t_reply, but just break in t_on_failure!!
>>
>>
>>As you have effectively dealt with the 487, SER only has a 408 left to
>>send
>>back.
>>
>>:-( I told you to use the callfwd script from onsip.org!! But you used
>>your
>>own f... up test script instead, and stupid me spent time on trying to
>>figure it out. Have you tried a non-altered version of the onsip.org
>>script
>>at all?!
>>
>>g-(
>>
>>----- Original Message -----
>>From: "zhangshuai" <zhangshuai at goldentek.biz>
>>To: "serusers" <serusers at lists.iptel.org>
>>Cc: "wuyuan" <wuyuan at goldentek.biz>
>>Sent: Wednesday, February 15, 2006 10:18 AM
>>Subject: Re: Re: Re: Re: [Serusers] a question about "cancel"
>>inforwardingscenario
>>
>>
>>> Dear Greger V. Teigre,
>>>
>>>
>>> Thanks for your suggestion.
>>>
>>> I've reset the fr_inv_timer and debug level, and put some log functions
>>> into ser.cfg:
>>>
>>> # ----------- global configuration parameters ------------------------
>>>
>>> debug=7 # debug level (cmd line: -dddddddddd)
>>> fork=no
>>> log_stderror=yes # (cmd line: -E)
>>>
>>> listen=218.97.252.39
>>> check_via=no # (cmd. line: -v)
>>> dns=no # (cmd. line: -r)
>>> rev_dns=no # (cmd. line: -R)
>>> #port=5060
>>> #children=4
>>> alias=localhost.localdomain
>>> alias=218.97.252.39
>>>
>>> # ------------------ module loading ----------------------------------
>>> loadmodule "/usr/local/lib/ser/modules/sl.so"
>>> loadmodule "/usr/local/lib/ser/modules/tm.so"
>>> # ----------------- setting module-specific parameters ---------------
>>>
>>> # -- tm params --
>>> # set time for which ser will be waiting for a final response;
>>> # fr_inv_timer sets value for INVITE transactions, fr_timer
>>> # for all others
>>> modparam("tm", "fr_inv_timer", 120 )
>>> modparam("tm", "fr_timer", 10 )
>>>
>>> # ------------------------- request routing logic -------------------
>>>
>>> # main routing logic
>>>
>>>
>>> route{
>>> # for testing purposes, simply okay all REGISTERs
>>> if (method=="REGISTER") {
>>> log("REGISTER\n");
>>> sl_send_reply("200", "ok");
>>> break;
>>> };
>>> seturi("sip:200 at 218.97.252.35:5060");
>>> # if we do not get a positive reply, continue at reply_route[1]
>>> log("for test\n");
>>> t_on_failure("1");
>>> # forward the request to all destinations in destination set now
>>> t_relay();
>>> }
>>>
>>> failure_route[1] {
>>> #when caller cancel, terminate the call
>>> if (t_check_status("487")) {
>>> log("cancel received\n");
>>> t_reply("487", "Request Terminated");
>>> break;
>>> };
>>> # forwarding failed -- try again at another destination
>>> append_branch("sip:300 at 218.97.252.44:5060");
>>> log(1,"first redirection\n");
>>> # if this alternative destination fails too, proceed to
>>> reply_route[2]
>>> #t_on_failure("2");
>>> t_relay();
>>> }
>>>
>>> Here is my test:
>>>
>>> When ua1(sip:100 at localhost.localdomain:5060) call
>>> <sip:400 at localhost.localdomain:5060>, SER, at once, rewrites uri and
>>> sends
>>> invite to ua2(sip:200 at 218.97.252.35:5060). But because ua2 is offline,
>>> SER
>>> forwards the invite to ua3(sip:300 at 218.97.252.44:5060) and then ua3
>>> begins
>>> ringing. Now, ua1 sends cancel to SER, SER sends cancel to ua3. ua3
>>> returns "487" to SER and SER sends "408" to ua1. I don't know whether
>>> the
>>> timers were reset properly before forwarding.
>>>
>>> And with the attachment is the ser debug info. Please have a look.
>>>
>>> Thanks again.
>>>
>>>>I think you need to make an ngrep SIP trace of the two scenarios. SER
>>>>will
>>>>not generate a 408 unless the timer hits. Increase the timer (it will be
>>>>easier to see what happens). You use a very low timer value
>>>>(fr_inv_timer=15). Set it to 120. Then look for the CANCEL from ua3.
>>>>Does
>>>>SER receive the CANCEL and process it (use debug mode 7)?
>>>>I'm not sure if this is the same as mentioned in the bug referred to in
>>>>another reply, but let's try to find out.
>>>>Please post the ngrep trace for the two scenarios.
>>>>g-)
>>>>
>>>>----- Original Message -----
>>>>From: "zhangshuai" <zhangshuai at goldentek.biz>
>>>>To: "serusers" <serusers at lists.iptel.org>
>>>>Cc: "wuyuan" <wuyuan at goldentek.biz>
>>>>Sent: Tuesday, February 14, 2006 9:41 AM
>>>>Subject: Re: Re: Re: [Serusers] a question about "cancel" in
>>>>forwardingscenario
>>>>
>>>>
>>>>> Dear Greger V. Teigre,
>>>>>
>>>>>
>>>>> I've tried t_on_failure("2").
>>>>>
>>>>> failure_route[2] {
>>>>> #when caller cancel, terminate the call
>>>>> if (t_check_status("487")) {
>>>>> log(1,"cancel received\n");
>>>>> t_reply("487", "Request Terminated");
>>>>> break;
>>>>> }
>>>>> }
>>>>>
>>>>> There are similar lines in failure_route[1]. When ua2 is ringing and
>>>>> ua1
>>>>> cancel the call, the value of "t_check_status("487")" in
>>>>> failure_route[1]
>>>>> will be true. However, When ua3 is ringing and ua1 cancel the call,
>>>>> the
>>>>> value of "t_check_status("487")" in failure_route[2] will be false.
>>>>> This
>>>>> time, t_check_status() returns "408". I don't know why SER generates
>>>>> "408"
>>>>> under this circumstance. My ser's version is 0.9.3 and I just run
>>>>> update_from_cvs. And I found similar description here:
>>>>> http://bugs.sip-router.org/browse/SER-63
>>>>> Is it an unsolved problem?
>>>>>
>>>>>
>>>>>>Do some logging, what happens in the failure route? To me, it looks
>>>>>>like
>>>>>>your config appends a branch. BTW, run update_from_cvs in your SER
>>>>>>source
>>>>>>dir top make sure you get the latest bug fixes!
>>>>>>g-)
>>>>>>
>>>>>>----- Original Message -----
>>>>>>From: "zhangshuai" <zhangshuai at goldentek.biz>
>>>>>>To: "serusers" <serusers at lists.iptel.org>
>>>>>>Cc: "wuyuan" <wuyuan at goldentek.biz>
>>>>>>Sent: Tuesday, February 14, 2006 3:49 AM
>>>>>>Subject: Re: Re: [Serusers] a question about "cancel" in forwarding
>>>>>>scenario
>>>>>>
>>>>>>
>>>>>>> Dear Greger V. Teigre,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Thanks for your quick reply.
>>>>>>>
>>>>>>> I have read the sergettingstarted05.pdf (Based upon SER version
>>>>>>> 0.9.3)
>>>>>>> and
>>>>>>> tested the onr.cfg in
>>>>>>> ser-0.9.3.GettingStarted.1.3.tar.gz/ser-0.9.3/examples many times.
>>>>>>> SER
>>>>>>> sent out "408" to caller immediately after received "486" from ua3.
>>>>>>> I
>>>>>>> don't know how does ser's failure route deal with this kind of
>>>>>>> "cancel"
>>>>>>> when the invite has been forwarded. Any ideas will help me a lot.
>>>>>>> Thanks!
>>>>>>>
>>>>>>> Here is the onr.cfg:
>>>>>>>
>>>>>>> # ------------------ module
>>>>>>> loading ----------------------------------
>>>>>>> loadmodule "/usr/local/lib/ser/modules/sl.so"
>>>>>>> loadmodule "/usr/local/lib/ser/modules/tm.so"
>>>>>>> # ----------------- setting module-specific
>>>>>>> parameters ---------------
>>>>>>>
>>>>>>> # -- tm params --
>>>>>>> # set time for which ser will be waiting for a final response;
>>>>>>> # fr_inv_timer sets value for INVITE transactions, fr_timer
>>>>>>> # for all others
>>>>>>> modparam("tm", "fr_inv_timer", 15 )
>>>>>>> modparam("tm", "fr_timer", 10 )
>>>>>>>
>>>>>>> # ------------------------- request routing
>>>>>>> logic -------------------
>>>>>>>
>>>>>>> # main routing logic
>>>>>>>
>>>>>>> route{
>>>>>>> # for testing purposes, simply okay all REGISTERs
>>>>>>> if (method=="REGISTER") {
>>>>>>> log("REGISTER");
>>>>>>> sl_send_reply("200", "ok");
>>>>>>> break;
>>>>>>> };
>>>>>>> # try these two destinations first in parallel; the second
>>>>>>> # destination is targeted to sink port -- that will make ser
>>>>>>> # wait until timer hits
>>>>>>> seturi("sip:200 at 218.97.252.35:5060");
>>>>>>> #append_branch("sip:300 at 218.97.252.36:5060");
>>>>>>> # if we do not get a positive reply, continue at
>>>>>>> reply_route[1]
>>>>>>> t_on_failure("1");
>>>>>>> # forward the request to all destinations in destination set
>>>>>>> now
>>>>>>> t_relay();
>>>>>>> }
>>>>>>>
>>>>>>> failure_route[1] {
>>>>>>> #when caller cancel, terminate the call
>>>>>>> if (t_check_status("487")) {
>>>>>>> t_reply("487", "Request Terminated");
>>>>>>> break;
>>>>>>> };
>>>>>>> # forwarding failed -- try again at another destination
>>>>>>> append_branch("sip:300 at 218.97.252.44:5060");
>>>>>>> log(1,"first redirection\n");
>>>>>>> # if this alternative destination fails too, proceed to
>>>>>>> reply_route[2]
>>>>>>> #t_on_failure("2");
>>>>>>> t_relay();
>>>>>>> }
>>>>>>>
>>>>>>>
>>>>>>> Thanks in advance.
>>>>>>>
>>>>>>> Have a good day!
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Shuai
>>>>>>>
>>>>>>>
>>>>>>>>The internal SER timer hits and the request times out (the request
>>>>>>>>is
>>>>>>>>not
>>>>>>>>terminated).
>>>>>>>>See SER-GettingStarted doc at ONsip.org for a full example of call
>>>>>>>>features
>>>>>>>>like forwarding.
>>>>>>>>g-)
>>>>>>>>----- Original Message -----
>>>>>>>>From: "zhangshuai" <zhangshuai at goldentek.biz>
>>>>>>>>To: "serusers" <serusers at lists.iptel.org>
>>>>>>>>Cc: "wuyuan" <wuyuan at goldentek.biz>
>>>>>>>>Sent: Friday, February 10, 2006 11:18 AM
>>>>>>>>Subject: [Serusers] a question about "cancel" in forwarding scenario
>>>>>>>>
>>>>>>>>
>>>>>>>>> Dear All,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I want to make use of avpops module to achieve forward
>>>>>>>>> on-no-reply.
>>>>>>>>> When
>>>>>>>>> ua1 calls ua2 and ua2 is off-line, or busy, or doesn't answer the
>>>>>>>>> phone,
>>>>>>>>> the invite should be forwarded to ua3 and ua3 begins ringing.
>>>>>>>>>
>>>>>>>>> In my tests, first, ua1 sends "cancel" when ua2 is ringing. Ua1
>>>>>>>>> receives
>>>>>>>>> "487 Request Terminated" from SER. Second, ua1 sends "cancel" when
>>>>>>>>> ua3
>>>>>>>>> is
>>>>>>>>> ringing. So, theoretically, ua1 should receive "487 Request
>>>>>>>>> Terminated"
>>>>>>>>> after "200 canceling" from SER, right? But, ua1 received "408
>>>>>>>>> Request
>>>>>>>>> Timeout" instead. So strange. How come?
>>>>>>>>>
>>>>>>>>> I think something is wrong with my ser.cfg. Could anyone help me
>>>>>>>>> about
>>>>>>>>> this? Thanks in advance.
>>>>>>>>>
>>>>>>>>> Here is my ser.cfg:
>>>>>>>>>
>>>>>>>>> # ------------------ module
>>>>>>>>> loading ----------------------------------
>>>>>>>>>
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/sl.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/tm.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/rr.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/maxfwd.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/usrloc.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/registrar.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/textops.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/avp.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/acc.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/mysql.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/dbtext.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/avpops.so"
>>>>>>>>> #loadmodule "/usr/local/lib/ser/modules/postgres.so"
>>>>>>>>> #loadmodule "/usr/local/lib/ser/modules/flatstore.so"
>>>>>>>>>
>>>>>>>>> # Uncomment this if you want digest authentication
>>>>>>>>> # mysql.so must be loaded !
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/auth.so"
>>>>>>>>> #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
>>>>>>>>>
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/auth_radius.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/group_radius.so"
>>>>>>>>> loadmodule "/usr/local/lib/ser/modules/uri_radius.so"
>>>>>>>>> # ----------------- setting module-specific
>>>>>>>>> parameters ---------------
>>>>>>>>>
>>>>>>>>> # -- usrloc params --
>>>>>>>>>
>>>>>>>>> #modparam("usrloc", "db_mode", 0)
>>>>>>>>>
>>>>>>>>> # Uncomment this if you want to use SQL database
>>>>>>>>> # for persistent storage and comment the previous line
>>>>>>>>> modparam("usrloc", "db_mode", 1)
>>>>>>>>>
>>>>>>>>> # -- auth params --
>>>>>>>>> # Uncomment if you are using auth module
>>>>>>>>> #
>>>>>>>>> #modparam("auth_db", "calculate_ha1", yes)
>>>>>>>>> #
>>>>>>>>> # If you set "calculate_ha1" parameter to yes (which true in this
>>>>>>>>> config),
>>>>>>>>> # uncomment also the following parameter)
>>>>>>>>> #
>>>>>>>>> #modparam("auth_db", "password_column", "password")
>>>>>>>>>
>>>>>>>>> # -- rr params --
>>>>>>>>> # add value to ;lr param to make some broken UAs happy
>>>>>>>>>
>>>>>>>>> modparam("rr", "enable_full_lr", 1)
>>>>>>>>> modparam("tm", "fr_timer", 10 )
>>>>>>>>> modparam("tm", "fr_inv_timer", 20)
>>>>>>>>> modparam("tm", "noisy_ctimer", 1)
>>>>>>>>>
>>>>>>>>> modparam("auth_radius|uri_radius|group_radius", "radius_config",
>>>>>>>>> "/usr/local/etc/radiusclient-ng/radiusclient.conf")
>>>>>>>>>
>>>>>>>>> modparam("avpops","avp_url","mysql://ser:heslo@localhost/ser")
>>>>>>>>> modparam("avpops","avp_table","usr_preferences")
>>>>>>>>> # ------------------------- request routing
>>>>>>>>> logic -------------------
>>>>>>>>>
>>>>>>>>> # main routing logic
>>>>>>>>>
>>>>>>>>> route{
>>>>>>>>> # initial sanity checks -- messages with
>>>>>>>>> # max_forwards==0, or excessively long requests
>>>>>>>>> if (!mf_process_maxfwd_header("10")) {
>>>>>>>>> sl_send_reply("483","Too Many Hops");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>> if (msg:len >= 2048 ) {
>>>>>>>>> sl_send_reply("513", "Message too big");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> if (!method=="REGISTER") record_route();
>>>>>>>>>
>>>>>>>>> if (loose_route()) {
>>>>>>>>> t_relay();
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> if (method=="INVITE") {
>>>>>>>>> lookup("location");
>>>>>>>>> #if (!lookup("location")) {
>>>>>>>>> # sl_send_reply("404", "Not Found");
>>>>>>>>> # break;
>>>>>>>>> #};
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> if (method=="REGISTER") {
>>>>>>>>> log("REGISTER\n");
>>>>>>>>> if (!radius_www_authorize("localhost.localdomain"))
>>>>>>>>> {
>>>>>>>>> www_challenge("localhost.localdomain",
>>>>>>>>> "0");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>> save("location");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> if (method=="INVITE") {
>>>>>>>>> if
>>>>>>>>> (!radius_proxy_authorize("localhost.localdomain"))
>>>>>>>>> {
>>>>>>>>> proxy_challenge("localhost.localdomain",
>>>>>>>>> "1");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> # if we do not get a positive reply, continue at
>>>>>>>>> failure_route[1]
>>>>>>>>> t_on_failure("1");
>>>>>>>>> # forward the request to all destinations in destination set
>>>>>>>>> now
>>>>>>>>> t_relay();
>>>>>>>>>
>>>>>>>>> #if (!t_relay()) {
>>>>>>>>> # sl_reply_error();
>>>>>>>>> #};
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>> failure_route[1] {
>>>>>>>>>
>>>>>>>>> #when caller cancel, terminate the call
>>>>>>>>> if (t_check_status("487")) {
>>>>>>>>> t_reply("487", "Request Terminated");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>>
>>>>>>>>> if ( ( avp_db_load("$ruri","s:redirect_on_failure") &&
>>>>>>>>> avp_check("redirect_on_failure","eq/i:1"))) {
>>>>>>>>> # User need to forward
>>>>>>>>> log(1, "User wants redirection.\n");
>>>>>>>>> if ( ( avp_db_load("$ruri","s:redirectnumber") &&
>>>>>>>>> !avp_check("redirectnumber","re/^$"))) {
>>>>>>>>> log(1,"first redirect\n");
>>>>>>>>> #avp_print();
>>>>>>>>> attr2uri("redirect number");
>>>>>>>>> lookup("location");
>>>>>>>>> append_branch();
>>>>>>>>> #t_on_failure("2");
>>>>>>>>> t_relay();
>>>>>>>>> }
>>>>>>>>> else {
>>>>>>>>> t_reply("408", "TimeOut");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>> }
>>>>>>>>> else {
>>>>>>>>> t_reply("404", "Not Found");
>>>>>>>>> break;
>>>>>>>>> };
>>>>>>>>> }
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> Serusers mailing list
>>>>>>>>> serusers at lists.iptel.org
>>>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> = = = = = = = = = = = = = = = = = = = =
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Serusers mailing list
>>>>>>> serusers at lists.iptel.org
>>>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> = = = = = = = = = = = = = = = = = = = =
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Serusers mailing list
>>>>> serusers at lists.iptel.org
>>>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>>>
>>>>
>>>>
>>>
>>> = = = = = = = = = = = = = = = = = = = =
>>>
>>>
>>>
>>
>>
>>--------------------------------------------------------------------------------
>>
>>
>>> _______________________________________________
>>> Serusers mailing list
>>> serusers at lists.iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>>
>>
>>
>
> = = = = = = = = = = = = = = = = = = = =
>
>
>
>
>
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
>
More information about the sr-users
mailing list