[reSIProcate] Transport selection and register/lookup behavior

[Gabriel Hege]

I came across the problem, when testing my application against a codian 
MCU for which no DNS was configured.

regards,
  gabriel

Byron Campen wrote:
>     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
>