Re: [OpenSIPS-Users] Transport follow up
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 partthat 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:
Re: [OpenSIPS-Users] Transport follow up
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Transport follow up
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 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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Bogdan-Andrei Iancu www.voice-system.ro ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] Transport follow up
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 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@lists.opensips.org
Re: [OpenSIPS-Users] Transport follow up
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 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 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,
Re: [OpenSIPS-Users] Transport follow up
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 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 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
Re: [OpenSIPS-Users] Transport follow up
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 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 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
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
[OpenSIPS-Users] Transport follow up
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@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
