Nils Ohlmeier wrote:
On Wednesday 11 July 2007 17:35:39 JF wrote:
Answer to 1st question: Yes.
Ok
Answer to 2nd question: if the call is routed to a SIP phone, the Req-URI is rewritten with an appropriate SIP URI (not necessarily sip:number_in_tel_uri@mydomain). If it goes to a PSTN gw, it is kept unchanged as a tel URI.
Ok, but for further in-dialog routing of the message between your AS and the GW the Contact's of the AS and the GW are important. As long none of these two uses a TEL URI Contact (which would be IMHO totally stupid),
It would not only be stupid, it would be illegal.
.--[RFC 3261, section 8.1.1.8]-- | | The Contact header field MUST be present and contain exactly one SIP | or SIPS URI in any request that can result in the establishment of a | dialog. | `--
it does not matter if the TEL URI is not re-written on the way to the GW.
Indeed. The only way loose_route() can end up using tel URIs is when someone preloaded a message with a Route header and used a tel URI as Request-URI, which is perfectly legal.
As for the return value of loose_route(), behaviour has changed over time a bit. In 0.8 it used to return true only if there was yet another Route header, ie., it returned false if this proxy was the last one in the chain of record routing. This changed sometime in 0.9 to the current behaviour to return true whenever there the topmost Route is this proxy.
In most cases this is what you want, because the presence of Routes indicates an in-dialog message which you want to treat differently (In practice, most UAs just forward the message to the outgoing proxy without adding a Route header, which is perfectly legal as well). The proper test for this, of course, is to check for the presence of a To tag. But it seems to be common to all SER configs I have seen to misuse loose_route() in this way.
Changing the behaviour of loose_route() yet again would mess up a lot of configs as the earlier change messed up a lot of configs (it certainly cost me a couple of hours debugging). Having another function would probably be a better approach. Especially, since loose_route() is actually the wrong name. The function does both loose and static record routing.
Regards, Martin