On Wed, 2006-06-14 at 15:06 -0700, Bill Moats wrote: > While I agree that this would be a practical solution, I am just not sure it > is compatible with RFC3261. Specifically, DNS look-ups are not relying on > the "time-invariant properties of the server".
It's close enough to time-invariant -- it is assumed that DNS results change infrequently relative to the lifetime of a SIP request/response transaction. DNS results are usually cached near the user of the result on timescales of at least an hour. > This would be a viable > solution if the DNS procedures were guaranteed to return an identical set of > address simply re-ordered. I think it fails in the case where a domain is > using "load-levelling" and is able to return a different subset of addresses > (either statistically based or otherwise). Check out RFC2782 under the > "Weight" of SRV records! But because of DNS caching, domains do *not* return different subsets of addresses. At least they shouldn't. In regard to SRV records (RFC 2782), the ultimate user of the DNS records is expected to choose from among them with the proper weight and ordering. But that can be done statelessly, also: Assign a "score" to each record by taking the negative of the logarithm of a random number in the range 0 to 1, and dividing it by the weight (which yields a positive number). (Seed the random number generator with the incoming branch parameter, as before.) Sort the records in order of increasing priority value, and then by increasing score. Try the addresses specified by the records in the order in the list. (But the addresses may be domain names and the names may return more than one A record -- recursively, sort each set.) The above algorithm will weight each SRV record correctly. (See the implementation in the sipX open-source proxy -- https://scm.sipfoundry.org/rep/sipX/main/sipXtackLib/doc/developer/scores/README for details and proof.) With some trickery you can try each address in order statelessly if, when an attempt to send fails, you get back an indicator that failure has occurred, and (say) the branch parameter of the failed message, which you constructed to contain the index into the above list. Then the stateless proxy can reconstruct the list, and use the index to find the next entry to use. > I guess I should give a little more background to my problem. Specifically I > have encountered a UA which sends all it's SIP messages (regardless of > Request-URI) directly to the IP address of it's configured proxy. So as a > result, the ACK requests to 2xx will always be sent to my proxy regardless > of destination. I am left with no alternative but to statelessly proxy the > request (since ACK cannot be statefully proxied), but sadly the request-URI > has a domain name containing a URI! So I am left with no choice but to drop > the ACK which will eventually kill the INVITE transaction! > > Surely if the concept of a stateless proxy has found it's way into RFC3261 > it should be possible to implement such a proxy! Or is this a specific case > of proxy in a local network, one which could be statically configured? I think that the concept of a (transaction-)stateless proxy was created assuming that within-dialog requests would be routed according to the "route set", which was assumed to contain the IP addresses of the agents involved. But I don't know if anyone has actually deployed a stateless proxy in the real world. Dale --- interop.pingtel.com -- the public SIP phone interoperability test server _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
