On 4/10/13 1:25 PM, Iñaki Baz Castillo wrote:
Please, RFC 5626 is the solution for NAT.
I thought Olle was about to agree, except the RFC number
being in fact 2460 :)
jiri
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
José Luis Millán writes:
> That is a wrong formed URI but a right formed URI parameter. The right URI
> format for the above is:
>
> sip:192.98.102.11:35453;transport=tcp
>
> While the right format for the same info when it is used as an URI
> parameter is:
>
> sip:192.98.102.11:35453%3Btranspo
Remember that Outbound also works for UDP. In that case:
a) The Outbound Flow Token (the URI username in the Record-Route) must
encode the public source IP:port of the request, and the Outbound
proxy must be capable of encoding and decoding it for routing the
request to the client (OverSIP does it
10 apr 2013 kl. 15:32 skrev Peter Dunkley :
> When using a non-outbound client like Jitsi you can keep-alive by getting it
> to re-REGISTER, OPTIONS ping, or '\r\n' frequently.
>
> IMHO that is far better solution than having the server run timers and
> generate keep-alives.
>
> Regards,
>
>
Olle E. Johansson writes:
> > Who does keep-alive when outbound is used? If it is the client, then
> > there still must be some tweaks in the server as the non-outbound
> > client will not send keep-alive.
>
> Outbound puts all the client connection management burden upon the
> client.
yes, but
When using a non-outbound client like Jitsi you can keep-alive by
getting it to re-REGISTER, OPTIONS ping, or '\r\n' frequently.
IMHO that is far better solution than having the server run timers and
generate keep-alives.
Regards,
Peter
On 10/04/13 13:53, Klaus Darilion wrote:
Who does keep
10 apr 2013 kl. 14:53 skrev Klaus Darilion :
>
>
> On 10.04.2013 12:58, Iñaki Baz Castillo wrote:
>> There is no need at all for clients to be Outbound aware. The proxy can
>> force it in the same way current "alias" / "contact mangling" /
>> "received stuff" is used.
>
> Who does keep-alive w
On 10.04.2013 12:58, Iñaki Baz Castillo wrote:
There is no need at all for clients to be Outbound aware. The proxy can
force it in the same way current "alias" / "contact mangling" /
"received stuff" is used.
Who does keep-alive when outbound is used? If it is the client, then
there still mu
2013/4/10 Juha Heinanen :
> Olle E. Johansson writes:
>
>> Can't you add and forward to yourself again? I do crazy stuff like that in
>> many places. Just loop around to force a new transaction with new headers.
>>
>> Just an idea. Maybe totally stupid.
>
> could be done, but it adds complexity and
10 apr 2013 kl. 13:09 skrev Juha Heinanen :
> Olle E. Johansson writes:
>
>> Can't you add and forward to yourself again? I do crazy stuff like that in
>> many places. Just loop around to force a new transaction with new headers.
>>
>> Just an idea. Maybe totally stupid.
>
> could be done, but
Olle E. Johansson writes:
> Can't you add and forward to yourself again? I do crazy stuff like that in
> many places. Just loop around to force a new transaction with new headers.
>
> Just an idea. Maybe totally stupid.
could be done, but it adds complexity and overhead. there is enough
time be
10 apr 2013 kl. 12:54 skrev Juha Heinanen :
> Peter Dunkley writes:
>
>> You can use the force_outbound option in the outbound module to make
>> path and rr add flow-tokens even when the client isn't doing outbound.
>
> thank for info. it may not work though, if registrar and edge proxy are
>
There is no need at all for clients to be Outbound aware. The proxy can
force it in the same way current "alias" / "contact mangling" / "received
stuff" is used.
--
Iñaki Baz Castillo
El 10/04/2013 12:44, "Juha Heinanen" escribió:
> Iñaki Baz Castillo writes:
>
> > Anyhow, why is the received s
Single server outbound is on my todo list. I have put the details of
what is needed here: http://www.kamailio.org/wiki/devel/completing_outbound
Don't know if or when I'll get time to do it though.
Regards,
Peter
On 10/04/13 11:54, Juha Heinanen wrote:
Peter Dunkley writes:
You can use th
José Luis Millán writes:
> That is a wrong formed URI but a right formed URI parameter. The right URI
> format for the above is:
>
> sip:192.98.102.11:35453;transport=tcp
>
> While the right format for the same info when it is used as an URI
> parameter is:
>
> sip:192.98.102.11:35453%3Btranspo
Peter Dunkley writes:
> You can use the force_outbound option in the outbound module to make
> path and rr add flow-tokens even when the client isn't doing outbound.
thank for info. it may not work though, if registrar and edge proxy are
combined. in my current test, i have two proxies/registr
You can use the force_outbound option in the outbound module to make
path and rr add flow-tokens even when the client isn't doing outbound.
Regards,
Peter
On 10/04/13 11:44, Juha Heinanen wrote:
Iñaki Baz Castillo writes:
Anyhow, why is the received stuff required at all? IMHO it is time fo
Iñaki Baz Castillo writes:
> Anyhow, why is the received stuff required at all? IMHO it is time for
> dropping custom/proprietary hacks and use rfc 5626 Outbound instead.
> Otherwise we must live with hacks in lot of places of the code and
> modules.
unfortunately it will take years before most s
Of course I assume that modules dont implement unescaping uris encoded as
URI param value. That needs to be coded.
Anyhow, why is the received stuff required at all? IMHO it is time for
dropping custom/proprietary hacks and use rfc 5626 Outbound instead.
Otherwise we must live with hacks in lot of
Hi,
2013/4/10 Juha Heinanen
> Juha Heinanen writes:
>
> > i tested and even when url path field contains escaped chars. however,
> > i started to get these to syslog every 20 seconds
> >
> > Apr 10 12:17:08 wheezy1 /usr/sbin/sip-proxy[3900]: ERROR: nathelper
> [nathelper.c:2018]: can't parse
Juha Heinanen writes:
> i tested and even when url path field contains escaped chars. however,
> i started to get these to syslog every 20 seconds
>
> Apr 10 12:17:08 wheezy1 /usr/sbin/sip-proxy[3900]: ERROR: nathelper
> [nathelper.c:2018]: can't parse contact uri
>
>
> most likely due to nat
i tested and even when url path field contains escaped chars. however,
i started to get these to syslog every 20 seconds
Apr 10 12:17:08 wheezy1 /usr/sbin/sip-proxy[3900]: ERROR: nathelper
[nathelper.c:2018]: can't parse contact uri
most likely due to nat pinging. i haven't checked yet where
2013/4/10 Juha Heinanen :
> here is an example:
>
> Path:
> .
Perfect.
> as you see, single quotes are gone, because they don't serve any purpose
> after escape.
Not exactly, I want to insist on this: Single quotes did not server
any purpose previously because using single quotes to delimit an
Iñaki Baz Castillo writes:
> Juha, could you please paste here how the Path above looks with your
> change?
here is an example:
Path:
.
as you see, single quotes are gone, because they don't serve any purpose
after escape.
-- juha
___
SIP Express R
BTW not sure if your patch does it but I strongly suggest removing the
useless and wrong single quotes around the received value (once such a
value is properly hex-escaped it becomes a valid URI param value).
Please remember that single quote is NOT a valid delimitator AT ALL
for a SIP URI paramete
Juha, could you please paste here how the Path above looks with your change?
Thanks a lot.
2013/4/10 Juha Heinanen :
> below is patch that fixes receiced param value. i have not tested if
> kamalio that gets such a value is able to unescape the escaped chars.
> if not, that is a bug too.
>
> --
below is patch that fixes receiced param value. i have not tested if
kamalio that gets such a value is able to unescape the escaped chars.
if not, that is a bug too.
-- juha
*** path.c Fri Mar 29 19:14:46 2013
--- /usr/src/sip-router/modules/path/path.c Wed Apr 10 08:09:43 2013
Richard Fuchs writes:
> Would you and everyone else agree that unconditionally encoding the
> param in base64 would be the preferred solution? I have some pending
> additions to the path module and could include that as well.
i don't agree. characters that are not param-unreserved or unreserved
As I said before, this Path header
Path:
has a URI with these params:
- lr : no value
- received : 'sip:10.59.1.241:5079
- transport : tcp'
And this is because quoting a *URI param* between single quotes is a
bug in Kamailio.
Due to this bug, FreeSwitch finds a "transport" para
Although slightly off topic, I've been trying to craft a Path header that will
work with FreeSWITCH.
See:
http://jira.freeswitch.org/browse/FS-4989
It would be great if the Path header was compatible with what they want as well.
BR,
Spencer
On Apr 9, 2013, at 4:05 PM, Iñaki Baz Castillo wrote
2013/4/9 Richard Fuchs :
> On 04/09/13 12:19, Iñaki Baz Castillo wrote:
>
>> So the "received" value added by Kamailio is invalid. Such a value
>> cannot be the value of a SIP URI parameter at all. I strongly propose
>> encoding it in base64 or escaping the "=" and the ";" symbols when in
>> a SIP
Hello,
On 04/09/13 12:19, Iñaki Baz Castillo wrote:
> So the "received" value added by Kamailio is invalid. Such a value
> cannot be the value of a SIP URI parameter at all. I strongly propose
> encoding it in base64 or escaping the "=" and the ";" symbols when in
> a SIP URI param value as Juha
2013/4/9 Juha Heinanen :
> because path-value starts with name-addr and my interpretation is that
> since there are <>s around this path header body:
>
> Path:
>
>
> solely consists of name-addr and does not include any rr-params. sip
> uri included in name-addr in turn cannot have ; and = in it
On 04/09/2013 11:59 AM, Juha Heinanen wrote:
> because path-value starts with name-addr and my interpretation is that
> since there are <>s around this path header body:
>
> Path:
>
>
> solely consists of name-addr and does not include any rr-params. sip
> uri included in name-addr in turn can
Andrew Pogrebennyk writes:
> I don't see why you think that ; and = should be escaped.
>
> rfc3327 chapter 4 says:
>
>The syntax for Path is defined as follows:
>
>Path = "Path" HCOLON path-value *( COMMA path-value )
>
>path-value = name-addr *( SEMI rr-param )
because path-value
Hi Juha,
On 04/07/2013 01:51 PM, Juha Heinanen wrote:
> i escaped them, but it didn't help. path header now looks like:
>
> Path:
> .
>
> and i still get the same error:
>
> Apr 7 14:49:47 wheezy1 /usr/sbin/sip-proxy[8709]: ERROR: registrar
> [save.c:887]: Failed to parse Path: URI
I don't
Peter Dunkley writes:
> Thanks for the bug-fix as the parsing should always work, but I am having
> difficulty understanding the configuration in use here.
>
> This particular parsing problem only occurs when outbound is enabled in
> registrar and you have a received parameter to the Path: header
Thanks for the bug-fix as the parsing should always work, but I am having
difficulty understanding the configuration in use here.
This particular parsing problem only occurs when outbound is enabled in
registrar and you have a received parameter to the Path: header. However,
when using outbound I
i find and fixed the bug that caused parsing of path uri to fail when
save() was called.
it still holds true that the path uri generated by add_path_received()
is syntactically bogus. if the receiver is not kamailio, parsing of
path uri would thus most likely fail.
what should be done about it?
i also tried by removing single quotes from received value:
Path:
since they are not serving any purpose, but that didn't help either.
-- juha
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
Juha Heinanen writes:
> my conclusion is that ; and = in received value needs to be escaped.
i escaped them, but it didn't help. path header now looks like:
Path:
.
and i still get the same error:
Apr 7 14:49:47 wheezy1 /usr/sbin/sip-proxy[8709]: ERROR: registrar
[save.c:887]: Failed to pa
Juha Heinanen writes:
> Path:
> .
according to rfc3261
pvalue = 1*paramchar
paramchar = param-unreserved / unreserved / escaped
param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$"
unreserved = aphanum / mark
mark = "-" / "_" / "." / "!" / "̃" / "*" / "’" / "(" / ")"
my conclusion is tha
it is not my lucky day. anything new that i try, does not work.
in proxy 1, i call add_path_received() on register request, which
results into this kind of path header:
Path:
.
then i forward the request to proxy 2 and call save() on it. it results
in error:
Apr 7 14:01:44 wheezy1 /usr/sbin
43 matches
Mail list logo
