{{{
#!html
<!-- MAIN TABLE START -->
<table border=0 width="90%" align="center"><tr><td>
}}}

= Using SIP TCP Transport =

'''Table of Contents'''
[[PageOutline(2-3,,inline)]]

[[BR]]

== Enabling TCP support == #enable

TCP support must be enabled in the build by setting '''{{{PJ_HAS_TCP}}}''' to non-zero. This is enabled by default, hence normally there's no specific step to do to enable this. You must then instantiate SIP TCP transport in your application, e.g.:

 {{{
pjsua_transport_config  tcfg;

pjsua_transport_config_default(&tcfg);
status = pjsua_transport_create(PJSIP_TRANSPORT_TCP, &tcfg, &transport_id);
 }}}


[[BR]]


== Sending Initial Requests == #initial

According to SIP spec, a request is sent to the address in the destination URI, which is the URI in the ''Route'' header if it is present, or to the request URI if there is no Route header. PJSIP only sends the request with TCP if the destination URI contains ''";transport=tcp"'' parameter. Hence to send request with TCP, the destination URI must contain this parameter. This can be accomplished in two ways:

 1. The most convenient way is to add a route-set entry (with proxy or outbound proxy setting in the account config) containing URI with TCP transport. This way all '''initial''' requests will be sent with TCP via the proxy, and we don't need to change the URI for the registrar and all buddies in the buddy list. Sample code:
 {{{
pjsua_acc_config acc_cfg;

...
acc_cfg.proxy[acc_cfg.proxy_cnt++] = pj_str("sip:proxy.example.com;transport=tcp");
         
 }}}
 If the destination doesn't like the additional ''Route'' header, you can hide this Route header by adding ''";hide"'' parameter to the route URI, for example:
 {{{
   "sip:proxy.example.com;transport=tcp;hide"
 }}}
 This way PJSIP will process the request as if the Route header is present, but the header itself will not actually put in the transmission.

 2. If you don't want to configure route set entry, then you must add ''";transport=tcp"'' parameter to all outgoing URIs (the registrar URI, the buddy URI, the target URI when making calls, the target URI when sending MESSAGE, etc.). For example, to make outgoing call with TCP:
 {{{
pj_str_t dst = pj_str("sip:alice@example.net;transport=tcp");

status = pjsua_call_make_call(acc_id, &dst, NULL, NULL, NULL, NULL);
 }}}

[[BR]]


== Contact Header == #contact

With PJSUA-LIB, when making or receiving calls with TCP, the local Contact header will automatically be adjusted to use the TCP transport.


[[BR]]

== Subsequent Requests == #nextreq

Subsequent requests means subsequent request that is sent within the call (dialog), for example UPDATE, BYE, re-INVITE to hold the call, and so on. Subsequent requests within a dialog will be sent to the URI that is found in the top-most ''Route'' header which was built from the ''Record-Route'' header in the response that established the dialog (it could be the 18x or 200/OK response), or if there's no ''Route''/''Record-Route'', the URI in the ''Contact'' header of that response.

It could be the case that the initial request is sent with TCP, but the subsequent ones are with UDP. In this case, check the URI in the ''Route'' or ''Record-Route'' or ''Contact'' header of the 18x or 2xx response that is sent by the remote party. Chances are this header lacks the ''";transport=tcp"'' parameter in the URI; in this case, you can either configure the other end to use TCP, or configure your proxy to ''record-route'' (i.e. to force itself to be within the request path of the call).


[[BR]]

== Automatic Switch to TCP if Request is Larger than 1300 bytes == #switch

According to [http://tools.ietf.org/html/rfc3261#section-18.1.1 RFC 3261 section 18.1.1]: 

  "If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such  as TCP."

By this rule, PJSIP will automatically send the request with TCP if the request is larger than 1300 bytes. The switching is done on request by request basis, i.e. if an initial INVITE is originally meant to use UDP but end up being sent with TCP because of this rule, then only that initial INVITE is sent with TCP; subsequent requests will use UDP, unless of course if it's larger than 1300 bytes. In particular, the Contact header stays the same. Only the Via header is changed to TCP.

It could be the case that the initial INVITE is sent with UDP, and once the request is challenged with 401 or 407, the size grows larger than 1300 bytes due to the addition of ''Authorization'' or ''Proxy-Authorization'' header. In this case, the request retry will be sent with TCP.

In case TCP transport is not instantiated, you will see error similar to this:

  ''"Temporary failure in sending Request msg INVITE/cseq=15228 (tdta02EB0530), will try next server. Err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))''

As the error says, the error is not permanent, as PJSIP will send the request anyway with UDP.

This TCP switching feature can be disabled as follows:
 * at run-time by setting {{{pjsip_cfg()->endpt.disable_tcp_switch}}} to PJ_TRUE.
 * at-compile time by setting {{{PJSIP_DONT_SWITCH_TO_TCP}}} to non-zero

You can also tweak the 1300 threshold by setting {{{PJSIP_UDP_SIZE_THRESHOLD}}} to the appropriate value.


[[BR]]

== Additional Info about Registration == #reg

The client registration session also will keep the TCP connection active throughout the registration session, and server may send inbound requests using this TCP connection if it wants to. 


[[BR]]



{{{
#!html
<!-- MAIN TABLE END -->
</td></tr></table>
}}}