[reSIProcate] Transport selection and register/lookup behavior

[Byron Campen]

	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 at resiprocate.org
> [mailto:resiprocate-devel-bounces at resiprocate.org] 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 at resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2423 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20080718/4cd252e6/attachment.bin>