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

[Joachim Fabini]

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