[reSIProcate] Transport selection and register/lookup behavior

[Byron Campen]

	Nope. We adhere to 3263, which mandates that the default be UDP. If I  
may ask, how are you getting a URI that lacks the DNS entries, or the  
transport=TCP param, necessary to cause traffic to come over TCP? Is  
something failing to put a transport=TCP in a Contact header? Is DNS  
mis-configured? Or is it something more complicated?

Best regards,
Byron Campen

> Thanks for the quick answer.
>
> Is there a possibility to set the default transport for outgoing  
> messages? I didn't find anything.
>
> best regards,
> gabriel hege
>
>
> Byron Campen wrote:
>>    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
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- 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/4a8cf872/attachment.bin>