<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
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...<br>
<br>
What would a "normal" user like to know in ser.cfg? <br>
1. Do I need to process like an INVITE or do I t_relay?<br>
2. How do I open or prevent relaying?<br>
<br>
Ex. I am sure quite a lot of configs will let an INVITE with a
pre-loaded Route go through without authentication...<br>
<br>
I still feel that preloaded_route() and in_dialog() would be simpler to
understand for most people. 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.<br>
<br>
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. So, could we
automaticlly add the rr param if and only if the original INVITE is
forwarded statelessly?<br>
The above functions could thus look for the rr param to detect the
corner-case and thus behave consistently.<br>
g-)<br>
<br>
Martin Hoffmann wrote:
<blockquote cite="mid:20070713140830.GA6098@m.hq.telio.no" type="cite">
<pre wrap="">Nils Ohlmeier wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Friday 13 July 2007 14:12:52 Martin Hoffmann wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Nils Ohlmeier wrote:
</pre>
</blockquote>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">But with this theory we are back to the original topic: is a TEL URI a
local URI or not.
</pre>
</blockquote>
<pre wrap="">I though that was solved. Only SIP and SIPS URI are allowed in Contact.
Your 2xx ACK will never have a TEL URI (unless the UA is broken in which
case someone should have sent a 400 back).
</pre>
</blockquote>
<pre wrap="">No. That is not true. Because you could receive a non-2xx ACK with a TEL RURI
and preloaded route. What now?
</pre>
</blockquote>
<pre wrap=""><!---->
Depends on what you do with an INVITE. Same thing shall be done to that
ACK. Which means you cannot have loose_route() decide for you.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Is just came to my mind that a possible solution could be to add some
kind of secret information to our Record-Route headers.
</pre>
</blockquote>
<pre wrap="">/me not like. Sounds like magic plus vendor specific extensions are
frowned upon in SIP.
</pre>
</blockquote>
<pre wrap="">Sure, they are. But I currently do not really see any option for this problem.
</pre>
</blockquote>
<pre wrap=""><!---->
Possibly, the problem is that loose_route() is trying to be smart. Maybe
it should be split in two. One function removes the topmost Route if
present and pointing to this proxy (it can return false if the Route is
all wrong and we can reply 4xx then), another one that allows to check
if there is a Route left. The rest is done in config.
Without reading 3261 again, I think this can be done in a way compatible
with strict routing.
Regards,
Martin
</pre>
</blockquote>
</body>
</html>