Hi Joachim,

the host (like name) is mandatory - if no port and no proto is given, you will use the host name (sip.com) to do NAPTR lookup to get the supported protos and than SRV lookup to get the machine name and port.

if only the port is missing, only SRV lookup will be done to get the machine name and port.

if only proto is missing, it will be assumed UDP and normal (A record) DNS lookup performed.

time? hard to say...until the next release anyhow...

regards, bogdan

Joachim Fabini wrote:

Hi Bogdan,

...

you are right - when the NAPTR support will be added, I plan to cumulate all t_relayxxxx() functions in a single one like: t_relay("[proto:]host[:port]")

lack of proto or port will trigger NAPTR or SRV lookups.

Hmmh, host must be optional, too. That's the situation when you really need DNS NAPTR/DNS SRV lookup.

Any idea when first versions of NAPTR-support will be available?

Thanks, best regards --Joachim

...

Joachim Fabini wrote:

...

Hi,

Initially I intended to submit a feature request for OpenSER functionality similar to t_relay_to_udp, t_relay_to_tcp but WITHOUT the need to specify the destination IP address and port. My reasoning was to let the new functions do exactly what t_relay() does but in addition force the DNS SRV query for a specific transport (udp, tcp, or tls).

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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users

Hi Joachim,

indeed, there was a misunderstanding :) .t_relay() with no param will be kept with the current functionality. Or you suggest to be able to specify only a different proto or port from the RURI?

regards, bogdan

Joachim Fabini wrote:

Hi Bogdan,

...

the host (like name) is mandatory - if no port and no proto is given, you will use the host name (sip.com) to do NAPTR lookup to get the supported protos and than SRV lookup to get the machine name and port.

if only the port is missing, only SRV lookup will be done to get the machine name and port.

if only proto is missing, it will be assumed UDP and normal (A record) DNS lookup performed.

Hmmh, seems to me that there's a slight misunderstanding here. The new function should imho also replace the current t_relay() - from the user's point of view this means for me: route the message statefully to the next hop.

The user does not need to (and can not, except he does the RFC3263 resolution manually) specify a destination proxy - OpenSER should be able to determine it according to the SIP DNS resolution rules (RFC 3263).

So my point of view: if no host is passed, OpenSER uses the destination URI to query the DNS (NAPTR) to determine what protocol the destination proxy prefers (Samuel made the correct point in his email, RFC 3263 states that the destination proxy must decide on the protocol to use) and then must do the SRV record and possibly A record lookup for the correct host to contact.

...

time? hard to say...until the next release anyhow...

Doesn't sound too optimistic if we need it in the next three months, right?... ;)

Thanks, best regards --Joachim

Hi Joachim,

I meant t_reply() will keep its behaviour as looking into URI for the destination - but it will incorporate the NAPTR lookup.

to response also to on earlier question, regarding the timing - I say 3 months are more than enough ;).

regards, bogdan

Joachim Fabini wrote:

Hi Bogdan,

...

indeed, there was a misunderstanding :) .t_relay() with no param will be kept with the current functionality. Or you suggest to be able to specify only a different proto or port from the RURI?

I did not yet find the primitive which is supposed to statefully relay and do the following:

1. NAPTR query on the transport to use PLUS
2. _exactly_ what t_relay() does now for the

transport returned by the NAPTR query.

You say that t_relay() is kept with the current functionality. Does this mean no NAPTR, or will t_relay() be extended to use NAPTR before SRV/A query? If the latter then everything is OK.

Otherwise we have the alternatives:

t_relay() -> Stateful relaying according to destination address using the incoming transport (no NAPTR). t_relay_to() -> Stateful relaying to a specific host (you said that <host> is mandatory here) using NAPTR to determine the transport.

To summarize: My point is that none of these two primitives covers the case when the message is to be relayed to the next hop based only on the destination address _and_ using the transport selected by the destination proxy (determined via NAPTR query).

Except if either a) t_relay() does NAPTR or b) the host parameter in t_relay_to() is optional.

--Joachim

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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users