<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-6" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
Nils Ohlmeier wrote:
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap="">On Monday 16 July 2007 14:04:31 Greger V. Teigre wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Ok, let me try to take a step back. This discussion is an example of why
ser.cfg sometimes seems like black magic for most users. It's very
complicated to get a generic config that works in most scenarios. What
we really need to make sure is that people can use the recommended black
magic in most cases, that it is intuitive how to add their own stuff,
and that we make it difficult to "break".. phew...
What would a "normal" user like to know in ser.cfg?
1. Do I need to process like an INVITE or do I t_relay?
2. How do I open or prevent relaying?
Ex. I am sure quite a lot of configs will let an INVITE with a
pre-loaded Route go through without authentication...
</pre>
</blockquote>
<pre wrap=""><!---->
Which is not an issue as long as the RURI points to you. Because then you
simply route the request to yourself with no Route header any more, and then
it should be processed like a request without pre-loaded Route.
</pre>
</blockquote>
Right, but I was referring to the case where the ruri does not point to
you, but (most probably) a PSTN GW.<br>
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">I still feel that preloaded_route() and in_dialog() would be simpler to
understand for most people.
</pre>
</blockquote>
<pre wrap=""><!---->
Just to state it clearly: the names of these two function can not be
implemented technically correct! Thus I would vote at least against the
names.
</pre>
</blockquote>
I assume you here implicitly mean that they cannot be implemented
technically correct for both stateful and stateless? I assumed in my
suggestion that we can make an rr param work.<br>
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap="">If you use has_to_tag(), fine you should know what you are doing. But
in_dialog() without being dialog statefull promisses to much.
</pre>
</blockquote>
Right, so maybe in_dialog should be found in tm?<br>
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">I agree with Martin that maybe having a
separate function checking/removing/failing a pre-loaded route is
cleaner than letting loose_route() do it.
</pre>
</blockquote>
<pre wrap=""><!---->
Ok. I'm still trying to evaluate if this is possible or not. See below for
more details. But we are talking here about > 2.0 any way, right?
</pre>
</blockquote>
Indeed.<br>
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">The problem of "non-2xx ACK with a preloaded route looks exactly the
same then a 2xx ACK" is a corner-case, and I don't see any solution
either, than the suggest uri param in the rr.
</pre>
</blockquote>
<pre wrap=""><!---->
Just to make it clear to everybody: this "corner case" occurs in all setups
with a stateless load balancer and where the INVITE gets challenged!
</pre>
</blockquote>
Yes, "corner case" was maybe misphrased. My point was that it does not
occur in every setup.<br>
<blockquote cite="mid:200707161653.52650.nils@iptel.org" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">So, could we
automaticlly add the rr param if and only if the original INVITE is
forwarded statelessly?
</pre>
</blockquote>
<pre wrap=""><!---->
I don't think so, because the rr module has no idea when you call
record_route() how the request is going to be tramsitted.
</pre>
</blockquote>
Isn't uri params implemented differently in 2.0? Where the actual
params are added before relaying (based on avp)?<br>
<br>
g-)
</body>
</html>