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 does not matter if the TEL URI is not re-written on the way to the GW.
Nils
JF
On 7/11/07, Nils Ohlmeier nils@iptel.org wrote:
Hi,
On Wednesday 11 July 2007 17:07:22 JF wrote:
The scenario was actually using an Application Server. The AS starts a call and sends an INVITE with tel URI to a SER which is the entrypoint to my SIP infrastructure. The AS uses this SER as outbound proxy, so it includes its SIP URI in a Route header.
The use-case for tel URI in the Req-URI here is that it will be the task of my SIP infrastructure to determine if this tel URI is associated to a SIP phone, or if it should be forwarded to a PSTN gw.
But your AS uses a SIP URI as Contact in the INVITE? And when the call is established either to a phone or the GW there will be no TEL URI any more in the dialog, right?
If you can answer both questions from above with yes, I would propose to add another check for the To-tag before we deviced if this is loose route driven or not. That should then hopefully solve your problem in a generic way without caring about the URI scheme.
Nils
JF
On 7/11/07, Nils Ohlmeier nils@iptel.org wrote:
Hello,
I think the TEL URI was invented to make the live easier for PSTN gateways. So they should only be used between proxy's and gateways (or vice versa). This also means that a TEL URI should not be used routing between SIP proxies. IMHO basically the first fully SIP aware hop should turn the TEL URI into a SIP URI. That makes life of everybody easier.
So I think that treating a TEL URI as a local URI (as if it would have one of the local domains) is not the correct solution.
To understand the scenario a little bit better: in this an in-dialog request with a To-tag (then I'm wondering how this can happen), or is this an initial request without a To-tag (the devices uses your proxy as outbound proxy)?
Regards Nils
On Thursday 28 June 2007 17:13:43 JF wrote:
I would propose to simply apply this patch to modules/rr/loose.c:
@@ -1069,8 +1069,8 @@ return -1; }
if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)|| _m->parsed_uri.type==TEL_URI_T ||_m->parsed_uri.type==TELS_URI_T) {
if (_m->parsed_uri.type==TEL_URI_T ||_m->parsed_uri.type==TELS_URI_T || + is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)) { DBG("loose_route: RURI is myself (or tel URI)\n"); if ((ret = is_myself(&puri.host, puri.port_no)) == 1 && !(enable_double_rr && is_2rr(&puri.params))) {
JF
On 6/22/07, Greger Viken Teigre greger@teigre.com wrote:
This seems like a corner case where the tel uri with no domain results in maybe a bit unfortunate return code from loose_route. Comments anyone? g-)