4 Jul
2011
4 Jul
'11
1:43 p.m.
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
4 Jul
4 Jul
1:46 p.m.
$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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
1:53 p.m.
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
1:59 p.m.
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.
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
2:08 p.m.
Am 04.07.2011 13:59, schrieb Alex Balashov:
On 07/04/2011 07:53 AM, Klaus Darilion wrote:
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
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. 
2:26 p.m.
2011/7/4 Klaus Darilion <klaus.mailinglists(a)pernau.at>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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:37 p.m.
On 07/04/2011 08:26 AM, Iñaki Baz Castillo wrote:
2011/7/4 Klaus
Darilion<klaus.mailinglists(a)pernau.at>at>:
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";
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
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.
2:38 p.m.
On 07/04/2011 08:37 AM, Alex Balashov wrote:
On 07/04/2011 08:26 AM, Iñaki Baz Castillo wrote:
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
2011/7/4 Klaus
Darilion<klaus.mailinglists(a)pernau.at>at>:
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"; 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.
2:47 p.m.
On 07/04/2011 08:44 AM, Iñaki Baz Castillo wrote:
2011/7/4 Alex
Balashov<abalashov(a)evaristesys.com>om>:
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. :-)
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
Right, but would be cooler a pv? :)
2:54 p.m.
2011/7/4 Alex Balashov <abalashov(a)evaristesys.com>om>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
2:57 p.m.
Alex Balashov wrote:
On 07/04/2011 08:44 AM, Iñaki Baz Castillo wrote:
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
2011/7/4 Alex
Balashov<abalashov(a)evaristesys.com>om>:
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?
Or rather:
$var(scheme) = $(ru{s.select,0,:});
(had the index and separator arguments reversed)
Right, but would be cooler a pv? :)
3:10 p.m.
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?
--
Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
3:21 p.m.
Am 04.07.2011 15:10, schrieb Alex Balashov:
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
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_l…
I guess the uri subelement "type" would be the URI scheme, e.g: @ruri.type
Note: selects are read-only.
regards
Klaus
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?
3:22 p.m.
Alex Balashov wrote:
I was about to write a lengthy mail but, lucky for me:
http://sip-router.org/wiki/ref_manual/selects
Regards,
Martin
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
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.
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?
3:42 p.m.
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:
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda
On 07/04/2011 08:57 AM, Martin Hoffmann wrote:
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.
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?
3:15 p.m.
Am 04.07.2011 14:26, schrieb Iñaki Baz Castillo:
2011/7/4 Klaus Darilion
<klaus.mailinglists(a)pernau.at>at>:
Indeed. In my case I do not care anyway. I have to use sip: as the
gateway does not support TLS :-)
klaus
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.
3:40 p.m.
2011/7/4 Klaus Darilion <klaus.mailinglists(a)pernau.at>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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
1:48 p.m.
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 - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
1:51 p.m.
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;
4901
days inactive
4901
days old
19 comments
5 participants
participants (5)
-
Alex Balashov -
Daniel-Constantin Mierla -
Iñaki Baz Castillo -
Klaus Darilion -
Martin Hoffmann