Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

List overview All Threads
Download

newer

older

openser_receiver

default flavour set to kamailio

SIP Mailing-list

27 Nov 2012 27 Nov '12

9:12 p.m.

Hi guys, I wonder if someone could sanity check something for me. I currently have a simple load balancer set up using algorithm 10 (call load distribution) from the dispatcher module. I'm using Record-Routing so that I can clear down the call load record at the end of the call. Everything looked like it was working okay until I just spotted a problem that I think might be a bug. It's to do with ACKs to non-200 responses. In a normal call, the flow goes: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 200 OK --- ds_load_update() 4 <-- 200 OK 5 ACK --> 6 ACK --> Now between step 3 and 4 the proxy runs ds_load_update which according to the documentation "set internal state to confirmed for the call load" entry in the internal call state store. This means the proxy knows where to send the ACK at step 5 because it is safely in the call state store so you can use ds_select_dst again on the ACK to get it to the right place. Works fine! Now consider the non-200 case: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 603 Decline --- ds_load_unset() 4 <-- 603 Decline 5 ACK --> 6 ACK --> ??? Between step 3 and 4 the proxy is supposed to run ds_load_unset() which unconditionally removes the call from the call state store. Now when the ACK comes in at step 5, the proxy has no record of the call and so doesn't know where to send the ACK. This results in retried Declines and ACKs. Broken :-( If the proxy doesn't run ds_load_unset() on the 603 response, is there some kind of timer that will cause the call to be removed from the call state store on unconfirmed calls? I don't think I can run ds_load_unset on the ACK because there's nothing in the ACK that tells me it is because of a 603, rather than a 200. Edit: actually there is! The Route header is present on the 200 ACK, but * not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any thoughts would be appreciated! Cheers, Richard

Attachments:

attachment.html (text/html — 2.4 KB)

Show replies by date

SIP Mailing-list

28 Nov 28 Nov

1:40 p.m.

New subject: Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

...

Daniel-Constantin Mierla

30 Nov 30 Nov

9:31 a.m.

New subject: Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

Hello, by stateless dispatcher do you mean using forward() to send out the INVITE? Cheers, Daniel On 11/28/12 1:40 PM, SIP Mailing-list wrote:

...

Further edit: Actually I tried using ds_select_dst to forward the ACK on the unconfirmed (unanswered; 603 Decline) call but it routed to another destination. My work-around involves using ds_next_dst to send the ACK to *all* destinations. Does anyone know if there is a way to fix this behaviour? Any help is much appreciated! Cheers, Richard On 27 November 2012 20:12, SIP Mailing-list <sip(a)racitup.com <mailto:sip@racitup.com>> wrote: Hi guys, I wonder if someone could sanity check something for me. I currently have a simple load balancer set up using algorithm 10 (call load distribution) from the dispatcher module. I'm using Record-Routing so that I can clear down the call load record at the end of the call. Everything looked like it was working okay until I just spotted a problem that I think might be a bug. It's to do with ACKs to non-200 responses. In a normal call, the flow goes: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 200 OK --- ds_load_update() 4 <-- 200 OK 5 ACK --> 6 ACK --> Now between step 3 and 4 the proxy runs ds_load_update which according to the documentation "set internal state to confirmed for the call load" entry in the internal call state store. This means the proxy knows where to send the ACK at step 5 because it is safely in the call state store so you can use ds_select_dst again on the ACK to get it to the right place. Works fine! Now consider the non-200 case: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 603 Decline --- ds_load_unset() 4 <-- 603 Decline 5 ACK --> 6 ACK --> ??? Between step 3 and 4 the proxy is supposed to run ds_load_unset() which unconditionally removes the call from the call state store. Now when the ACK comes in at step 5, the proxy has no record of the call and so doesn't know where to send the ACK. This results in retried Declines and ACKs. Broken :-( If the proxy doesn't run ds_load_unset() on the 603 response, is there some kind of timer that will cause the call to be removed from the call state store on unconfirmed calls? I don't think I can run ds_load_unset on the ACK because there's nothing in the ACK that tells me it is because of a 603, rather than a 200. Edit: actually there is! The Route header is present on the 200 ACK, but *not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any thoughts would be appreciated! Cheers, Richard _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

SIP Mailing-list

1 Dec 1 Dec

4:35 a.m.

New subject: Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

Hi Daniel, Yes I am using forward() because I thought it would be the fastest solution. I guess I was lead on by the dispatcher documentation saying it can be used statelessly, so I tried to do the whole route script stateless. However, I've recently been looking at t_relay and in particular t_check_trans() and I think that might be the answer... I do think it would be great if the ds_select_dst/domain functions performed a lookup in the hash table for non-INVITEs and set the right destination though. Cheers, Richard On 30 November 2012 08:31, Daniel-Constantin Mierla <miconda(a)gmail.com>wrote;wrote:

...

Hello, by stateless dispatcher do you mean using forward() to send out the INVITE? Cheers, Daniel On 11/28/12 1:40 PM, SIP Mailing-list wrote: Further edit: Actually I tried using ds_select_dst to forward the ACK on the unconfirmed (unanswered; 603 Decline) call but it routed to another destination. My work-around involves using ds_next_dst to send the ACK to *all* destinations. Does anyone know if there is a way to fix this behaviour? Any help is much appreciated! Cheers, Richard On 27 November 2012 20:12, SIP Mailing-list <sip(a)racitup.com> wrote:

Hi guys, I wonder if someone could sanity check something for me. I currently have a simple load balancer set up using algorithm 10 (call load distribution) from the dispatcher module. I'm using Record-Routing so that I can clear down the call load record at the end of the call. Everything looked like it was working okay until I just spotted a problem that I think might be a bug. It's to do with ACKs to non-200 responses. In a normal call, the flow goes: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 200 OK --- ds_load_update() 4 <-- 200 OK 5 ACK --> 6 ACK --> Now between step 3 and 4 the proxy runs ds_load_update which according to the documentation "set internal state to confirmed for the call load" entry in the internal call state store. This means the proxy knows where to send the ACK at step 5 because it is safely in the call state store so you can use ds_select_dst again on the ACK to get it to the right place. Works fine! Now consider the non-200 case: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 603 Decline --- ds_load_unset() 4 <-- 603 Decline 5 ACK --> 6 ACK --> ??? Between step 3 and 4 the proxy is supposed to run ds_load_unset() which unconditionally removes the call from the call state store. Now when the ACK comes in at step 5, the proxy has no record of the call and so doesn't know where to send the ACK. This results in retried Declines and ACKs. Broken :-( If the proxy doesn't run ds_load_unset() on the 603 response, is there some kind of timer that will cause the call to be removed from the call state store on unconfirmed calls? I don't think I can run ds_load_unset on the ACK because there's nothing in the ACK that tells me it is because of a 603, rather than a 200. Edit: actually there is! The Route header is present on the 200 ACK, but *not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any thoughts would be appreciated! Cheers, Richard

_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing listsr-users@lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla - http://www.asipto.comhttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

Daniel-Constantin Mierla

4 Dec 4 Dec

5:36 p.m.

New subject: Problem with Stateless Dispatcher Call Load Distribution (Algorithm 10)

Hello, only several algorithms are suitable for full stateless usage, I am mainly referring to those doing hashes over attributes of the sip message (like hash over call id). For the other you would need to use tm module and t_relay(). That will make it easy for you. Otherwise, you can use htable module to store the address from where the reply is coming and send the ACK there if it doesn't have a route header. Cheers, Daniel On 12/1/12 4:35 AM, SIP Mailing-list wrote:

...

Further edit: Actually I tried using ds_select_dst to forward the ACK on the unconfirmed (unanswered; 603 Decline) call but it routed to another destination. My work-around involves using ds_next_dst to send the ACK to *all* destinations. Does anyone know if there is a way to fix this behaviour? Any help is much appreciated! Cheers, Richard On 27 November 2012 20:12, SIP Mailing-list <sip(a)racitup.com <mailto:sip@racitup.com>> wrote: Hi guys, I wonder if someone could sanity check something for me. I currently have a simple load balancer set up using algorithm 10 (call load distribution) from the dispatcher module. I'm using Record-Routing so that I can clear down the call load record at the end of the call. Everything looked like it was working okay until I just spotted a problem that I think might be a bug. It's to do with ACKs to non-200 responses. In a normal call, the flow goes: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 200 OK --- ds_load_update() 4 <-- 200 OK 5 ACK --> 6 ACK --> Now between step 3 and 4 the proxy runs ds_load_update which according to the documentation "set internal state to confirmed for the call load" entry in the internal call state store. This means the proxy knows where to send the ACK at step 5 because it is safely in the call state store so you can use ds_select_dst again on the ACK to get it to the right place. Works fine! Now consider the non-200 case: UAC Proxy UAS 1 INVITE --> 2 INVITE--> 3 <-- 603 Decline --- ds_load_unset() 4 <-- 603 Decline 5 ACK --> 6 ACK --> ??? Between step 3 and 4 the proxy is supposed to run ds_load_unset() which unconditionally removes the call from the call state store. Now when the ACK comes in at step 5, the proxy has no record of the call and so doesn't know where to send the ACK. This results in retried Declines and ACKs. Broken :-( If the proxy doesn't run ds_load_unset() on the 603 response, is there some kind of timer that will cause the call to be removed from the call state store on unconfirmed calls? I don't think I can run ds_load_unset on the ACK because there's nothing in the ACK that tells me it is because of a 603, rather than a 200. Edit: actually there is! The Route header is present on the 200 ACK, but *not* on the 3xx to 6xx ACK. Maybe I can use loose_route... Anyway, any thoughts would be appreciated! Cheers, Richard _______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users(a)lists.sip-router.org <mailto:sr-users@lists.sip-router.org> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Daniel-Constantin Mierla -http://www.asipto.com http://twitter.com/#!/miconda <http://twitter.com/#%21/miconda> -http://www.linkedin.com/in/miconda

-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

4170

days inactive

4177

days old

sr-users@lists.kamailio.org

Manage subscription

4 comments

2 participants

tags (0)

participants (2)

Daniel-Constantin Mierla
SIP Mailing-list