On Thu, 2009-06-11 at 16:58 -0400, Scott Lawrence wrote: > On Wed, 2009-06-10 at 14:27 -0400, Dale Worley wrote: > > (I jumped the gun on this one with XX-5918.) > > > > I'm seeing in various logs that we are not succeeding to get all the > > traffic between the proxy and registrar to use TCP. Out-of-dialog > > requests are routed from the proxy to the registrar by > > forwardingrules.xml, which always specifies TCP for contacting the > > registrar. But in-dialog requests (which are always for 'reg' > > subscriptions) generally go by UDP. In the proxy-to-registrar > > direction, the reason for that is that the registrar provides for itself > > a Contact that has no transport specification, so the proxy is free to > > use whatever transport it chooses, and often the messages are short > > enough that it chooses UDP. In the registrar-to-proxy direction, the > > proxy record-routes itself, but the RR does not include a transport > > specification, so the registrar is free use whatever transport it > > chooses... > > > > At least in the proxy-to-registrar direction, this could be fixed by > > having the registrar 'reg' event server use a contact address that > > specifies "transport=tcp". > > If we fixed http://track.sipfoundry.org/browse/XX-4789 so that the reg > event service ran on the same port as the registry and redirect > services, then we could just address it using the SRV record and control > the transport there.
That is, we could have the event service provide the SRV name as its contact, which would take care of the proxy-to-registrar direction. But it wouldn't take care of the registrar-to-proxy direction, as the Record-Route that the proxy adds doesn't have a transport specification. > In the more general case, it would be interesting to see if we could > design an address decoration for contacts that would instruct the Proxy > to record-route itself with a transport-specific route. Easier if we > got around to unifying the two proxy threads, but that's not happening > right now... The proxy has to generate the Record-Route when it sees the request, so it doesn't know what the UAS's Contact will be. But ... if the URI to which the proxy is sending the request (which is usually the request-URI) has a transport specification, then the proxy can "double Record-Route" itself, with the UAS-side R-R containing the same transport specification. (On the assumption that if the UAS can receive requests using a transport, then it can send requests using that transport.) (The transport specification of the UAC-side R-R would have to be coordinated with the transport on which the request reached the proxy.) > Is there some reason why we can't just set the sipXecs user services > that never talk directly to anything but the proxy to just always use > TCP? Why even configure them to use UDP at all (aside from the fact > that doing so has probably not been tested lately)? We can configure them to only listen on TCP, which will constrain them to only send using TCP. But that won't constrain the proxy to only attempt TCP with them -- it might try UDP, discover that that fails, and then fall back to TCP. Dale _______________________________________________ sipx-dev mailing list sipx-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
