[OpenSIPS-Users] Transport follow up

Daniel Goepp dan at goepp.net
Thu Apr 15 18:09:50 CEST 2010


Okay, thanks for the info, I will try serial forking.  As per one of the
previous threads regarding this, one of the ways recommended to force a
transport was to tag the RURI, for example:

        if($rd="proxy.othercompany.com"){
                $rd = "proxy.othercompany.com;transport=TCP";
        }

Although this does seem to force the transport, I'm having some troubles
with media getting setup when I do this.  Is this the method you would
recommend, or do you have a better way to force a specific transport?

Thanks

-dg


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

> 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
>
>
> _______________________________________________
> 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/c7a7ef97/attachment.htm 


More information about the Users mailing list