2 Oct
2011
2 Oct
'11
8 p.m.
Hi,
I am trying to create concurrent calls limitations.
two questions:
1. should i use dialog module? or is there a better module?
2. i was trying to work with the dialog module, but didnt understand how and
where to configure the commands and which to use.... any examples or ideas?
BR,
Uri
3 Oct
3 Oct
5:03 a.m.
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may
have just read my posts).
Here is how I am doing it, roughly, for me. I have two places where I am
executing the 3rd section below (for outbound and inbound).
Your mileage will vary.
modparam("auth_db", "load_credentials", "username")
.
.
.
.
avp_db_query("select quota from quota where
username='$avp(s:username)'",
"$avp(s:quota)");
.
.
.
.
$var(SIZE) = 0;
get_profile_size("callquota", "$avp(s:username)",
"$var(SIZE)");
if( $var(SIZE) >= $avp(s:quota) ){
sl_send_reply("503", "Simultaneous calls limit
reached");
xlog("DEBUG: Limit of $var(SIZE) active calls has been
reached for $avp(s:username)\n");
exit;
}
set_dlg_profile("callquota","$avp(s:username)");
get_profile_size("callquota", "$avp(s:username)",
"$var(SIZE)");
xlog("DEBUG: there are now $var(SIZE) active calls for
$avp(s:username)\n");
On 10/2/11 12:00 PM, "Uri Shacked" <ushacked(a)gmail.com> wrote:
Hi,
I am trying to create concurrent calls limitations.
two questions:
1. should i use dialog module? or is there a better module?
2. i was trying to work with the dialog module, but didnt understand how and
where to configure the commands and which to use.... any examples or ideas?
BR,
Uri
_______________________________________________
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
5:32 a.m.
Graham,
Good deal. The one improvement I would suggest would be to use sqlops for custom DB
queries as it is more flexible, and is the canonical way to do them now as of >= 1.5.0.
avp_db_query() could go away at some point.
--
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 2, 2011, at 10:03 PM, Graham Wooden <graham(a)g-rock.net> wrote:
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may have just
read my posts).
Here is how I am doing it, roughly, for me. I have two places where I am executing the
3rd section below (for outbound and inbound).
Your mileage will vary.
modparam("auth_db", "load_credentials", "username")
.
.
.
.
avp_db_query("select quota from quota where
username='$avp(s:username)'", "$avp(s:quota)");
.
.
.
.
$var(SIZE) = 0;
get_profile_size("callquota", "$avp(s:username)",
"$var(SIZE)");
if( $var(SIZE) >= $avp(s:quota) ){
sl_send_reply("503", "Simultaneous calls limit
reached");
xlog("DEBUG: Limit of $var(SIZE) active calls has been reached for
$avp(s:username)\n");
exit;
}
set_dlg_profile("callquota","$avp(s:username)");
get_profile_size("callquota", "$avp(s:username)",
"$var(SIZE)");
xlog("DEBUG: there are now $var(SIZE) active calls for
$avp(s:username)\n");
On 10/2/11 12:00 PM, "Uri Shacked" <ushacked(a)gmail.com> wrote:
Hi,
I am trying to create concurrent calls limitations.
two questions:
1. should i use dialog module? or is there a better module?
2. i was trying to work with the dialog module, but didnt understand how and where to
configure the commands and which to use.... any examples or ideas?
BR,
Uri
_______________________________________________
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
_______________________________________________
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
10:50 a.m.
El Sun, 02 Oct 2011 21:03:38 -0500
Graham Wooden <graham(a)g-rock.net> escribió:
Hi Uri,
I just got done tailoring this exact concept with the dialog module (you may
have just read my posts).
Two tips here:
Due to a couple of bugs in the dialog module I'd suggest you to run this code
after the user auth has been successfull. You'll need to call dlg_manage()
function first.
The other bug makes the dialog not being freed if you send a sl reply generated
by the proxy. You should call t_newtran + t_reply to send a statefull reply to
the user.
8 Oct
8 Oct
10:44 p.m.
2011/10/3 Jon Bonilla <manwe(a)aholab.ehu.es>es>:
Due to a couple of bugs in the dialog module I'd
suggest you to run this code
after the user auth has been successfull. You'll need to call dlg_manage()
function first.
The other bug makes the dialog not being freed if you send a sl reply generated
by the proxy. You should call t_newtran + t_reply to send a statefull reply to
the user.
Mixing two points above into a single one:
- Just call dlg_manage() after the authentication and authorization
has been made.
As a recommendation, call dlg_manage() just before t_relay() and you
are done (and you will avoid both bugs explained by Jon).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
9 Oct
9 Oct
4:03 a.m.
Am 08.10.2011 um 21:44 schrieb Iñaki Baz Castillo:
2011/10/3 Jon Bonilla <manwe(a)aholab.ehu.es>es>:
This works around most issues w.r.t. to the dialog module. However, there's at least
one case which cannot be covered: If a proxy behind the one tracking a dialog returns a
status code that must not render the dialog as failed (e.g., 407), as of the current
implementation the dialog *will* transition into the failure state. According to the
standard, this must not occur.
As explained by myself in Flyspray issue #146[1], a fix to this problem is quite feasible.
Overall, I believe that dialog module usage should be more robust and work out of the box;
that is, it shouldn't matter where you place dlg_manage(), things should just work and
handle the tricky cases intelligently. That's something for the long run though. For
the time being, the two hints you gave can definitely be considered good practice
regarding the dialog module.
Cheers,
--Timo
[1] http://sip-router.org/tracker/index.php?do=details&task_id=146
Due to a couple of bugs in the dialog module
I'd suggest you to run this code
after the user auth has been successfull. You'll need to call dlg_manage()
function first.
The other bug makes the dialog not being freed if you send a sl reply generated
by the proxy. You should call t_newtran + t_reply to send a statefull reply to
the user.
Mixing two points above into a single one:
- Just call dlg_manage() after the authentication and authorization
has been made.
As a recommendation, call dlg_manage() just before t_relay() and you
are done (and you will avoid both bugs explained by Jon). 
10 Oct
10 Oct
6:53 p.m.
On 10/8/2011 6:03 PM, Timo Reimann wrote:
As explained by myself in Flyspray issue #146[1], a fix to this problem is
quite feasible. Overall, I believe that dialog module usage should be more
robust and work out of the box; that is, it shouldn't matter where you place
dlg_manage(), things should just work and handle the tricky cases
intelligently.
I'm sure the developers would welcome you to submit a patch.
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
http://www.bendsource.com/
C - (541) 408-5189
O - (541) 323-9113
H - (541) 323-4219
7:14 p.m.
On Monday 10 October 2011, Jim Lucas wrote:
Hi Jim,
Timo is the one developer which has spend the most time with the dialog module
in the last months, IMHO. ;-)
Best regards,
Henning
As explained
by myself in Flyspray issue #146[1], a fix to this problem
is quite feasible. Overall, I believe that dialog module usage should be
more robust and work out of the box; that is, it shouldn't matter where
you place dlg_manage(), things should just work and handle the tricky
cases intelligently.
I'm sure the developers would welcome you to submit a patch.
7:20 p.m.
2011/10/10 Jim Lucas <lists(a)cmsws.com>om>:
On 10/8/2011 6:03 PM, Timo Reimann wrote:
Humm, Time *is* the developer here ;)
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
As explained by myself in Flyspray issue #146[1], a fix to this problem is
quite feasible. Overall, I believe that dialog module usage should be more
robust and work out of the box; that is, it shouldn't matter where you place
dlg_manage(), things should just work and handle the tricky cases
intelligently.
I'm sure the developers would welcome you to submit a patch.
8 p.m.
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
2011/10/10 Jim Lucas <lists(a)cmsws.com>om>:
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else should
develop it.
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
http://www.bendsource.com/
C - (541) 408-5189
O - (541) 323-9113
H - (541) 323-4219
On 10/8/2011 6:03 PM, Timo Reimann wrote:
Humm, Time *is* the developer here ;)
As explained by myself in Flyspray issue #146[1], a fix to this problem is
quite feasible. Overall, I believe that dialog module usage should be more
robust and work out of the box; that is, it shouldn't matter where you place
dlg_manage(), things should just work and handle the tricky cases
intelligently.
I'm sure the developers would welcome you to submit a patch.
8:15 p.m.
On 10.10.2011 19:00, Jim Lucas wrote:
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
Humm, Time *is* the developer here ;)
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else
should
develop it.
Check the Flyspray issue linked before and see who reported and is
assigned to the bug. Hint: It involves me. :)
Cheers,
--Timo
2011/10/10 Jim Lucas <lists(a)cmsws.com>om>:
> On 10/8/2011 6:03 PM, Timo Reimann wrote:
>>
>> As explained by myself in Flyspray issue #146[1], a fix to this
problem
is
>> quite feasible. Overall, I believe that
dialog module usage should
be more
>> robust and work out of the box; that is,
it shouldn't matter where
you place
dlg_manage(), things should just work and handle the
tricky cases
intelligently.
I'm sure the developers would welcome you to submit a patch.
8:53 p.m.
Not only that, but the fix is not trivial. Contrary to how it may appear to a
non-developer, this problem cannot be solved by just making a little patch.
Stateless replies have that name for a reason; they lack state. They don't trigger
any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a
dialog to which a stateless final failure reply has been sent is actually quite difficult,
and requires significant architectural changes.
--
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 10, 2011, at 1:00 PM, Jim Lucas <lists(a)cmsws.com> wrote:
On 10/10/2011 9:20 AM, Iñaki Baz Castillo wrote:
2011/10/10 Jim Lucas <lists(a)cmsws.com>om>:
My apologies to Timo.
The way he said it, I read that as he was suggesting that someone else should
develop it.
--
Jim Lucas
http://www.cmsws.com/
http://www.cmsws.com/examples/
http://www.bendsource.com/
C - (541) 408-5189
O - (541) 323-9113
H - (541) 323-4219
_______________________________________________
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 On 10/8/2011 6:03 PM, Timo Reimann wrote:
Humm, Time *is* the developer here ;)
As explained by myself in Flyspray issue #146[1], a fix to this problem is
quite feasible. Overall, I believe that dialog module usage should be more
robust and work out of the box; that is, it shouldn't matter where you place
dlg_manage(), things should just work and handle the tricky cases
intelligently.
I'm sure the developers would welcome you to submit a patch. 
9:03 p.m.
Alex Balashov writes:
Stateless replies have that name for a reason; they
lack state. They
don't trigger any TM callbacks that the dialog module can latch onto.
So, figuring out how to remove a dialog to which a stateless final
failure reply has been sent is actually quite difficult, and requires
significant architectural changes.
one can always use sems to limit number of simultaneous calls (see
cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with
right tool (= sbc) than to try to twist sip proxy to do something that
it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying,
topology hiding, reliable accounting, anonymity, etc. with one single
tool.
-- juha
9:56 p.m.
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance
and stability with a large number of calls. We are rather fond of the proxy-based
approach because it works, and works well.
--
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 10, 2011, at 2:03 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Alex Balashov writes:
Stateless replies have that name for a reason;
they lack state. They
don't trigger any TM callbacks that the dialog module can latch onto.
So, figuring out how to remove a dialog to which a stateless final
failure reply has been sent is actually quite difficult, and requires
significant architectural changes.
one can always use sems to limit number of simultaneous calls (see
cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with
right tool (= sbc) than to try to twist sip proxy to do something that
it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying,
topology hiding, reliable accounting, anonymity, etc. with one single
tool.
-- juha
_______________________________________________
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 
10:34 p.m.
Alex,
We've had huge performance and stability issues with SEMS in the past as
well, but together with the Frafos guys we've brought version 1.4 with
thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of
parallel calls without issues for months now. Load tests have shown that
we can run it with >100 caps and tens of thousands of parallel calls
over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have had a
lot of problems with SEMS performance and stability with a large number of calls. We are
rather fond of the proxy-based approach because it works, and works well.
--
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 10, 2011, at 2:03 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
Alex Balashov writes:
_______________________________________________
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 Stateless replies have that name for a reason;
they lack state. They
don't trigger any TM callbacks that the dialog module can latch onto.
So, figuring out how to remove a dialog to which a stateless final
failure reply has been sent is actually quite difficult, and requires
significant architectural changes.
one can always use sems to limit number of simultaneous calls (see
cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with
right tool (= sbc) than to try to twist sip proxy to do something that
it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying,
topology hiding, reliable accounting, anonymity, etc. with one single
tool.
-- juha
_______________________________________________
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
10:37 p.m.
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged signaling-only, I
assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a respectable
number of streams concurrently, for a userspace process, and is easy to horizontally scale
by just adding more rtpproxies to the set, and/or binding additional instances to
additional CPU cores.
--
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 10, 2011, at 3:34 PM, Andreas Granig <agranig(a)sipwise.com> wrote:
Alex,
We've had huge performance and stability issues with SEMS in the past as
well, but together with the Frafos guys we've brought version 1.4 with
thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of
parallel calls without issues for months now. Load tests have shown that
we can run it with >100 caps and tens of thousands of parallel calls
over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have
had a lot of problems with SEMS performance and stability with a large number of calls.
We are rather fond of the proxy-based approach because it works, and works well.
--
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 10, 2011, at 2:03 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
_______________________________________________
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 Alex Balashov writes:
_______________________________________________
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 Stateless replies have that name for a reason;
they lack state. They
don't trigger any TM callbacks that the dialog module can latch onto.
So, figuring out how to remove a dialog to which a stateless final
failure reply has been sent is actually quite difficult, and requires
significant architectural changes.
one can always use sems to limit number of simultaneous calls (see
cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with
right tool (= sbc) than to try to twist sip proxy to do something that
it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying,
topology hiding, reliable accounting, anonymity, etc. with one single
tool.
-- juha
_______________________________________________
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
11 p.m.
Alex,
We use our own kernel-based mediaproxy in our systems, so I can't tell
much about rtpproxy, beside that our ngcp-mediaproxy-ng uses the same
control protocol (or a basic sub-set of it, e.g. no recording or stream
forking etc), so you can use it as drop-in replacement of rtpproxy.
See http://deb.sipwise.com/spce/2.2/pool/main/n/ngcp-mediaproxy-ng/ ,
it's part of the open-source sip:provider CE system
(http://www.sipwise.com/products/spce/), which uses kamailio, sems and
mediaproxy-ng for SIP and RTP.
Andreas
On 10/10/2011 09:37 PM, Alex Balashov wrote:
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged signaling-only, I
assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a respectable
number of streams concurrently, for a userspace process, and is easy to horizontally scale
by just adding more rtpproxies to the set, and/or binding additional instances to
additional CPU cores.
--
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 10, 2011, at 3:34 PM, Andreas Granig <agranig(a)sipwise.com> wrote:
Alex,
We've had huge performance and stability issues with SEMS in the past as
well, but together with the Frafos guys we've brought version 1.4 with
thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of
parallel calls without issues for months now. Load tests have shown that
we can run it with >100 caps and tens of thousands of parallel calls
over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
_______________________________________________
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 In theory, this sounds appealing. But we have
had a lot of problems with SEMS performance and stability with a large number of calls.
We are rather fond of the proxy-based approach because it works, and works well.
--
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 10, 2011, at 2:03 PM, Juha Heinanen <jh(a)tutpro.com> wrote:
_______________________________________________
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 Alex Balashov writes:
> Stateless replies have that name for a reason; they lack state. They
> don't trigger any TM callbacks that the dialog module can latch onto.
> So, figuring out how to remove a dialog to which a stateless final
> failure reply has been sent is actually quite difficult, and requires
> significant architectural changes.
one can always use sems to limit number of simultaneous calls (see
cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with
right tool (= sbc) than to try to twist sip proxy to do something that
it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying,
topology hiding, reliable accounting, anonymity, etc. with one single
tool.
-- juha
_______________________________________________
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
_______________________________________________
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
11 Oct
11 Oct
11:52 a.m.
Hey Alex,
On 10.10.2011 19:53, Alex Balashov wrote:
Not only that, but the fix is not trivial. Contrary
to how it may
appear to a non-developer, this problem cannot be solved by just making
a little patch.
Stateless replies have that name for a reason; they lack state. They
don't trigger any TM callbacks that the dialog module can latch onto.
So, figuring out how to remove a dialog to which a stateless final
failure reply has been sent is actually quite difficult, and requires
significant architectural changes.
Agreed that fixing the issue for locally sent responses is somewhat
tricky. Apart from trying to link stateless responses to transactions,
however, there are other, less perfect solutions. For instance, you
could allow reusing dialogs on arrival of a subsequent INVITE if the
initial INVITE wasn't forwarded yet (and therefore must have been
replied to locally). It's probably not trivial to implement but keeps
the required modifications to a single module.
Then again, you can work around such cases by not tracking dialogs for
which you know you are going to respond statelessly to (and therefore
require no tracking) in the first place. It's not perfectly elegant from
a usability point of view but it works.
By the way, I came across this bug from a specific scenario where
authentication takes place behind the dialog-tracking proxy; that is, a
407 was received from upstream and forwarded back to the caller. In such
scenarios, the approach I devised in the bug report should do well and
not involve too much work.
Cheers,
--Timo
4794
days inactive
4803
days old
17 comments
10 participants
participants (10)
-
Alex Balashov -
Andreas Granig -
Graham Wooden -
Henning Westerholt -
Iñaki Baz Castillo -
Jim Lucas -
Jon Bonilla -
Juha Heinanen -
Timo Reimann -
Uri Shacked