[reSIProcate] Transport selection and register/lookup behavior
Byron Campen
bcampen at estacado.net
Fri Jul 18 16:53:54 CDT 2008
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>
More information about the resiprocate-devel
mailing list