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 > <bog...@voice-system.ro <mailto:bog...@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 > > <bog...@voice-system.ro <mailto:bog...@voice-system.ro> > <mailto:bog...@voice-system.ro <mailto:bog...@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 > > > <bog...@voice-system.ro <mailto:bog...@voice-system.ro> > <mailto:bog...@voice-system.ro <mailto:bog...@voice-system.ro>> > > <mailto:bog...@voice-system.ro > <mailto:bog...@voice-system.ro> <mailto:bog...@voice-system.ro > <mailto:bog...@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 _______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users