sr-users August 2009

sr-users@lists.kamailio.org

55 participants
77 discussions

by BERGANZ François

Hello, In a SIP Frame, how to see if it is a T38 frame? Thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

14 years, 8 months

[Serusers] SER with a PSTN Gateway (pstn, cfg) vs called-party-BYE or Re-INVITE

by Frank Durda IV

I have noted that the pstn.cfg example (or anything built from its premise) doesn't work right for one very important situation, that hopefully someone has already discovered and has a good fix for. The documentation isn't helping. The situation: I have a call initiated by some SIP client, with the INVITE passing through SER and sent on to a PSTN gateway (the SIP to SS7/ISUP conversion occurs there). The call is in progress (post 200 OK) and both parties are chatting away. So far, so good. The problem: Trouble begins when the called-party (somewhere on the PSTN) hangs up first. What happens: This event triggers a SS7 REL message, and the SIP/SS7 switch providing the VOIP gateway service emits a BYE message, which gets sent to SER. SER receives the message and doesn't treat it as a reply (because it isn't), but instead it comes in the door at route {}. The pstn.cfg-like script quickly determines that this BYE message is coming from the gateway (correct) and skips all the authentication checks (good), and does a rewritehostport() using the PSTN gateway IP address (bad), and finally does a t_relay() (very bad). The BYE is now emitted by SER and sent back to the PSTN gateway switch, rather than on to wherever the INVITE originally came from, the device that needs to know about this BYE. This quickly degenerates into a small battle between PSTN gateway switch and SER, as the PSTN gateway isn't getting the answer back it is expecting in response to the BYE it sent to SER, and the PSTN gateway certainly doesn't want to see the message it just sent out come back over and over. Eventually various looping checks or timers kick in and the argument ends, but the calling system remains in the dark over the fact that the call is now over (other than getting a lot of silence). So that behavior is obviously wrong, but that's what the stock copy of pstn.cfg does here. SER obviously wants to be involved, because it added a Record-Route, but the script really isn't able to deal with the consequences. If the calling network was all SIP this would be merely annoying, but if it is another ISUP network (with a SIP leg in the middle), the originating ISUP legs of the call just rack up the toll charges, unaware that the other legs of the call are gone. Bad things also happen if the original INVITE included a Session-Expires: header, which causes the PSTN gateway to emit its own INVITE back to the calling network (via the SER) at intervals during the call, starting at 50% of the time specified in that header. These packets also die a horrible fate in the PSTN-Gateway and SER packet loop, which causes the call to collapse 32 seconds later. (That's unbelieveably bad.) Recognizing this apparent-shortcoming in the pstn.cfg example, and using the fact that the script could determine that this called-party-BYE or INVITE message came from the PSTN gateway and not somewhere else, I added tests to not perform the rewritehost that sends the message back to the gateway, but instead sets the address to that of the known place where the INVITE originally came from, because in this super simple example, there is only one place, eg phone-asterisk-SER-PSTN-SS7network-... Forcing BYE/INVITEs coming from the PSTN direction sort of fixes the problem of called-party BYEs, and the PSTN gateway device emitting re-INVITEs. However, it only works for ONE source, which is lousy as you have to hard-code the right place for the call in both directions! And of course, someone has too many calls for their one SBC (aka an asterisk box) and they have more than one now. In fact, many more, and any of them can send me the same range of calls from the same sources and to the same PSTN gateway. And it would be really nice if I sent the called-party-BYE or re-INVITEs back to the right SBC. But how? An examination of the numerous variables that SER has (as viewed via xlog() when the called-party-BYE or called-network-reINVITE comes in) shows that SER actually has the right IP address available that the called-party-BYE or re-INVITE should be sent back to (apparently saved as part of the transaction details from the original INVITE), but I can't figure out how to reference this value in "rewritehost()". Like most SER functions, rewritehost() doesn't appear to accept variable names as parameters, and as xlog uses cryptic abbreviations for what it displays, I probably wouldn't know what variable name to specify in rewritehost() anyway. (Did two different programmers do these parts?) Now, if you don't use "rewritehost()" in the send-back-to-caller direction and are hoping that SER will do the right thing on its own, you will be disappointed. The t_relay() merely sends the message back itself and you get a much smaller SIP message loop going. (This is because SER puts its IP address all over the original INVITE message so that the PSTN gateway would talk to SER rather than the true source of the call.) So that appears to means that you must set rewritehost() to a reasonable destination to get the message to move beyond SER, and somehow I have to choose a destination from many possible destinations the original INVITE came from, based on some piece of trivia that was in the original INVITE that I can somehow trigger on. That means if there are 250 different SBCs out there sending me calls, and one of them was where the original INVITE came from for the call I just got a called-party-BYE from, how do I force that called-party-BYE (or a called-network re-INVITE) to go back to the right place? Must I build a giant if statement that tests the addresses of all 250 sources and leaves a flag or something that can be used in 250 if statements later when the called-party-BYE or called-network-reINVITE shows up? Sounds horrible and a giant kludge! Any other solutions? Thanks in advance for thinking about this one!

14 years, 8 months

[Serusers] Is there any way to validate the RTP/media address?

by Frank Durda IV

I am receiving INVITEs from a specific source, and I have a need to test the media IP address specified in the SDP payload against a list of approved netblocks. I'd like to catch this in the INVITE and reject the call if a RTP address in the SDP payload is out of a pre-defined range for that given source. Is there a way to get this address into a variable that can be used in "if" statements? As in something like this? if (src_ip==17.18.19.20 && method=="INVITE") { if (rtp_addr!=17.0.0.0/8) { sl_reply("502", "Rejected - Unauthorized RTP source"); drop; } } with rtp_addr being the made-up, hope-something-like-it-exists thing. Thanks in advance.

14 years, 8 months

[Kamailio-Users] Kamailio installed on other dir issues

by Uriel Rozenbaum

Guys, I've installed all Kamailio in /opt/kamailio. When I execute some kamctl using cr module I get the following: /opt/kamailio/sbin/kamctl cr reload ERROR: This command requires a database engine - none was loaded Do I have to configure something? If i just run /opt/kamailio/sbin/kamctl I get the help lines and running /opt/kamailio/sbin/kamctl fifo cr_reload_routes makes effect as well. Thanks! Uriel

14 years, 8 months

[Serusers] new_t: out of mem

by Roger Tan

hi. I tested my ser server which version is 0.9.7+cvs20080424 used sipps sending 1000 invite per sec. after about 10 sec, there was an out of mem error. Aug 18 09:40:12 ubuntu /sbin/ser[20805]: ERROR: new_t: out of mem: Aug 18 09:40:12 ubuntu /sbin/ser[20805]: ERROR: t_newtran: new_t failed Aug 18 09:40:12 ubuntu /sbin/ser[20805]: ERROR: sl_reply_error used: I'm terribly sorry, server error occurred (1/SL) Aug 18 09:40:12 ubuntu /sbin/ser[20805]: ERROR: sip_msg_cloner: cannot allocate memory and my memlog is: Aug 18 10:11:02 ubuntu /sbin/ser[20787]: ----------------------------- Aug 18 10:11:02 ubuntu /sbin/ser[20787]: Memory status (shm): Aug 18 10:11:02 ubuntu /sbin/ser[20787]: qm_status (0xb5acf000): Aug 18 10:11:02 ubuntu /sbin/ser[20787]: heap size= 33554432 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: used= 1914592, used+overhead=2224736, free=31329696 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: max used (+overhead)= 33534720 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: dumping all alloc'ed. fragments: Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 0. N address=0xb5ad41a8 frag=0xb5ad41a0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 1. N address=0xb5ad41c8 frag=0xb5ad41c0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 2. N address=0xb5ad41e8 frag=0xb5ad41e0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 3. N address=0xb5ad4208 frag=0xb5ad4200 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 4. N address=0xb5ad4228 frag=0xb5ad4220 size=4096 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 5. N address=0xb5ad5238 frag=0xb5ad5230 size=4096 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 6. N address=0xb5ad6248 frag=0xb5ad6240 size=2800 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 7. N address=0xb5ad6d48 frag=0xb5ad6d40 size=1680 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 8. N address=0xb5ad73e8 frag=0xb5ad73e0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 9. N address=0xb5ad7408 frag=0xb5ad7400 size=1572864 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 10. N address=0xb5c57418 frag=0xb5c57410 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 11. N address=0xb5c57438 frag=0xb5c57430 size=320 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 12. N address=0xb5c57588 frag=0xb5c57580 size=48 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 13. N address=0xb5c575c8 frag=0xb5c575c0 size=80 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 14. N address=0xb5c57628 frag=0xb5c57620 size=80 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 15. N address=0xb5c57688 frag=0xb5c57680 size=80 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 16. N address=0xb5c576e8 frag=0xb5c576e0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 17. N address=0xb5c57708 frag=0xb5c57700 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 18. N address=0xb5c57728 frag=0xb5c57720 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 19. N address=0xb5c57748 frag=0xb5c57740 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 20. N address=0xb5c57768 frag=0xb5c57760 size=32 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 21. N address=0xb5c57798 frag=0xb5c57790 size=131072 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 22. N address=0xb5c777a8 frag=0xb5c777a0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 23. N address=0xb5c777c8 frag=0xb5c777c0 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 24. N address=0xb5c777e8 frag=0xb5c777e0 size=32 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 25. N address=0xb5c77818 frag=0xb5c77810 size=131072 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 60. N address=0xb5ca7948 frag=0xb5ca7940 size=48 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 61. N address=0xb5ca7988 frag=0xb5ca7980 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 62. N address=0xb5ca79a8 frag=0xb5ca79a0 size=80 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 63. N address=0xb5ca7a08 frag=0xb5ca7a00 size=48 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 64. N address=0xb5ca7a48 frag=0xb5ca7a40 size=32 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 65. N address=0xb5ca7a78 frag=0xb5ca7a70 size=16 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: 66. N address=0xb5ca7a98 frag=0xb5ca7a90 size=65808 used=1 Aug 18 10:11:02 ubuntu /sbin/ser[20787]: dumping free list stats : Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 1. fragments no.: 1232, unused: 0 ^I^I bucket size: 16 - 16 (first 16) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 38. fragments no.: 54, unused: 0 ^I^I bucket size: 608 - 608 (first 608) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 43. fragments no.: 54, unused: 0 ^I^I bucket size: 688 - 688 (first 688) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 44. fragments no.: 3991, unused: 0 ^I^I bucket size: 704 - 704 (first 704) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 57. fragments no.: 114, unused: 0 ^I^I bucket size: 912 - 912 (first 912) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 58. fragments no.: 4004, unused: 0 ^I^I bucket size: 928 - 928 (first 928) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 68. fragments no.: 46, unused: 0 ^I^I bucket size: 1088 - 1088 (first 1088) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 82. fragments no.: 109, unused: 0 ^I^I bucket size: 1312 - 1312 (first 1312) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 115. fragments no.: 34, unused: 0 ^I^I bucket size: 1840 - 1840 (first 1840) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 174. fragments no.: 3795, unused: 0 ^I^I bucket size: 2784 - 2784 (first 2784) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 186. fragments no.: 790, unused: 0 ^I^I bucket size: 2976 - 2976 (first 2976) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 187. fragments no.: 3820, unused: 0 ^I^I bucket size: 2992 - 2992 (first 2992) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 262. fragments no.: 1, unused: 0 ^I^I bucket size: 4192 - 4192 (first 4192) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: hash= 318. fragments no.: 1, unused: 0 ^I^I bucket size: 5088 - 5088 (first 5088) Aug 18 10:11:02 ubuntu /sbin/ser[20787]: ----------------------------- I think it's not a memory leak but the so many small memory fragments, and those fragments were not combinated. How I solve this problem? Thanks. -- MSN: miao__tan(a)hotmail.com Email: m.roger.t(a)gmail.com

14 years, 8 months

[Serusers] tcpconn_new: mem. allocation failure

by Roger Tan

Hi:

14 years, 8 months

[Kamailio-Users] Generating SIP /TLS Certificate

by Meftah Tayeb

hello all please how i can generate a certificate to do sip / tls? and how to configure my kamailio? try to help me please thanks __________ Information from ESET NOD32 Antivirus, version of virus signature database 4341 (20090817) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com

14 years, 8 months

Re: [Kamailio-Users] presence_dialoginfo context

by David

Hey, I definitely have an exit(), but even if I didn't most of the message is changed, an exit would not change that would it? David Klaus Darilion wrote: > Very strange. > > Maybe exit(); is missing after t_relay() loop and both PUBLISHs are > processed? I think I forgot the exit() in the config snippet. > > Yes, on the server. And please attach the trace as attachment - inline > is difficult to read > > klaus > > David schrieb: >> Hey, >> >> Here is an expert from the /var/log/messsages : >> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: New request - >> M=PUBLISH RURI=sip:group1.105@mydomain.tld >> F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld >> IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: Publish >> rewritten forwarded for ext=group1.105 >> ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml >> version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" >> entity="sip:group1.105@mydomain.tld"> <dialog >> id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> local-tag="4fbrxu9548" remote-tag="as4fb63283" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target >> uri="sip:103@mydomain.tld"/> </remote> <local> >> <identity>sip:group1.105@mydomain.tld</identity> <target >> uri="sip:group1.105@mydomain.tld"/> </local> </dialog> >> </dialog-info> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: New request - >> M=PUBLISH RURI=sip:group1.105@mydomain.tld >> F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld >> IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: Publish >> accepted for ext=group1.105 ruri=sip:group1.105@mydomain.tld >> duri=<null> body=<?xml version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" >> entity="sip:105@mydomain.tld"> <dialog >> id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" >> local-tag="4fbrxu9548" remote-tag="as4fb63283" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target >> uri="sip:103@mydomain.tld"/> </remote> <local> >> <identity>sip:105@mydomain.tld</identity> <target >> uri="sip:105@mydomain.tld"/> </local> </dialog> </dialog-info> >> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: >> INFO:presence:send_notify_request: NOTIFY sip:group1.101@mydomain.tld >> via sip:group1.101@phone.ip:57234 on behalf of sip:105@mydomain.tld >> for event dialog >> >> But the phone's syslog shows this : >> >> Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 >> Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 >> Aug 14 10:16:21 linksys NOTIFY sip:group1.101@phone.ip:57234 >> SIP/2.0^M Via: SIP/2.0/UDP >> 72.55.182.125;branch=z9hG4bK0b0a.9725e23.0^M To: >> sip:group1.101@mydomain.tld;tag=1c32db3af4d889ac^M From: >> sip:105@mydomain.tld;tag=6d6077e15fecee48b2721a5e94bf8883-91a8^M >> CSeq: 12 NOTIFY^M Call-ID: 984d4cd2-37b04f4(a)192.168.1.104^M >> Content-Length: 655^M User-Agent: Kamailio (1.5.2-tls (i386/linux))^M >> Max-Forwards: 70^M Event: dialog^M Contact: <sip:mydomain.tld:5060>^M >> Subscription-State: active;expires=1470^M Content-Type: >> application/dialog-info+xml^M ^M <?xml version="1.0"?> <dialog-info >> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" >> state="full" entity="group1.105(a)mydomain.tld"> <dialog >> id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" >> call-id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" >> local-tag="loto7h3i9a" remote-tag="as4f284f05" >> direction="recipient"> <state>early</state> <remote> >> <identity>sip:103@mydomain.tld</identity> <target uri=" >> >> Everything is good, but notice the entity is somehow back to group1.105. >> >> Where do you want me to run the traceroute? On the server? >> >> David >> >> Klaus Darilion wrote: >>> >>> >>> David schrieb: >>>> Hey, >>>> >>>> I tried that, but it did not seem to change anything. I saw the >>>> message change on the second loop, but it seems that the presence >>>> module figure out my tactic and fixed the message. >>> >>> That's not possible. The presence module does not alter the received >>> body. I think the problem is somewhere else. >>> >>> Can you send me a trace? >>> >>> ngrep -t -P "" -W byline -d any port 5060 >>> >>> regards >>> klaus >>> >>> >>>> >>>> David >>>> >>>> Klaus Darilion wrote: >>>>> That does not work: presence_server always uses the original >>>>> received body, the modifications applied by you are not seen by >>>>> the presence server. >>>>> >>>>> The workaround would be to "loop" the modified PUBLISH to Kamailio >>>>> again, e.g.: >>>>> >>>>> listen=.......:5060 >>>>> listen=.......:5050 >>>>> >>>>> route{ >>>>> ... >>>>> if (is_method("PUBLISH")) { >>>>> if (dst_port==5060) { >>>>> subst_body('/group1[.]//'); >>>>> t_relay("udp:127.0.0.1:5050); >>>>> } else if (dst_port==5050) { >>>>> handle_publish(); >>>>> t_release(); >>>>> } >>>>> } >>>>> ... >>>>> } >>>>> >>>>> >>>>> klaus >>>>> David schrieb: >>>>>> Hey, >>>>>> >>>>>> I tried doing a subst or replace_body_all to change the entity="" >>>>>> value, >>>>>> >>>>>> if (is_method("PUBLISH") ) >>>>>> { >>>>>> subst_body('/group1[.]//'); >>>>>> handle_publish(); >>>>>> t_release(); >>>>>> } >>>>>> >>>>>> It did not work, the $rb variable still shows the old body and >>>>>> the NOTIFY received on the phone is the old body as well. >>>>>> >>>>>> I thought about doing a string replace on the outbound NOTIFY but >>>>>> it never hits my routing script, so I can't. >>>>>> >>>>>> I read textops and it does not list any limitations relating to me. >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> David >>>>>> >>>>>> Klaus Darilion wrote: >>>>>>> I think the problem lies within the dialog module. Dialog module >>>>>>> stores from/to URI. Both, from and to URI are derived from the >>>>>>> headers. We could extend the dialog module to store request-URI >>>>>>> in the dialog-info structure too, and add an option to >>>>>>> pua_dialoginfo to use RURI instead of To-URI. >>>>>>> >>>>>>> regards >>>>>>> klaus >>>>>>> >>>>>>> David schrieb: >>>>>>>> Hey, >>>>>>>> >>>>>>>> I think I am doing something wrong, because here is the NOTIFY >>>>>>>> that comes to the phone : >>>>>>>> >>>>>>>> NOTIFY sip:group1.101@my.home.ip:57234 SIP/2.0 >>>>>>>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0 >>>>>>>> To: sip:group1.101@my.kamailio.domain.name;tag=b2514519391e8b4d >>>>>>>> From: >>>>>>>> sip:102@my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>>>> >>>>>>>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d(a)192.168.1.104 >>>>>>>> Content-Length: 298 >>>>>>>> User-Agent: MyServer 1.0 >>>>>>>> Max-Forwards: 70 >>>>>>>> Event: dialog >>>>>>>> Contact: <sip:my.kamailio.domain.name:5060> >>>>>>>> Subscription-State: active;expires=1570 >>>>>>>> Content-Type: application/dialog-info+xml >>>>>>>> >>>>>>>> <?xml version="1.0"?> <dialog-info >>>>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" >>>>>>>> version="11" state="full" >>>>>>>> entity="group1.102(a)my.kamailio.domain.name"> <dialog >>>>>>>> id="7aaa32e84362a246716009175ad670be(a)domain.tld" >>>>>>>> direction="recipient"> <state>early</state> </dialog> >>>>>>>> </dialog-info> >>>>>>>> >>>>>>>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + >>>>>>>> SPA932) does not flash lights or anything. Since you suggested >>>>>>>> that a solid kamailio would work out of the box, I suspect that >>>>>>>> either I miscommunicated my setup or did something really >>>>>>>> wrong. The notify definitely gets to the phone and the phone >>>>>>>> replies 200/OK when it receives the NOTIFY. But I think that >>>>>>>> the telephone is not understanding the request because it >>>>>>>> subscribed to '102' but received a notification for >>>>>>>> 'group1.102'. The funny thing is, the From header matches the >>>>>>>> subscribe To header, it's just the XML has the full name >>>>>>>> instead of the shortened name. >>>>>>>> >>>>>>>> To: >>>>>>>> <sip:102@my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>>>> >>>>>>>> >>>>>>>> I see this in my ( on kamailio ) /var/log/messages : >>>>>>>> >>>>>>>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]: >>>>>>>> INFO:presence:send_notify_request: NOTIFY >>>>>>>> sip:group1.101@my.kamailio.domain.name via >>>>>>>> sip:group1.101@my.home.ip.where.phone.is:57234 on behalf of >>>>>>>> sip:102@my.kamailio.domain.name for event dialog >>>>>>>> >>>>>>>> I should also mention that the NOTIFY sent out by presence >>>>>>>> bypasses my routing scripts. So I have the PUBLISH come through >>>>>>>> ( which I leave alone ) and the NOTIFY is sent according to the >>>>>>>> location table without ever consulting my routing script. >>>>>>>> >>>>>>>> So everything amazingly worked out well, except that the lights >>>>>>>> are not changing status which I think is related to the XML >>>>>>>> document dialog-info entity attribute containing the group >>>>>>>> name, sent from my server. >>>>>>>> >>>>>>>> Any ideas or suggestions ? >>>>>>>> >>>>>>>> Thanks, >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>> Other information : >>>>>>>> >>>>>>>> if ( is_method("SUBSCRIBE") ) >>>>>>>> { >>>>>>>> avp_db_query("select groupname from sometable ", >>>>>>>> "$avp(s:groupname)"); >>>>>>>> avp_printf("$ru", >>>>>>>> "sip:$avp(s:zone).$tU@my.kamailio.domain.name"); >>>>>>>> xlog("L_INFO", "Subscribe rewritten from $tU to >>>>>>>> $ru - M=$rm \n"); >>>>>>>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - >>>>>>>> $avp(s:zone) - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>>>>>>> handle_subscribe(); >>>>>>>> t_release(); >>>>>>>> exit; >>>>>>>> } >>>>>>>> >>>>>>>> Kamailio compiled from sources : >>>>>>>> >>>>>>>> Path: /usr/src/kamailio >>>>>>>> URL: >>>>>>>> https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 >>>>>>>> Repository Root: >>>>>>>> https://openser.svn.sourceforge.net/svnroot/openser >>>>>>>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 >>>>>>>> Revision: 5910 >>>>>>>> Node Kind: directory >>>>>>>> Schedule: normal >>>>>>>> Last Changed Author: henningw >>>>>>>> Last Changed Rev: 5910 >>>>>>>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009) >>>>>>>> >>>>>>>> >>>>>>>> Klaus Darilion wrote: >>>>>>>>> notifies are generated by the presence module, based on the >>>>>>>>> subscription. So, there is nothing you have to do with NOTIFY. >>>>>>>>> Also PUBLISHs are created internally. Depending on your >>>>>>>>> concrete setup (e.g. format of the SIP user names) it should >>>>>>>>> work out of the box. >>>>>>>>> >>>>>>>>> klaus >>>>>>>>> >>>>>>>>> dlublink schrieb: >>>>>>>>>> What about the notifies? >>>>>>>>>> >>>>>>>>>> Klaus Darilion wrote: >>>>>>>>>>> dlublink wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> I have three different groups of extensions on my kamailio >>>>>>>>>>>> I want to be able to separate them, so I prefixed a name to >>>>>>>>>>>> the extensions, so I have : >>>>>>>>>>>> >>>>>>>>>>>> 1. group1.101 >>>>>>>>>>>> 2. group1.102 >>>>>>>>>>>> 3. group2.101 >>>>>>>>>>>> 4. group2.102 >>>>>>>>>>>> 5. group3.102 >>>>>>>>>>>> 6. group3.103. >>>>>>>>>>>> >>>>>>>>>>>> The phones from different groups can not call each other, I >>>>>>>>>>>> found a pseudo variable that I use to rewrite the >>>>>>>>>>>> destination url, so if user group1.101 dials 102 I rewrite >>>>>>>>>>>> it to group1.102. >>>>>>>>>>>> >>>>>>>>>>>> I want to do the same thing for presence_dialog info, how >>>>>>>>>>>> can I rewrite the subscribe, presence and and notify >>>>>>>>>>>> messages to append the appropriate prefix ? >>>>>>>>>>> >>>>>>>>>>> Just apply the same rewrite you have already done for the >>>>>>>>>>> INVITE also for the SUBSCRIBE >>>>>>>>>>> >>>>>>>>>>> regards >>>>>>>>>>> klaus >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Kamailio (OpenSER) - Users mailing list >>>>>>>>>>>> Users(a)lists.kamailio.org >>>>>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>

14 years, 8 months

[Serusers] 200 OK not being ACKnowledged

by Steven C. Blair

I'm testing SIP trunking connectivity to an ITSP through a Covergence (CXC)/ACME Packet session border controller. Calls from an IP phone to the PSTN through SER and the CXC are being dropped 15 seconds after the initial call is setup and just after a cal l is answered. We do not have this problem with calls which reach the PSTN via local gateways. It seems that SER is not relaying an ACK which it receives from the phone which causes the SBC to resend a 200 OK message until finally the connection times out. I've checked the call routing and do not see any issue however I do notice the following in the SER logs. Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> Starting PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> End PRESENCE/BLA section Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: [Thu Aug 13 13:07:24 2009] [453a4bbf-90848c86-ea3a8091(a)128.91.56.18] --URI match--. Method: <ACK> R-uri: <sip:92155738396@vidar.net.isc.upenn.edu:5060;user=phone;maddr=128.91.56.242;transport=udp> Contact Header: <<sip:89390@128.91.56.18:5060>> From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> IP source address <128.91.2.223> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: --ACK--: Time: [Thu Aug 13 13:07:24 2009] From: <sip:89390@vidar.net.isc.upenn.edu> To <sip:92155738396@vidar.net.isc.upenn.edu;user=phone> Src IP <128.91.2.223> Method:<ACK> Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: [SER]: Too many hops Aug 13 13:07:24 vidar /usr/local/sbin/ser[19053]: Warning: sl_send_reply: I won't send a reply for ACK!! User 89390 is a local subscriber and the phone initiating the call. The recipient of the call is my desk phone 215-573-8396 which is on a different, unrelated SER service. We do record_route traffic through SER for call control and accounting reasons. It seems like the ACK is looping through SER and therefore never being sent to the SBC but I cannot see why. Does anyone have any thoughts on this issue? Thanks,Steve

14 years, 8 months

Re: [Kamailio-Users] presence_dialoginfo context

by David

Hey, Apparently the list did not accept the previous message... Here is the code you suggested with my modifications, it'll help put the log extracts in context : else if ( dst_port == 5060 ) { xlog("L_INFO", "Publish rewritten forwarded for ext=$tU ruri=$ru duri=$du body=$rb"); subst_body('/group1[.]//g' ) ; t_relay("udp:127.0.0.1:5050"); exit ; } else { xlog("L_INFO", "Publish accepted for ext=$tU ruri=$ru duri=$du body=$rb"); handle_publish(); t_release(); exit; } Here is an expert from the /var/log/messsages : Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28924]: Publish rewritten forwarded for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:group1.105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:group1.105@mydomain.tld</identity> <target uri="sip:group1.105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: New request - M=PUBLISH RURI=sip:group1.105@mydomain.tld F=sip:group1.105@mydomain.tld T=sip:group1.105@mydomain.tld IP=72.55.182.125 ID=7bddec01-28924(a)72.55.182.125 Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: Publish accepted for ext=group1.105 ruri=sip:group1.105@mydomain.tld duri=<null> body=<?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" entity="sip:105@mydomain.tld"> <dialog id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" call-id="5a9207de129fc16f49cafaa425e312f1(a)mydomain.tld" local-tag="4fbrxu9548" remote-tag="as4fb63283" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri="sip:103@mydomain.tld"/> </remote> <local> <identity>sip:105@mydomain.tld</identity> <target uri="sip:105@mydomain.tld"/> </local> </dialog> </dialog-info> Aug 14 10:16:42 kamailio-dev /usr/sbin/kamailio[28932]: INFO:presence:send_notify_request: NOTIFY sip:group1.101@mydomain.tld via sip:group1.101@phone.ip:57234 on behalf of sip:105@mydomain.tld for event dialog But the phone's syslog shows this : Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys [0:57234]<<server.ip:5060 Aug 14 10:16:21 linksys NOTIFY sip:group1.101@phone.ip:57234 SIP/2.0^M Via: SIP/2.0/UDP 72.55.182.125;branch=z9hG4bK0b0a.9725e23.0^M To: sip:group1.101@mydomain.tld;tag=1c32db3af4d889ac^M From: sip:105@mydomain.tld;tag=6d6077e15fecee48b2721a5e94bf8883-91a8^M CSeq: 12 NOTIFY^M Call-ID: 984d4cd2-37b04f4(a)192.168.1.104^M Content-Length: 655^M User-Agent: Kamailio (1.5.2-tls (i386/linux))^M Max-Forwards: 70^M Event: dialog^M Contact: <sip:mydomain.tld:5060>^M Subscription-State: active;expires=1470^M Content-Type: application/dialog-info+xml^M ^M <?xml version="1.0"?> <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" state="full" entity="group1.105(a)mydomain.tld"> <dialog id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" call-id="0b5776fb2ea599c429038414054eb383(a)mydomain.tld" local-tag="loto7h3i9a" remote-tag="as4f284f05" direction="recipient"> <state>early</state> <remote> <identity>sip:103@mydomain.tld</identity> <target uri=" Everything is good, but notice the entity is somehow back to group1.105. Where do you want me to run the traceroute? On the server? David Klaus Darilion wrote: > > > David schrieb: >> Hey, >> >> I tried that, but it did not seem to change anything. I saw the >> message change on the second loop, but it seems that the presence >> module figure out my tactic and fixed the message. > > That's not possible. The presence module does not alter the received > body. I think the problem is somewhere else. > > Can you send me a trace? > > ngrep -t -P "" -W byline -d any port 5060 > > regards > klaus > > >> >> David >> >> Klaus Darilion wrote: >>> That does not work: presence_server always uses the original >>> received body, the modifications applied by you are not seen by the >>> presence server. >>> >>> The workaround would be to "loop" the modified PUBLISH to Kamailio >>> again, e.g.: >>> >>> listen=.......:5060 >>> listen=.......:5050 >>> >>> route{ >>> ... >>> if (is_method("PUBLISH")) { >>> if (dst_port==5060) { >>> subst_body('/group1[.]//'); >>> t_relay("udp:127.0.0.1:5050); >>> } else if (dst_port==5050) { >>> handle_publish(); >>> t_release(); >>> } >>> } >>> ... >>> } >>> >>> >>> klaus >>> David schrieb: >>>> Hey, >>>> >>>> I tried doing a subst or replace_body_all to change the entity="" >>>> value, >>>> >>>> if (is_method("PUBLISH") ) >>>> { >>>> subst_body('/group1[.]//'); >>>> handle_publish(); >>>> t_release(); >>>> } >>>> >>>> It did not work, the $rb variable still shows the old body and the >>>> NOTIFY received on the phone is the old body as well. >>>> >>>> I thought about doing a string replace on the outbound NOTIFY but >>>> it never hits my routing script, so I can't. >>>> >>>> I read textops and it does not list any limitations relating to me. >>>> >>>> Any ideas? >>>> >>>> David >>>> >>>> Klaus Darilion wrote: >>>>> I think the problem lies within the dialog module. Dialog module >>>>> stores from/to URI. Both, from and to URI are derived from the >>>>> headers. We could extend the dialog module to store request-URI in >>>>> the dialog-info structure too, and add an option to pua_dialoginfo >>>>> to use RURI instead of To-URI. >>>>> >>>>> regards >>>>> klaus >>>>> >>>>> David schrieb: >>>>>> Hey, >>>>>> >>>>>> I think I am doing something wrong, because here is the NOTIFY >>>>>> that comes to the phone : >>>>>> >>>>>> NOTIFY sip:group1.101@my.home.ip:57234 SIP/2.0 >>>>>> Via: SIP/2.0/UDP my.kamailio.ip;branch=z9hG4bK3cab.78e494a4.0 >>>>>> To: sip:group1.101@my.kamailio.domain.name;tag=b2514519391e8b4d >>>>>> From: >>>>>> sip:102@my.kamailio.domain.name;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> CSeq: 12 NOTIFY^M Call-ID: 24db3209-611c031d(a)192.168.1.104 >>>>>> Content-Length: 298 >>>>>> User-Agent: MyServer 1.0 >>>>>> Max-Forwards: 70 >>>>>> Event: dialog >>>>>> Contact: <sip:my.kamailio.domain.name:5060> >>>>>> Subscription-State: active;expires=1570 >>>>>> Content-Type: application/dialog-info+xml >>>>>> >>>>>> <?xml version="1.0"?> <dialog-info >>>>>> xmlns="urn:ietf:params:xml:ns:dialog-info" version="11" >>>>>> state="full" entity="group1.102(a)my.kamailio.domain.name"> >>>>>> <dialog id="7aaa32e84362a246716009175ad670be(a)domain.tld" >>>>>> direction="recipient"> <state>early</state> </dialog> >>>>>> </dialog-info> >>>>>> >>>>>> The phone ( I tested with a GXP2000, GXP2020 and SPA962 + SPA932) >>>>>> does not flash lights or anything. Since you suggested that a >>>>>> solid kamailio would work out of the box, I suspect that either I >>>>>> miscommunicated my setup or did something really wrong. The >>>>>> notify definitely gets to the phone and the phone replies 200/OK >>>>>> when it receives the NOTIFY. But I think that the telephone is >>>>>> not understanding the request because it subscribed to '102' but >>>>>> received a notification for 'group1.102'. The funny thing is, the >>>>>> From header matches the subscribe To header, it's just the XML >>>>>> has the full name instead of the shortened name. >>>>>> >>>>>> To: >>>>>> <sip:102@my.kamailio.domain.name>;tag=6d6077e15fecee48b2721a5e94bf8883-f712 >>>>>> >>>>>> >>>>>> I see this in my ( on kamailio ) /var/log/messages : >>>>>> >>>>>> Aug 13 09:55:24 kamailio-dev /usr/sbin/kamailio[25449]: >>>>>> INFO:presence:send_notify_request: NOTIFY >>>>>> sip:group1.101@my.kamailio.domain.name via >>>>>> sip:group1.101@my.home.ip.where.phone.is:57234 on behalf of >>>>>> sip:102@my.kamailio.domain.name for event dialog >>>>>> >>>>>> I should also mention that the NOTIFY sent out by presence >>>>>> bypasses my routing scripts. So I have the PUBLISH come through ( >>>>>> which I leave alone ) and the NOTIFY is sent according to the >>>>>> location table without ever consulting my routing script. >>>>>> >>>>>> So everything amazingly worked out well, except that the lights >>>>>> are not changing status which I think is related to the XML >>>>>> document dialog-info entity attribute containing the group name, >>>>>> sent from my server. >>>>>> >>>>>> Any ideas or suggestions ? >>>>>> >>>>>> Thanks, >>>>>> >>>>>> David >>>>>> >>>>>> Other information : >>>>>> >>>>>> if ( is_method("SUBSCRIBE") ) >>>>>> { >>>>>> avp_db_query("select groupname from sometable ", >>>>>> "$avp(s:groupname)"); >>>>>> avp_printf("$ru", >>>>>> "sip:$avp(s:zone).$tU@my.kamailio.domain.name"); >>>>>> xlog("L_INFO", "Subscribe rewritten from $tU to $ru >>>>>> - M=$rm \n"); >>>>>> xlog("L_INFO", "Handling SUBSCRIBE - $fU - >>>>>> $avp(s:zone) - M=$rm RURI=$ru F=$fu T=$tu IP=$si ID=$ci\n"); >>>>>> handle_subscribe(); >>>>>> t_release(); >>>>>> exit; >>>>>> } >>>>>> >>>>>> Kamailio compiled from sources : >>>>>> >>>>>> Path: /usr/src/kamailio >>>>>> URL: >>>>>> https://openser.svn.sourceforge.net/svnroot/openser/branches/1.5 >>>>>> Repository Root: https://openser.svn.sourceforge.net/svnroot/openser >>>>>> Repository UUID: 689a6050-402a-0410-94f2-e92a70836424 >>>>>> Revision: 5910 >>>>>> Node Kind: directory >>>>>> Schedule: normal >>>>>> Last Changed Author: henningw >>>>>> Last Changed Rev: 5910 >>>>>> Last Changed Date: 2009-08-06 13:08:30 -0400 (Thu, 06 Aug 2009) >>>>>> >>>>>> >>>>>> Klaus Darilion wrote: >>>>>>> notifies are generated by the presence module, based on the >>>>>>> subscription. So, there is nothing you have to do with NOTIFY. >>>>>>> Also PUBLISHs are created internally. Depending on your concrete >>>>>>> setup (e.g. format of the SIP user names) it should work out of >>>>>>> the box. >>>>>>> >>>>>>> klaus >>>>>>> >>>>>>> dlublink schrieb: >>>>>>>> What about the notifies? >>>>>>>> >>>>>>>> Klaus Darilion wrote: >>>>>>>>> dlublink wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> I have three different groups of extensions on my kamailio I >>>>>>>>>> want to be able to separate them, so I prefixed a name to the >>>>>>>>>> extensions, so I have : >>>>>>>>>> >>>>>>>>>> 1. group1.101 >>>>>>>>>> 2. group1.102 >>>>>>>>>> 3. group2.101 >>>>>>>>>> 4. group2.102 >>>>>>>>>> 5. group3.102 >>>>>>>>>> 6. group3.103. >>>>>>>>>> >>>>>>>>>> The phones from different groups can not call each other, I >>>>>>>>>> found a pseudo variable that I use to rewrite the destination >>>>>>>>>> url, so if user group1.101 dials 102 I rewrite it to group1.102. >>>>>>>>>> >>>>>>>>>> I want to do the same thing for presence_dialog info, how can >>>>>>>>>> I rewrite the subscribe, presence and and notify messages to >>>>>>>>>> append the appropriate prefix ? >>>>>>>>> >>>>>>>>> Just apply the same rewrite you have already done for the >>>>>>>>> INVITE also for the SUBSCRIBE >>>>>>>>> >>>>>>>>> regards >>>>>>>>> klaus >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Kamailio (OpenSER) - Users mailing list >>>>>>>>>> Users(a)lists.kamailio.org >>>>>>>>>> http://lists.kamailio.org/cgi-bin/mailman/listinfo/users >>>>>>>>>> http://lists.openser-project.org/cgi-bin/mailman/listinfo/users >>>>>>>> >>>>>> >>>> >>

14 years, 8 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users August 2009