| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature