version: kamailio 3.1.4 (i386/linux)
FAILURE_ROUTE:
xlogl("L_NOTICE","failure to PSTN gateway: Call to $ru\n"); $rd = "81.209.128.132:5060"; xlogl("L_NOTICE","next gateway. Call to $ru\n"); route(RELAY);
results in:
NOTICE: <script>: 1089:failure to PSTN gateway: Call to sip:00431505641636@1.2.3.4:5060 ERROR: pv [pv_core.c:186]: failed to parse the R-URI NOTICE: <script>: 1097:next gateway. Call to <null> ... ERROR: uri2dst: bad_uri: sip:00431505641636@81.209.128.132:5060:5060
Looks like the assignment to $rd is buggy (double port)
regards klaus
$rd is only the host part of the r-uri, you add also port there. I guess same happens if you do rewritehost() with host and port.
If you want to update the port as well, then use $rp in a second assignment.
Cheers, Daniel
On 7/4/11 1:43 PM, Klaus Darilion wrote:
version: kamailio 3.1.4 (i386/linux)
FAILURE_ROUTE:
xlogl("L_NOTICE","failure to PSTN gateway: Call to $ru\n"); $rd = "81.209.128.132:5060"; xlogl("L_NOTICE","next gateway. Call to $ru\n"); route(RELAY);
results in:
NOTICE:<script>: 1089:failure to PSTN gateway: Call to sip:00431505641636@1.2.3.4:5060 ERROR: pv [pv_core.c:186]: failed to parse the R-URI NOTICE:<script>: 1097:next gateway. Call to<null> ... ERROR: uri2dst: bad_uri: sip:00431505641636@81.209.128.132:5060:5060
Looks like the assignment to $rd is buggy (double port)
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Is there a method to replace the whole part after the @ with a single assignment (setting domain,port and parameters)?
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
Thanks Klaus
Am 04.07.2011 13:46, schrieb Daniel-Constantin Mierla:
$rd is only the host part of the r-uri, you add also port there. I guess same happens if you do rewritehost() with host and port.
If you want to update the port as well, then use $rp in a second assignment.
Cheers, Daniel
On 7/4/11 1:43 PM, Klaus Darilion wrote:
version: kamailio 3.1.4 (i386/linux)
FAILURE_ROUTE:
xlogl("L_NOTICE","failure to PSTN gateway: Call to $ru\n"); $rd = "81.209.128.132:5060"; xlogl("L_NOTICE","next gateway. Call to $ru\n"); route(RELAY);
results in:
NOTICE:<script>: 1089:failure to PSTN gateway: Call to sip:00431505641636@1.2.3.4:5060 ERROR: pv [pv_core.c:186]: failed to parse the R-URI NOTICE:<script>: 1097:next gateway. Call to<null> ... ERROR: uri2dst: bad_uri: sip:00431505641636@81.209.128.132:5060:5060
Looks like the assignment to $rd is buggy (double port)
regards klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
On 07/04/2011 07:53 AM, Klaus Darilion wrote:
Is there a method to replace the whole part after the @ with a single assignment (setting domain,port and parameters)?
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
There is rewritehostport(). But if you have PV arguments, I don't know if it will take them.
Am 04.07.2011 13:59, schrieb Alex Balashov:
On 07/04/2011 07:53 AM, Klaus Darilion wrote:
Is there a method to replace the whole part after the @ with a single assignment (setting domain,port and parameters)?
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
There is rewritehostport(). But if you have PV arguments, I don't know if it will take them.
Actually I try to replace rewritehostport as it also leaves the URI parameters untouched.
E.g. If client sent sip:004312345@domain;transport=tls the transport parameter would survive. Thus I need to replace the parameters as well.
regards Klaus
2011/7/4 Klaus Darilion klaus.mailinglists@pernau.at:
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
This would be a bit hack as, for now, there is no way to know which URI schema (sip or sips) has the RURI (there is no a pv for it). So if you are forcing "sip:" you could break something if the original RURI had "sips" schema.
On 07/04/2011 08:26 AM, Iñaki Baz Castillo wrote:
2011/7/4 Klaus Darilionklaus.mailinglists@pernau.at:
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
This would be a bit hack as, for now, there is no way to know which URI schema (sip or sips) has the RURI (there is no a pv for it). So if you are forcing "sip:" you could break something if the original RURI had "sips" schema.
This affects a relatively small minority of users who actually use SIP-TLS :-) but, I suppose one could work around it thusly:
$var(scheme) = $(ru{s.select,:,0}); $ru = $var(scheme) + $rU + "@1.2.3.4:5060";
On 07/04/2011 08:37 AM, Alex Balashov wrote:
On 07/04/2011 08:26 AM, Iñaki Baz Castillo wrote:
2011/7/4 Klaus Darilionklaus.mailinglists@pernau.at:
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
This would be a bit hack as, for now, there is no way to know which URI schema (sip or sips) has the RURI (there is no a pv for it). So if you are forcing "sip:" you could break something if the original RURI had "sips" schema.
This affects a relatively small minority of users who actually use SIP-TLS :-) but, I suppose one could work around it thusly:
$var(scheme) = $(ru{s.select,:,0}); $ru = $var(scheme) + $rU + "@1.2.3.4:5060";
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
2011/7/4 Alex Balashov abalashov@evaristesys.com:
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
Right, but would be cooler a pv? :)
On 07/04/2011 08:44 AM, Iñaki Baz Castillo wrote:
2011/7/4 Alex Balashovabalashov@evaristesys.com:
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
Right, but would be cooler a pv? :)
I think part of the philosophical problem is that it is generally desirable to keep uniform PV coverage for components of various headers and URIs. So, the question would come up: if there is a PV for the RURI scheme, why not have PVs for the scheme of various other URIs, such as From, To, RPID, whatever, etc?
And suddenly we'd end up with a bunch more pollution of the PV space that consists of basically useless functionality for the sake of conceptual integrity. :-)
2011/7/4 Alex Balashov abalashov@evaristesys.com:
I think part of the philosophical problem is that it is generally desirable to keep uniform PV coverage for components of various headers and URIs. So, the question would come up: if there is a PV for the RURI scheme, why not have PVs for the scheme of various other URIs, such as From, To, RPID, whatever, etc?
And suddenly we'd end up with a bunch more pollution of the PV space that consists of basically useless functionality for the sake of conceptual integrity. :-)
From a proxy point of view, inspecting the kind of schema of the RURI
(or of the topmost Route header) is important as routing rules could change depending on it.
Maybe there could be a generic URI transformation like {uri.schema}. However it would require (if I'm not wrong) Sip-Router to re-parse again the RURI just to get the schema.
Alex Balashov wrote:
On 07/04/2011 08:44 AM, Iñaki Baz Castillo wrote:
2011/7/4 Alex Balashovabalashov@evaristesys.com:
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
Right, but would be cooler a pv? :)
I think part of the philosophical problem is that it is generally desirable to keep uniform PV coverage for components of various headers and URIs. So, the question would come up: if there is a PV for the RURI scheme, why not have PVs for the scheme of various other URIs, such as From, To, RPID, whatever, etc?
Am I the only one who cringes at $(ru{s.select,0,:}) and a few other PV constructs?
SER 2.x had this nice concept of hierarchic select. What happened to that?
Regards, Martin
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
Am I the only one who cringes at $(ru{s.select,0,:}) and a few other PV constructs?
On an aesthetic basis purely?
SER 2.x had this nice concept of hierarchic select. What happened to that?
For those coming from the OpenSER/Kamailio universe, can you elaborate on how these worked?
Am 04.07.2011 15:10, schrieb Alex Balashov:
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
Am I the only one who cringes at $(ru{s.select,0,:}) and a few other PV constructs?
On an aesthetic basis purely?
SER 2.x had this nice concept of hierarchic select. What happened to that?
For those coming from the OpenSER/Kamailio universe, can you elaborate on how these worked?
They are still available, e.g I use selects to get RR cookies:
if (@msg.header.Route[1].nameaddr.uri.params["nat"] == "both") {
Full list of selects is available here: http://sip-router.org/docbook/sip-router/branch/master/select_list/select_li...
I guess the uri subelement "type" would be the URI scheme, e.g: @ruri.type
Note: selects are read-only.
regards Klaus
Alex Balashov wrote:
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
Am I the only one who cringes at $(ru{s.select,0,:}) and a few other PV constructs?
On an aesthetic basis purely?
Mostly. It is kinda hard to read and figure out. I know how all this came to be, but I'd really would have preferred a syntax like s.select($ru, 0, ':'), even though that still isn't very self-explaining.
SER 2.x had this nice concept of hierarchic select. What happened to that?
For those coming from the OpenSER/Kamailio universe, can you elaborate on how these worked?
I was about to write a lengthy mail but, lucky for me:
http://sip-router.org/wiki/ref_manual/selects
Regards, Martin
Several notes in the context of the whole discussion: - setting hostport and everything after @ are well defined operations specified internally but not exported to work as a variable -- should be easy to code, just needs a developer to do it :-) - selects are still there as mentioned by Klaus, as separate framework. They can be accessed through PV framework as well, so @whatsoever is the same as $sel(whatsoever) - transformations were intended to be chained in a simple way:
$(name{trans1}{trans2}...{transN}) - it is a valid syntax applying trans1 ... to transN to the value of variable $name. Besides that, they are working in xlog parameters, so you don't need to build the value of parameter before or do concat expressions as parameters. In other words, transformations are part of PV specification.
Cheers, Daniel
On 7/4/11 3:22 PM, Martin Hoffmann wrote:
Alex Balashov wrote:
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
Am I the only one who cringes at $(ru{s.select,0,:}) and a few other PV constructs?
On an aesthetic basis purely?
Mostly. It is kinda hard to read and figure out. I know how all this came to be, but I'd really would have preferred a syntax like s.select($ru, 0, ':'), even though that still isn't very self-explaining.
SER 2.x had this nice concept of hierarchic select. What happened to that?
For those coming from the OpenSER/Kamailio universe, can you elaborate on how these worked?
I was about to write a lengthy mail but, lucky for me:
http://sip-router.org/wiki/ref_manual/selects
Regards, Martin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Am 04.07.2011 14:26, schrieb Iñaki Baz Castillo:
2011/7/4 Klaus Darilion klaus.mailinglists@pernau.at:
I want to avoid: $ru = "sip:" + $rU + "@" + "1.2.3.4:5060";
This would be a bit hack as, for now, there is no way to know which URI schema (sip or sips) has the RURI (there is no a pv for it). So if you are forcing "sip:" you could break something if the original RURI had "sips" schema.
Indeed. In my case I do not care anyway. I have to use sip: as the gateway does not support TLS :-)
klaus
2011/7/4 Klaus Darilion klaus.mailinglists@pernau.at:
Indeed. In my case I do not care anyway. I have to use sip: as the gateway does not support TLS :-)
This is not entire true. A request can contain a RURI with sips schema even if it's sent via UDP or TCP (for example there could be a topmost Route with sip scheme). It's also valid in the case of a registrar which receives a request for an AoR with sips and must inspect in the registration backend for such AoR, no matter it's registered with a sip or sips address.
On 07/04/2011 07:43 AM, Klaus Darilion wrote:
NOTICE:<script>: 1089:failure to PSTN gateway: Call to sip:00431505641636@1.2.3.4:5060 ERROR: pv [pv_core.c:186]: failed to parse the R-URI NOTICE:<script>: 1097:next gateway. Call to<null> ... ERROR: uri2dst: bad_uri: sip:00431505641636@81.209.128.132:5060:5060
Looks like the assignment to $rd is buggy (double port)
It had always been my understanding--and my experience--that $rd governs the domain portion of the Request URI only, _not_ including port. Port is handled by a different PV: $rp. Thus, the correct assignment would be:
$rd = 81.209.128.132; $rp = 5060;
Uppss, thanks.
Sorry for the noise Klaus
Am 04.07.2011 13:48, schrieb Alex Balashov:
On 07/04/2011 07:43 AM, Klaus Darilion wrote:
NOTICE:<script>: 1089:failure to PSTN gateway: Call to sip:00431505641636@1.2.3.4:5060 ERROR: pv [pv_core.c:186]: failed to parse the R-URI NOTICE:<script>: 1097:next gateway. Call to<null> ... ERROR: uri2dst: bad_uri: sip:00431505641636@81.209.128.132:5060:5060
Looks like the assignment to $rd is buggy (double port)
It had always been my understanding--and my experience--that $rd governs the domain portion of the Request URI only, _not_ including port. Port is handled by a different PV: $rp. Thus, the correct assignment would be:
$rd = 81.209.128.132; $rp = 5060;
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Martin Hoffmann