[OpenSIPS-Users] Transport follow up

Daniel Goepp dan at goepp.net
Thu Apr 15 17:52:17 CEST 2010 

If NAPTR was the method being used, but in this case is not setup.  So the
problem I'm trying to solve is what to do when the endpoints and the other
gateways are not being explicit via either URI or DNS.  The endpoint is not
specifying transport in the RURI, and DNS SRV is setup and exists with
entries for both TCP and UDP, but no NAPTR.  In this case, it's really
leaving it up to the proxy to decide what transport to prefer.

-dg


On Thu, Apr 15, 2010 at 8:44 AM, Bogdan-Andrei Iancu <bogdan at voice-system.ro
> wrote:

> Daniel,
>
> So, the transport to be used is chosen as follows:
>    A)  if "transport" in URI -> use it
>    B)  if no port in URI, try to use NAPTR
>    B1) if NAPTR -> use the advertised protocols as per weight and
> priority in NAPTR records (in the given order)
>    B2) if no NAPTR -> it is up to the proxy to choose the protocol
> (obeying the URI scheme, like sips).
>
> I guess you are referring to B2 case, which you can do in script, using
> a serial forking scenario (forcing different protos via $du ).
>
> Regards,
> Bogdan
>
> Daniel Goepp wrote:
> > I did, but I don't see anything that says it would be a violation of
> > SIP to try a number of transports in sequence, and to determine that
> > sequence by the proxy.  And I do understand that this is not a problem
> > with OpenSIPS, just trying to find a way to accomplish something new
> > perhaps.  We are working with some other networks which use a
> > different method of selecting transport.  And we are trying to
> > implement a similar method to select transport using OpenSIPS.  Very
> > similar to how route advancing works, but at the transport level.  I
> > am working now to do it at the scripting level, but just thought this
> > might be something to consider actually implementing as functionality
> > at the application level.  Perhaps it is just too unique of a problem
> > and not worth it.  The problem I believe is UDP is clearly the most
> > commonly used transport, but as devices get more capable (for example
> > in our situation with large SDPs for video, and traversing multiple
> > proxies adding record routes), packet sizes get larger, and TCP
> > becomes a more reliable transport.  Additionally many folks we work
> > with would prefer that is a secure connection is available, then it
> > should be used.  So the defaults on their network proxies will attempt
> > in the order of TLS, TCP then UDP to place a call.
> >
> > I will continue my work to try to get this going, but thought I would
> > post for comments here to get thoughts on the matter, or
> > recommendations on how this would be best implemented using OpenSIPS.
> >
> > Thanks.
> >
> > -dg
> >
> >
> > On Thu, Apr 15, 2010 at 1:59 AM, Bogdan-Andrei Iancu
> > <bogdan at voice-system.ro <mailto:bogdan at voice-system.ro>> wrote:
> >
> >     Hi Daniel,
> >
> >
> >     Have you read RFC3263 about Locating SIP Servers  (with proto
> >     selection)  ?
> >
> >        http://www.ietf.org/rfc/rfc3263.txt
> >
> >     Regards,
> >     Bogdan
> >
> >     Daniel Goepp wrote:
> >     > I had a previous question regarding default transport, and the
> >     > response I got was that the RFC says the order should be UDP,
> >     TCP then
> >     > TLS.  However after reading into this further (and some recent
> >     > experiences with other platforms) I'm wondering if I have a new
> >     > feature request for OpenSIPS.  >From the RFC 3263 - Section 4.1
> >     > Selecting a Transport Protocol, I read it as saying:
> >     >
> >     > 1.  If specified in the RURI it SHOULD use this (but doesn't
> >     have to)
> >     > 2.  Bunch of stuff on NAPTR (which we are not doing)
> >     > 3.  The section related to what we are doing:
> >     >
> >     > -----clip-----
> >     > If no NAPTR records are found, the client constructs SRV queries
> for
> >     > those transport protocols it supports, and does a query for each.
> >     > Queries are done using the service identifier "_sip" for SIP
> >     URIs and
> >     > "_sips" for SIPS URIs. A particular transport is supported if the
> >     > query is successful. The client MAY use any transport protocol it
> >     > desires which is supported by the server.
> >     >
> >     > This is a change from RFC 2543. It specified that a client would
> >     > lookup SRV records for all transports it supported, and merge the
> >     > priority values across those records. Then, it would choose the
> >     > most preferred record.
> >     >
> >     > If no SRV records are found, the client SHOULD use TCP for a SIPS
> >     > URI, and UDP for a SIP URI. However, another transport protocol,
> >     > such as TCP, MAY be used if the guidelines of SIP mandate it for
> >     this
> >     > particular request. That is the case, for example, for requests
> that
> >     > exceed the path MTU.
> >     > -----clip-----
> >     >
> >     > The way I read this is that OpenSIPS MAY select whatever
> >     transport it
> >     > likes, and if no DNS SRV is found, then it would default to
> >     using UDP
> >     > first for SIP.  But in our set, DNS SRV does exist, and there
> >     are both
> >     > TCP and UDP records.  We would like to decide the default transport
> >     > order to use, starting with TLS then TCP then UDP.  I think I
> >     can try
> >     > to write something in the script to do this, but I'm not sure
> >     yet.  I
> >     > don't want to rewrite the RURI, I just want to specify the
> >     transport.
> >     > It would be great if there was a global variable defined in the
> >     config
> >     > that was something like "transport_order=TLS,TCP,UDP"
> >     >
> >     > Thoughts?
> >     >
> >     > -dg
> >     >
> >
> ------------------------------------------------------------------------
> >     >
> >     > _______________________________________________
> >     > Users mailing list
> >     > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >     > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >     >
> >
> >
> >     --
> >     Bogdan-Andrei Iancu
> >     www.voice-system.ro <http://www.voice-system.ro>
> >
> >
> >     _______________________________________________
> >     Users mailing list
> >     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> >     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org
> > http://lists.opensips.org/cgi-bin/mailman/listinfo/users
> >
>
>
> --
> Bogdan-Andrei Iancu
> www.voice-system.ro
>
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100415/b2540944/attachment.htm

More information about the Users mailing list