Mark wrote: > Scott Lawrence wrote: > > > I realize sipXecs is not obligated to set transport in RR, but at > > > least in the case of remote worker, who registered via TCP, > > in may be > > > the logical thing to do. We already send out-of-dialog > > requests toward > > > the remote worker using the transport protocol taken from > > registration > > > record. Why not modify the RR based on the registration. > > > > > > Even though one can argue that the phone configured to use TCP > > > protocol should stick to TCP even when facing the freedom > on using > > > either UDP or TCP, there is no harm in forcing the > > transport to TCP in > > > the case of a remote worker registered via TCP. > > > > I think that this latter issue is a special case of XX-5896, which > > tracks the need to add a separate Record-Route to support NAT > > traversal. > > Having that one specify the transport explicitly is probably a good > > idea. Do you see any subtlety here that wouldn't catch? > > Hi Scott, > > It might be confusing to tie this fix with XX-5896, which has > a different focus and transport requirement can be lost as an > unrelated detail. I would view XX-4786 and XX-5896 as larger > scope, less predictable and having less urgency. > > A solution for the transport problem is a simple one, is low > risk and can be implemented quickly, perhaps even in 4.0. > There is also some urgency in getting this issue addressed.
I realize the 4.0 ship has sailed, but could we consider this simple solution for 4.2? It would work-around a couple of Polycom issues. These issues are difficult, and won't be fixed in their next release. The only way to get them resolved in the 4.2 timeframe is with a change on our end. -Paul [email protected] _______________________________________________ sipx-dev mailing list [email protected] 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/
