Re: [reSIProcate] Transport selection and register/lookup behavior
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@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel