[SR-Users] Who is at Astricon?
Alex Balashov
abalashov at evaristesys.com
Wed Oct 26 06:18:49 CEST 2011
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.richardson at gmail.com> wrote:
> I am.
>
> On 10/25/11, sr-users-request at lists.sip-router.org
> <sr-users-request at lists.sip-router.org> wrote:
>> Send sr-users mailing list submissions to
>> sr-users at 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-request at lists.sip-router.org
>>
>> You can reach the person managing the list at
>> sr-users-owner at 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 <miconda at 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 at lists.sip-router.org>
>> Message-ID: <4EA78206.4060203 at 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 at 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 <miconda at 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 at lists.sip-router.org>
>> Message-ID: <4EA782DF.4030206 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at 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 at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
More information about the sr-users
mailing list