Hi Klaus,
Maybe you can get a workaround using add_uri_param:
http://openser.org/docs/modules/1.0.x/uri.html#AEN118
add_uri_param("transport=tcp");
The solution is interesting. I see a slight problem
because we want to use tcp in the core and udp in the
access - basically the last proxy on the path must
rewrite the URI again to udp. But if the originating
client inserted already tcp... hmmmh...
The t_relay should use TCP. A problem might be if
there is already a
transport parameter.
I guess you can avoid this by do not changing the request URI but the
destination URI (overrides the request URI). E.g. an example
from Bogdan:
avp_write("sip:openser.org;transport=tls","i:11");
avp_pushto("$duri","i:11");
Probably you have to use regexp to copy the existing RURI
into an AVP, strip the existing transport parameter, add
the new one, and write it into the DURI.
The d-uri approach sounds promising. I'll go through the
scenario to see if there's some problem that I do not find
at first glance.
Thanks for your help,
best regards
--Joachim
regards
klaus
Seeing the roadmap for 1.1 I realized that NAPTR
solves
part of this problem. Is there already any estimation
when NAPTR implementation will be available in OpenSER?
I intentionally said "part of the problem" because
NAPTR delegates the decision on the transport to the
destination DNS. But: our own proxy might also be
required to control the selected transport.
It seems to me quite flexible to implement a
proxy-hosted NAPTR emulation and specify the list
of requested protocols, e.g.
t_relay_to_transport("tls","tcp",0)
specifies that t_relay should firstly generate a
SRV DNS query for
_sips._tcp.mydomain.org, if this
fails to query for
_sip._tcp.mydomain.org and then
give up - if I don't want UDP.
This saves one DNS query (NAPTR) and enables a proxy
to control what protocols it uses for contacting the
next hop.
Finally, I believe that the interface to t_relay_naptr()
(or whatever the naptr relaying will be called) should
support selection of desired protocols, e.g.
t_relay_to_naptr("tls", "tcp", "udp") where entries
can be left empty to indicate that this transport is
not desired. The argument order might even overrule
the NAPTR response transport ranking - finally we
connect and thus decide on what transport we prefer... ;)
Any comments warmly welcome,
best regards
--Joachim
_______________________________________________
Users mailing list
Users(a)openser.org
http://openser.org/cgi-bin/mailman/listinfo/users