[reSIProcate] Transport selection and register/lookup behavior

Byron Campen bcampen at estacado.net
Fri Jul 18 14:32:24 CDT 2008


	responses inline:

> Hi!
>
> I have two questions.
> The first one is concerning the stack:
> Is it possible to have Resiprocate switch the transport used for  
> sending an outgoing message, when the first transport does not  
> succeed within a certain timeframe? For example when I first send a  
> message to a UAS and don't specify a transport in the URL, it is  
> being sent via UDP. When the other side only listens on TCP, I have  
> to wait until the transaction expires, when I do not want to create  
> a concurrent transaction.
> The way SipX handles that is to first send it via UDP and when the  
> message is being retransmitted it also tries it via TCP. Is it  
> possible to have a similar behavior in Resiprocate?
>

	resip doesn't do this. It would probably be a much better idea to try  
TCP first, and then fail over to UDP (this is a violation of 3263, but  
I bet that doing UDP and TCP at the same time has worse consequences).  
Ultimately, if your UAS doesn't support UDP, you have to make sure it  
is contacted using a URI that specifies TCP. (either by setting its  
DNS up properly, or making sure to put a transport=TCP in its Contact  
header)

>
> The second question is about Repro:
> When a client registers with the proxy and specifies a port in the  
> To-URI, you always have to specify the port, when calling that  
> client via Repro. This is even the case when the specified port is  
> the default port (e.g. 5060).
> Wouldn't it it make sense for Repro to have the URIs match on lookup  
> even though only one of them explicitly specifies the (default) port?
>

	repro really should be ignoring the port altogether, I think. Anyone  
disagree?

Best regards,
Byron Campen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080718/21513b3a/attachment.bin>


More information about the resiprocate-devel mailing list