[Users] Problem with TCP INVITE being bridged by OpenSER to UDP

[Klaus Darilion]

Russ Daigle wrote:
> Hi Klaus,
> 
> Thanks for the insightful response.
> 
> Is that truly a MUST in the RFC definition of the word?  (I couldn't 
> find the sections in the RFC that you alluded to.)

12.2.1.1 Generating the Request

> 
> I see other call flows in the basic call flows RFC does as you 
> mention.   My concern is that stateless or transaction stateful proxies 
> may not now how to forward the "alice at 192.168.0.3:5070" request; in 

it is simple - just forward to 192.168.0.3:5070. Every proxy can do this.

> fact, it is likely they won't!

All the information needed for routing is available. the final 
destination is in the request URI and the intermediate hops are in the 
Route headers.

> I presume my client should only do as you mention if the client is going 
> to contact the other endpoint directly for the rest of the dialog 

wrong

> (rather than going through the proxy)? Sending a message to the proxy 
> where request-URI mentioned an IP address the proxy doesn't know is bad, 

no, it is good. The proxy does not have to lookup the location of the 
request URI again. It it works also in cases where for example the BYE 
is routed through other proxies.

> and furthermore specifying a port in the request-URI that is not the 
> same as the port for proxy is listening on also sounds bad.

it is the port where the client is listening - the request URI is the 
final destination. In your scenario, when you insert again the AoR in 
the request URI, the proxy is unable to forward.

> Especially remember in this case there was a record-route: forcing to 
> continue going through the proxy!!!!  Therefore, I would think that 
> changing the request-URI could cause problems with the proxy.

My clients do change the request URI and I have no problems in the 
proxy. Your client does not change the request URI and has problem in 
the proxy....so guess who is right ;-)

> If the record-route headers were not present (other cases I'm testing), 
> would it be permissible for me to continue going though the proxy 

you could do and maybe it works, but there is no guarantee as it is not 
standard conform.

> anyways rather than reverting to sending directly to the endpoint for 
> the remainder of the dialog????

regards
klaus