[Users] OpenSER and transport selection (SRV and NAPTR)

[Joachim Fabini]

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