< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

Re: [reSIProcate-users] SIP messages limits for UDP in reSIProcate


Thank you for the thorough explanation.

And Happy Holidays!

Julio.

------------------
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Wednesday, December 23, 2015 7:01 PM
To: Julio Cabezas
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SIP messages limits for UDP in reSIProcate

The stack decides to which transport to use based on the results of the DNS 
NAPTR lookup for the message destination.  The NAPTR records can prefer TCP 
over UDP.  (This seems to be a good writeup:  http://anders.com/cms/264/ ).  
Also if the stack blacklists a UDP DNS result because it is unreachable, then 
it will use TCP instead.

An application can force a particular protocol in many different ways:
1.  Use a DUM profile outbound proxy setting (Profile::setOutboundProxy) with a 
transport=TCP parameter on the outbound URI.
2.  Use the DUM profile setting setFixedTransportPort to force the transport 
selection logic to a particular transport - this only works if you use a 
different port for UDP and TCP.
3.  Lower level - Add the transport parameter (ie: ;transport=TCP) to the 
request URI or Route header of any message.
4.  Lower level - pre-populate the Via header in each SipMessage with an IP 
address/port of the transport and a transport parameter (ie: ;transport=TCP).

Note:  All of these methods will end up circumventing the NAPTR lookup stage of 
the DNS records, since there is no point in checking which protocol to use, if 
the application is fixing it.  Some will also circumvent SRV look ups as well 
(the ones that lock to a particular IP or port).

I'm sure there are more ways I'm forgetting.

Scott

On Wed, Dec 23, 2015 at 3:31 PM, Julio Cesar Esteves Cabezas 
<jcabezas@xxxxxxxxxxxxx> wrote:
Hi Scott,

  I understand and I have 2 questions:

  - So, what is today the bonus of adding both UDP and TCP transports instead 
of only UDP, since it seems to always prefer and use UDP ?
  Maybe stack switches transport if it cannot get a response using the first 
tried transport ?

  - How an application, knowing the SIP message size, could command the stack 
to switch the transport, on-the-fly and on a message-by-message or 
dialog-by-dialog basis ?

Many thanks,
Julio.

--------------------------------
From: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Wednesday, December 23, 2015 5:52 PM
To: Julio Cabezas
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SIP messages limits for UDP in reSIProcate

There is nothing in the stack today to automatically switch from UDP to TCP 
based on the message size.  The application would need to be responsible for 
that.  You may want to consider just enabling TCP only.

Sounds like a feature to consider for a future release.  :)

Scott

On Wed, Dec 23, 2015 at 2:37 PM, Julio Cesar Esteves Cabezas 
<jcabezas@xxxxxxxxxxxxx> wrote:
Hi,

    I noticed in my UA application that the dum/resiprocate stack is sending 
and receiving UDP packets well above the 1300 bytes limit recommended in 
RFC3261.  (e.g. 5000 bytes)

    I think that allowing SIP over UDP above 1300 bytes is an useful behaviour 
in some scenarios (despite RFC3261) but undesirable in others.

    Suppose I have activated both UDP and TCP transports in an 
UserAgentMasterProfile.
    Is there any configuration to select the behaviour between "allow any UDP 
datagram size" and "switch automatically to TCP when sending SIP message above 
1300 bytes" ?

    I am using reSIProcate 1.8.14 in Windows 7.


Best Regards,
Julio.


_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/



_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/