Word. -- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/ On Oct 25, 2011, at 10:04 PM, JR Richardson <jmr.richard...@gmail.com> wrote: > I am. > > On 10/25/11, sr-users-requ...@lists.sip-router.org > <sr-users-requ...@lists.sip-router.org> wrote: >> Send sr-users mailing list submissions to >> sr-users@lists.sip-router.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> or, via email, send a message with subject or body 'help' to >> sr-users-requ...@lists.sip-router.org >> >> You can reach the person managing the list at >> sr-users-ow...@lists.sip-router.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of sr-users digest..." >> >> >> Today's Topics: >> >> 1. Re: Dispatcher Confusion (v3.2.0) (Daniel-Constantin Mierla) >> 2. Re: Dispatcher Confusion (v3.2.0) (Daniel-Constantin Mierla) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Wed, 26 Oct 2011 05:44:06 +0200 >> From: Daniel-Constantin Mierla <mico...@gmail.com> >> Subject: Re: [SR-Users] Dispatcher Confusion (v3.2.0) >> To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users Mailing List" <sr-users@lists.sip-router.org> >> Message-ID: <4ea78206.4060...@gmail.com> >> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >> >> Hello, >> >> On 10/25/11 5:52 PM, Asgaroth wrote: >>> Hi Daniel, >>> >>> Thanks for the clarrification, >>> >>> On 25/10/2011 16:30, Daniel-Constantin Mierla wrote: >>>> >>>> >>>> 4.6. |ds_mark_dst("s")| >>>> >>>> Mark the last used address from destination set as inactive >>>> ("i"/"I"/"0"), active ("a"/"A"/"1") or probing ("p"/"P"/"2"). With >>>> this function, an automatic detection of failed gateways can be >>>> implemented. When an address is marked as inactive or probing, it >>>> will be ignored by 'ds_select_dst' and 'ds_select_domain'. >>>> >>> >>> Above is the part that is a little misleading, it says that >>> >>> "When an address is marked as inactive or probing, it will be ignored >>> by 'ds_select_dst' and 'ds_select_domain'." >>> >>> This, to me, means that if a gateway is in probing mode >>> (Active-Probing) then it wont be selected in the destination set >>> because it is in probing mode, if this is not the case then maybe the >>> above line should read: >>> >>> "When an address is marked as inactive or inactive-probing, it will be >>> ignored by 'ds_select_dst' and 'ds_select_domain'." >>> >>> This brings me to my next question then, how would I set the state of >>> a destination to Inactive-Probing (state: IP) from the routing script. >>> The ds_mark_dst() function only allows one of "a", "i", "p". >>> >>> If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive >>> with no probing to tell when gateway is back up. >>> >>> If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a >>> log is printed saying that you cannot put a destination into probing >>> state when it is marked as inactive. >> are you sure you run the devel version? There is no such case in the >> sources -- send me exactly the log message you get. Only when the >> destination is disabled the probing cannot be set, but not the same case >> of inactive. >> >>> >>> Is it possible to set the state of a gateway to inactive-probing from >>> the routing script? >> >> Yes, it should be, no constraint in master branch source code. >> >> Daniel >> >>> >>> Thanks >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users@lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat >> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.sip-router.org/pipermail/sr-users/attachments/20111026/85df6c63/attachment-0001.htm> >> >> ------------------------------ >> >> Message: 2 >> Date: Wed, 26 Oct 2011 05:47:43 +0200 >> From: Daniel-Constantin Mierla <mico...@gmail.com> >> Subject: Re: [SR-Users] Dispatcher Confusion (v3.2.0) >> To: "SIP Router - Kamailio (OpenSER) and SIP Express Router (SER) - >> Users Mailing List" <sr-users@lists.sip-router.org> >> Message-ID: <4ea782df.4030...@gmail.com> >> Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" >> >> Hello, >> >> On 10/25/11 10:09 PM, Asgaroth wrote: >>> Hi Daniel, >>> >>> I'm wondering if the change you made to the dev branch for setting the >>> state via fifo command is what could be causing this issues (just >>> guessing, I am more than likely worng :)), see my subsequent testing >>> below: >> the purpose with three states (active, inactive and disabled) was not to >> relate probing to selection of gateways, as one may want to have even >> active gateways in probing mode to detect when they go down. So, in >> other words, if probing mode is not checked when a gateways is selected, >> but only if the gateway has the state active. >> >> Cheers, >> Daniel >> >>> >>> Just a little further digging on this, seems to show that kamailio >>> v3.2.0 acts differently than 3.3.0 dev branch. >>> >>> Below is the log output of my routing logic using v3.2.0: >>> >>> at this point dispatcher is loaded with both destinations set in AX >>> (Active) state, I then shutdown the 2 destination port(s), then, >>> request comes in: >>> >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@10.10.10.10:5060>) >>> route[MAIN] : REGISTER : SBC selected for mydomain.com is >>> sip:10.10.10.11:10000 >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : next destination select >>> (sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:29822->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : No destinations available for mydomain.com >>> >>> This request responds as expected, however, both destinations are now >>> set in AP mode, then some more requests come in: >>> NOTE: $du seems to be causing issue here as well, but i think $du is >>> cosmetic (I have previously sent the routing logic that displays this). >>> >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@10.10.10.10:5060>) >>> route[MAIN] : REGISTER : No destinations available for mydomain.com >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@10.10.10.10:5060>) >>> route[MAIN] : REGISTER : No destinations available for mydomain.com >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@10.10.10.10:5060>) >>> route[MAIN] : REGISTER : No destinations available for mydomain.com >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:29822/ru=sip:mydomain.com/ct=<sip:s@10.10.10.10:5060>) >>> route[MAIN] : REGISTER : No destinations available for mydomain.com >>> >>> This is behaiving as I understand it from the docs. Both destinations >>> are in Active-Probing state, and, because they are in probing state, >>> ds_select_dst will not use them in the selection process for >>> subsequent requests. >>> >>> Now, when testing with 3.3.0 dev branch: >>> >>> Below is log output of my routing script logic using 3.3.0 dev: >>> >>> at this point dispatcher is loaded with both destinations set in AX >>> (Active) state, I then shutdown the 2 destination port(s), then, >>> request comes in: >>> >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>) >>> route[MAIN] : REGISTER : SBC selected for mydomain.com is >>> sip:10.10.10.11:10000 >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : No destinations available for mydomain.com >>> >>> This request responds as expected, however, both destinations are now >>> set in AP mode, then some more requests come in: >>> NOTE: $du seems to be causing issue here as well, but i think $du is >>> cosmetic (I have previously sent the routing logic that displays this). >>> >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>) >>> route[MAIN] : REGISTER : SBC selected for mydomain.com is >>> sip:10.10.10.11:10001 >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state >>> route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state >>> route[TO_SBC] : REGISTER : No destinations available for mydomain.com >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>) >>> route[MAIN] : REGISTER : SBC selected for mydomain.com is >>> sip:10.10.10.11:10000 >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10000 to probing state >>> route[TO_SBC] : REGISTER : No destinations available for mydomain.com >>> route[MAIN] : REGISTER : Initial route request >>> (if=10.10.10.1:5060/src=10.10.10.10:44502/ru=sip:mydomain.com:5060/ct=<sip:s@10.10.10.10:5080>) >>> route[MAIN] : REGISTER : SBC selected for mydomain.com is >>> sip:10.10.10.11:10001 >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state >>> route[TO_SBC] : REGISTER : next destination select (sip:10.10.10.11:10000) >>> route[TO_SBC] : REGISTER : timeout and no reply >>> (10.10.10.10:44502->10.10.10.1:5060->sip:10.10.10.11:10001) >>> route[TO_SBC] : REGISTER : setting sip:10.10.10.11:10001 to probing state >>> route[TO_SBC] : REGISTER : No destinations available for mydomain.com >>> >>> This is not behaving as I understand the docs to explain. The only >>> difference between the 2 versions of the script logic is the version >>> of kamailio, the exact same routing script is used in both scenarios. >>> >>> The "working as understood from docs" version is as follows: >>> >>> # ./kamailio -V >>> version: kamailio 3.2.0 (i386/linux) e19bb8 >>> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, >>> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, >>> SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, >>> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, >>> USE_DST_BLACKLIST, HAVE_RESOLV_RES >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> id: e19bb8 >>> compiled on 15:04:46 Oct 25 2011 with gcc 4.1.2 >>> >>> The "not working as understood from docs" version is as follows: >>> >>> # /kamailio -V >>> version: kamailio 3.3.0-dev0 (i386/linux) 25bedc >>> flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, >>> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, >>> SHM_MMAP, PKG_MALLOC, DBG_QM_MALLOC, USE_FUTEX, >>> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, >>> USE_DST_BLACKLIST, HAVE_RESOLV_RES >>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, >>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 4MB >>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. >>> id: 25bedc >>> compiled on 09:18:41 Oct 21 2011 with gcc 4.1.2 >>> >>> I hope I'm not going crazy here :/ >>> >>> Thanks >>> >>> >>> >>> >>> On 25/10/2011 16:52, Asgaroth wrote: >>>> Hi Daniel, >>>> >>>> Thanks for the clarrification, >>>> >>>> On 25/10/2011 16:30, Daniel-Constantin Mierla wrote: >>>>> >>>>> >>>>> 4.6. |ds_mark_dst("s")| >>>>> >>>>> Mark the last used address from destination set as inactive >>>>> ("i"/"I"/"0"), active ("a"/"A"/"1") or probing ("p"/"P"/"2"). With >>>>> this function, an automatic detection of failed gateways can be >>>>> implemented. When an address is marked as inactive or probing, it >>>>> will be ignored by 'ds_select_dst' and 'ds_select_domain'. >>>>> >>>> >>>> Above is the part that is a little misleading, it says that >>>> >>>> "When an address is marked as inactive or probing, it will be ignored >>>> by 'ds_select_dst' and 'ds_select_domain'." >>>> >>>> This, to me, means that if a gateway is in probing mode >>>> (Active-Probing) then it wont be selected in the destination set >>>> because it is in probing mode, if this is not the case then maybe the >>>> above line should read: >>>> >>>> "When an address is marked as inactive or inactive-probing, it will >>>> be ignored by 'ds_select_dst' and 'ds_select_domain'." >>>> >>>> This brings me to my next question then, how would I set the state of >>>> a destination to Inactive-Probing (state: IP) from the routing >>>> script. The ds_mark_dst() function only allows one of "a", "i", "p". >>>> >>>> If I do a ds_mark_dst("i"), then the state changes to "IX", Inactive >>>> with no probing to tell when gateway is back up. >>>> >>>> If I do a ds_mark_dst("i") and then right after ds_mark_dst("p"), a >>>> log is printed saying that you cannot put a destination into probing >>>> state when it is marked as inactive. >>>> >>>> Is it possible to set the state of a gateway to inactive-probing from >>>> the routing script? >>>> >>>> Thanks >>>> >>>> >>>> >>>> _______________________________________________ >>>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>>> sr-users@lists.sip-router.org >>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >>> >>> >>> >>> _______________________________________________ >>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >>> sr-users@lists.sip-router.org >>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> -- >> Daniel-Constantin Mierla -- http://www.asipto.com >> Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kat >> http://linkedin.com/in/miconda -- http://twitter.com/miconda >> >> -------------- next part -------------- >> An HTML attachment was scrubbed... >> URL: >> <http://lists.sip-router.org/pipermail/sr-users/attachments/20111026/d195bb13/attachment.htm> >> >> ------------------------------ >> >> _______________________________________________ >> sr-users mailing list >> sr-users@lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> >> End of sr-users Digest, Vol 77, Issue 84 >> **************************************** >> > > -- > Sent from my mobile device > > JR Richardson > Engineering for the Masses > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
