Re: [SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello Daniel,

A URI param doesn't sound bad at all for this purpose, and works like a
charm! I believe the parameter never makes it to the receiving end when
using regular dispatcher functionality, as the R-URI is not rewritten and
only the $du variable is set with this URI, which never appears in the SIP
message anywhere, right? So there's some degree of elegance here as well
:-D.

Thanks again for the workaround, I've been working on this for a while...

Best regards,
George

On 20 December 2017 at 17:26, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> an workaround would be to add a custom parameter to the destination value,
> like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored by the
> receiving party. Or if you have only two records with same address, add to
> one ";transport=udp".
>
> Of course, coding in C to make it easier in config would be the elegant
> solution.
>
> Cheers,
> Daniel
>
> On 20.12.17 15:32, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> Thanks for the reply. Unfortunately I can't really use the database
> records to achieve what I want. The example in my previous message didn't
> show this, but I would like to be able to differentiate between the
> following:
>
> ++---+-+---+--+-
> +
> | id | setid | destination | flags | priority |
> attrs   |
> ++---+-+---+--+-
> +
> |  1 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 44.44.44.1:5060  |
> |  2 |10 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 55.55.55.1:5060  |
> ++---+-+---+--+-
> +
>
> In this case, how can I tell which destination went down? The URI is the
> same, but the sockets differ for each id.
>
> If only $ru is available in these event routes, I can't query the database
> because $ru matches both records. If I can't access the socket used with a
> PV, is there any way to have access to *either* the id *or* the setid for
> the destination for which the event was generated?
>
> Thanks!
>
> BR,
> George
>
> On 20 December 2017 at 10:57, Daniel-Constantin Mierla 
> wrote:
>
>> Hello,
>>
>> those event routes are executed with a so called faked request (a request
>> generated internally, unrelated to the OPTIONS request sent to the wire),
>> apart of request uri, the rest of values are not related to the dispatcher
>> records.
>>
>> To get access to other attributes of dispatcher records in a straight way
>> in the config, it would require C coding, Anyhow, even now using scripting,
>> you can try with sql queries to database or rpc commands execution via
>> jsonrpcs module and then parse the result using jansson module.
>>
>> Cheers,
>> Daniel
>>
>> On 18.12.17 13:33, George Diamantopoulos wrote:
>>
>> Hello all,
>>
>> I use the dispatcher module extensively for load balancing and fail-over.
>> My kamailio instance is multihomed, and I use the "socket" attribute to
>> determine which socket SIP messages should use for each dispatcher
>> destination, as such:
>>
>> ++---+-+---+--+-
>> +
>> | id | setid | destination | flags | priority |
>> attrs   |
>> ++---+-+---+--+-
>> +
>> |  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
>> 10.10.10.1:5060  |
>> |  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
>> 44.44.44.1:5060  |
>> |  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
>> 55.55.55.1:5060  |
>> ++---+-+---+--+-
>> +
>>
>> The dispatcher module uses OPTIONS to probe each destination for
>> availability. When a destination goes down or up, the respective
>> event-route is executed.
>>
>> What I need to do is to be able to "capture" the sending socket used for
>> this probing when a destination becomes unavailable or available in the
>> event-routes. The $fs variable is set, but unfortunately its value does not
>> make sense. Here's an example route and the results that are printed:
>>
>> event_route[dispatcher:dst-down] {
>> xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
>> $T_req($fs) $T_req($Ru)\n");
>> }
>>
>> Now say destination with id = '2' goes down. This is what I get in the
>> logs for the event_route above:
>>
>> ERROR: 

Re: [SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[Daniel-Constantin Mierla]

Hello,

an workaround would be to add a custom parameter to the destination
value, like sip:1.2.3.4:5060;sid=1. Unknown parameters should be ignored
by the receiving party. Or if you have only two records with same
address, add to one ";transport=udp".

Of course, coding in C to make it easier in config would be the elegant
solution.

Cheers,
Daniel


On 20.12.17 15:32, George Diamantopoulos wrote:
> Hello Daniel,
>
> Thanks for the reply. Unfortunately I can't really use the database
> records to achieve what I want. The example in my previous message
> didn't show this, but I would like to be able to differentiate between
> the following:
>
> ++---+-+---+--+-+
> | id | setid | destination | flags | priority |
> attrs   |
> ++---+-+---+--+-+
> |  1 | 1 | sip:111.111.11.1:5060   
> | 8 |    0 | socket=udp:44.44.44.1:5060
>   |
> |  2 |    10 | sip:111.111.11.1:5060   
> | 8 |    0 | socket=udp:55.55.55.1:5060
>   |
> ++---+-+---+--+-+
>
> In this case, how can I tell which destination went down? The URI is
> the same, but the sockets differ for each id.
>
> If only $ru is available in these event routes, I can't query the
> database because $ru matches both records. If I can't access the
> socket used with a PV, is there any way to have access to *either* the
> id *or* the setid for the destination for which the event was generated?
>
> Thanks!
>
> BR,
> George
>
> On 20 December 2017 at 10:57, Daniel-Constantin Mierla
> > wrote:
>
> Hello,
>
> those event routes are executed with a so called faked request (a
> request generated internally, unrelated to the OPTIONS request
> sent to the wire), apart of request uri, the rest of values are
> not related to the dispatcher records.
>
> To get access to other attributes of dispatcher records in a
> straight way in the config, it would require C coding, Anyhow,
> even now using scripting, you can try with sql queries to database
> or rpc commands execution via jsonrpcs module and then parse the
> result using jansson module.
>
> Cheers,
> Daniel
>
>
> On 18.12.17 13:33, George Diamantopoulos wrote:
>> Hello all,
>>
>> I use the dispatcher module extensively for load balancing and
>> fail-over. My kamailio instance is multihomed, and I use the
>> "socket" attribute to determine which socket SIP messages should
>> use for each dispatcher destination, as such:
>>
>> 
>> ++---+-+---+--+-+
>> | id | setid | destination | flags | priority |
>> attrs   |
>> 
>> ++---+-+---+--+-+
>> |  1 | 0 | sip:192.168.0.1:5060    
>> | 8 |    0 | socket=udp:10.10.10.1:5060
>>   |
>> |  2 | 1 | sip:111.111.11.1:5060   
>> | 8 |    0 | socket=udp:44.44.44.1:5060
>>   |
>> |  3 | 1 | sip:222.222.22.2:5060   
>> | 8 |    0 | socket=udp:55.55.55.1:5060
>>   |
>> 
>> ++---+-+---+--+-+
>>
>> The dispatcher module uses OPTIONS to probe each destination for
>> availability. When a destination goes down or up, the respective
>> event-route is executed.
>>
>> What I need to do is to be able to "capture" the sending socket
>> used for this probing when a destination becomes unavailable or
>> available in the event-routes. The $fs variable is set, but
>> unfortunately its value does not make sense. Here's an example
>> route and the results that are printed:
>>
>> event_route[dispatcher:dst-down] {
>>     xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru
>> $T_req($fs) $T_req($Ru)\n");
>> }
>>
>> Now say destination with id = '2' goes down. This is what I get
>> in the logs for the event_route above:
>>
>> ERROR: 

Re: [SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello Daniel,

Thanks for the reply. Unfortunately I can't really use the database records
to achieve what I want. The example in my previous message didn't show
this, but I would like to be able to differentiate between the following:

++---+-+---+--+-
+
| id | setid | destination | flags | priority |
attrs   |
++---+-+---+--+-
+
|  1 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
44.44.44.1:5060  |
|  2 |10 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
55.55.55.1:5060  |
++---+-+---+--+-
+

In this case, how can I tell which destination went down? The URI is the
same, but the sockets differ for each id.

If only $ru is available in these event routes, I can't query the database
because $ru matches both records. If I can't access the socket used with a
PV, is there any way to have access to *either* the id *or* the setid for
the destination for which the event was generated?

Thanks!

BR,
George

On 20 December 2017 at 10:57, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> those event routes are executed with a so called faked request (a request
> generated internally, unrelated to the OPTIONS request sent to the wire),
> apart of request uri, the rest of values are not related to the dispatcher
> records.
>
> To get access to other attributes of dispatcher records in a straight way
> in the config, it would require C coding, Anyhow, even now using scripting,
> you can try with sql queries to database or rpc commands execution via
> jsonrpcs module and then parse the result using jansson module.
>
> Cheers,
> Daniel
>
> On 18.12.17 13:33, George Diamantopoulos wrote:
>
> Hello all,
>
> I use the dispatcher module extensively for load balancing and fail-over.
> My kamailio instance is multihomed, and I use the "socket" attribute to
> determine which socket SIP messages should use for each dispatcher
> destination, as such:
>
> ++---+-+---+--+-
> +
> | id | setid | destination | flags | priority |
> attrs   |
> ++---+-+---+--+-
> +
> |  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
> 10.10.10.1:5060  |
> |  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
> 44.44.44.1:5060  |
> |  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
> 55.55.55.1:5060  |
> ++---+-+---+--+-
> +
>
> The dispatcher module uses OPTIONS to probe each destination for
> availability. When a destination goes down or up, the respective
> event-route is executed.
>
> What I need to do is to be able to "capture" the sending socket used for
> this probing when a destination becomes unavailable or available in the
> event-routes. The $fs variable is set, but unfortunately its value does not
> make sense. Here's an example route and the results that are printed:
>
> event_route[dispatcher:dst-down] {
> xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
> $T_req($Ru)\n");
> }
>
> Now say destination with id = '2' goes down. This is what I get in the
> logs for the event_route above:
>
> ERROR: 

[SR-Users] Dispatcher module OPTIONS and event routes: how are they handled by core?

[George Diamantopoulos]

Hello all,

I use the dispatcher module extensively for load balancing and fail-over.
My kamailio instance is multihomed, and I use the "socket" attribute to
determine which socket SIP messages should use for each dispatcher
destination, as such:

++---+-+---+--+-+
| id | setid | destination | flags | priority |
attrs   |
++---+-+---+--+-+
|  1 | 0 | sip:192.168.0.1:5060| 8 |0 | socket=udp:
10.10.10.1:5060  |
|  2 | 1 | sip:111.111.11.1:5060   | 8 |0 | socket=udp:
44.44.44.1:5060  |
|  3 | 1 | sip:222.222.22.2:5060   | 8 |0 | socket=udp:
55.55.55.1:5060  |
++---+-+---+--+-+

The dispatcher module uses OPTIONS to probe each destination for
availability. When a destination goes down or up, the respective
event-route is executed.

What I need to do is to be able to "capture" the sending socket used for
this probing when a destination becomes unavailable or available in the
event-routes. The $fs variable is set, but unfortunately its value does not
make sense. Here's an example route and the results that are printed:

event_route[dispatcher:dst-down] {
xlog("L_ERR", "Destination down: $rm $ru ($du) $ds $fs $Ru $T_req($fs)
$T_req($Ru)\n");
}

Now say destination with id = '2' goes down. This is what I get in the logs
for the event_route above:

ERROR: