Re: [reSIProcate] Transport selection and register/lookup behavior

[Byron Campen <bcampen@xxxxxxxxxxxx>]

        We will only failover from TCP->UDP, not in the other direction.

Best regards,
Byron Campen

> 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
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxx
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

Attachment: smime.p7s
Description: S/MIME cryptographic signature