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