[OpenSIPS-Users] Transport follow up
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Thu Apr 15 18:02:30 CEST 2010
exactly, and you can configure in opensips cfg whatever sequence of
protocols to be tried (by doing serial forking).
Regards,
Bogdan
Daniel Goepp wrote:
> 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 <mailto: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>
> <mailto: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>
> <mailto: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>
> <http://www.voice-system.ro>
> >
> >
> > _______________________________________________
> > Users mailing list
> > Users at lists.opensips.org <mailto:Users at lists.opensips.org>
> <mailto: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 <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
More information about the Users
mailing list