Re: [reSIProcate] Transport selection and register/lookup behavior
Does resip handle the case where the NAPTR/SRV record for the domain
contains two entries? One with UDP, then TCP?
For example
sip IN NAPTR 100 50 "s" "SIP+D2U" ""
_sip._udp.sip.mydomain.com.
sip IN NAPTR 200 50 "s" "SIP+D2T" ""
_sip._tcp.sip.mydomain.com.
_sip._udp.sip IN SRV 100 50 5060 sip.mydomain.com.
_sip._tcp.sip IN SRV 200 50 5060 sip.mydomain.com.
Would it be able determine that transport using the first method failed,
then fallback to tcp automatically on a transaction level?
-Aron
-----Original Message-----
From: resiprocate-devel-bounces@xxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxx] On Behalf Of Byron
Campen
Sent: Friday, July 18, 2008 12:32 PM
To: Gabriel Hege
Cc: resiprocate-devel
Subject: Re: [reSIProcate] Transport selection and register/lookup
behavior
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