Re: [reSIProcate] BasicCall TCP Transport

[Alan Hawrylyshen <alan@xxxxxxxxxx>]

On 24-Sep-04, at 12:29 PM, Samphel Norden wrote:

> This is regarding BasicCall sample code. When trying to add TCP 
> transport ("stackUac.addTransport (TCP, 5060)") It tries to create a 
> TCP connection and then later on looks for a matching UDP connection 
> (The error comes in the transportselector.cxx file). Am I suppose to 
> specify TCP transport in some other file and how do I force the stack 
> to stick to TCP?
> Thanks,
> Sam

Sam;

A common issue with this is when either the RURI to tried to use or the 
remote-target (as provided in provisionals from the other party) are in 
fact URIs that are routed over UDP.

To be sure, make sure you are using the latest reSIProcate from 
Subversion, then, run your test program with logging set to 
resip::Log::Stack.

Check carefully all the output from the DnsResolver.  You might find 
that the Stack thinks UDP is the correct way to transport your message.

The presence of NAPTR, and SRV records for your target will also 
strongly influence (ok, control) the stack's choice.

Consider the following RURIs:
        
sip:alice@xxxxxxxxxxx  (will follow RFC3263, might select UDP if there 
is no TCP SRVs/NAPTRs)
sip:alice@xxxxxxxxxxx;transport=tcp (will use TCP), but ACK (for IT) 
might use UDP if remote target ctc is silly.
sip:alice@xxxxxxxx (will use UDP to port 5060)
sip:alice@xxxxxxxxxxx:5060 (UDP)


Your best best for now might be to explicitly ensure that there is a 
URI parameter 'transport=tcp'.
If you can see from the DnsResults and TransportSelector that the stack 
has chosen UDP when TCP makes more sense (eg. TCP is a valid alternate, 
but there is no UDP tranport), please post the log and I'll take a 
look)


Thanks

Alan Hawrylyshen
a l a n a t  j a s o m i d o t c o m