17 Jul
2007
17 Jul
'07
11:22 a.m.
In order to be treated as a special case in the script (with
uri~="tel:.*"), we will need the extra function to detect preloaded
routes.
JF
On 7/17/07, Nils Ohlmeier <nils(a)iptel.org> wrote:
On Monday 16 July 2007 12:06:40 Jiri Kuthan wrote:
At 09:26 12/07/2007, Martin Hoffmann wrote:
I'll try my best....
It was started by JF who pointed out that an INVITE with a TEL URI in the RURI
and a SIP URI as preloaded Route is not handled the same way by loose_route()
as other preloaded requests. The reason for this is that a TEL URI is not
detected/accepted as local URI.
If the RURI contains a local URI the handling is very easy, because you simply
can remove the Route header and forward the request to yourself. In the
second round the request should be treated as any other incoming request
without a preloaded route. Unfortunately this does not work in case of
non-local RURI's.
Then I tried to explain what was the motivation behind the change of the
loose_route() function for 2.0 (stateless handling of non-2xx preloaded ACKs
and 2xx ACKs - please see the thread for details).
Then the reasonable question was raised if preloaded requests should be
handled by the loose_route() function at all.
Currently I like Martin's proposal of having an extra function for preloaded
requests best. But
- a clean implemenatation of this is not easy
- still the only solution for distinguishing non-2xx preloaded ACKs from 2xx
ACKs seems to be a Route cookie (which can be omitted if your proxy is
statefull)
- all this discussion is IMO for SER version > 2.0
Besides this interesting discussion for future SER versions, the big open
question is: if and how we want to change/fix the original problem of JF?
Personally I do not like JFs proposal, because it "fixes" only his problem
with TEL URIs. But the general problem of having pre-loaded requests with
non-local or non-routeable RURIs is not solved by this.
Changing loose_route() in a way of not handling preloaded requests is a too
dramitcal change for the 2.0 release IMHO.
Introducing a To-tag check would be a faulty solution as well (as I explained
already that you can not distinguish a non-2xx preloaded ACK from a 2xx ACK
by this).
So I fear there is no optimal solution for this. Thus I would propose that we
just explain that this "special case" has to be considered by the script
writers.
Regards
Nils
_______________________________________________
Serdev mailing list
Serdev(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serdev
Nils Ohlmeier wrote:
I would say too that this is not a big exception but an insignificant one.
(Historians may wish to comment, that from the protocol design point of
view the positive ACK is just terribly insane in SIP, but for benefit of
the mailing list readers I will save you this ellaboration.)
The realization of the fact that the presence or
absence of To-tag is
not enough to decide if a request belongs to a dialog or not. The big
exception here is the ACK for negative replies. It has a To-tag but a
dialog was not established.
That is a non-issue. This ACK needs special treatment anyways -- it is
to be consumed by tm. Is there any argument against putting a
if (method == "ACK") {
t_relay();
drop();
}
somewhere way up in your config?
Haven't tried but it seems workable. It would have to be behind loose_route
(otherweise e2e ACK routed using record-routed logic would be routed
wrong.) hbh ACKs are absorbed by t_relay, e2e ACKs forwarded statelessly.
Anyhow, I got lost in the volume of this exciting debate. Can some of the
honorable gentlemen make me a massive favor and "destilate" for me, what
the problem is thought to be? (i.e., what does not work "as is")?