[OpenSIPS-Users] Transport follow up
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Fri Apr 16 12:33:17 CEST 2010
Hi Daniel,
Daniel Goepp wrote:
> 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 <http://proxy.othercompany.com>"){
> $rd = "proxy.othercompany.com
> <http://proxy.othercompany.com>;transport=TCP";
> }
>
works like that, but if you want not change the RURI in the message,
change the Destination URI instead:
if($rd="proxy.othercompany.com <http://proxy.othercompany.com>"){
$du = "sip:"+$rd+";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?
it should not affect the media part....that is controlled by SDP only.
Regards,
Bogdan
>
> Thanks
>
> -dg
>
>
> On Thu, Apr 15, 2010 at 9:02 AM, Bogdan-Andrei Iancu
> <bogdan at voice-system.ro <mailto: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>
> <mailto: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>>
> > <mailto: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
> > > >
>
--
Bogdan-Andrei Iancu
www.voice-system.ro
More information about the Users
mailing list