Re: [reSIProcate] Transport selection and register/lookup behavior
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