21 | | PJSIP only sends the request with TCP if the destination URI contains ''";transport=tcp"'' parameter. Adding this parameter can be accomplished in two ways: |
22 | | 1. the most convenient way is to add a route-set entry (with proxy or outbound proxy setting) 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: |
| 28 | |
| 29 | == Sending Initial Requests == #initial |
| 30 | |
| 31 | According to SIP spec, a request is sent to the URI in the ''Route'' header if it is present, or to the request URI if not. PJSIP only sends the request with TCP if the destination URI contains ''";transport=tcp"'' parameter. Hence sending a request with TCP can be accomplished in two ways: |
| 32 | |
| 33 | 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: |
30 | | 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 call, the target URI when sending MESSAGE, etc.). For example, to make outgoing call with TCP: |
| 41 | 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: |
43 | | 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. |
| 56 | [[BR]] |
| 57 | |
| 58 | == Subsequent Requests == #nextreq |
| 59 | |
| 60 | 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. |
| 61 | |
| 62 | 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). |
46 | | == Additional Info about Registration == |
| 65 | [[BR]] |
| 66 | |
| 67 | == Automatic Switch to TCP if Request is Larger than 1300 bytes == #switch |
| 68 | |
| 69 | According to [http://tools.ietf.org/html/rfc3261#section-18.1.1 RFC 3261 section 18.1.1]: |
| 70 | |
| 71 | "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." |
| 72 | |
| 73 | 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. |
| 74 | |
| 75 | 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. |
| 76 | |
| 77 | In case TCP transport is not instantiated, you will see error similar to this: |
| 78 | |
| 79 | ''"Temporary failure in sending Request msg INVITE/cseq=15228 (tdta02EB0530), will try next server. Err=171060 (Unsupported transport (PJSIP_EUNSUPTRANSPORT))'' |
| 80 | |
| 81 | As the error says, the error is not permanent, as PJSIP will send the request anyway with UDP. |
| 82 | |
| 83 | This TCP switching feature can be disabled as follows: |
| 84 | * at run-time by setting {{{pjsip_cfg()->endpt.disable_tcp_switch}}} to PJ_TRUE. |
| 85 | * at-compile time by setting {{{PJSIP_DONT_SWITCH_TO_TCP}}} to non-zero |
| 86 | |
| 87 | You can also tweak the 1300 threshold by setting {{{PJSIP_UDP_SIZE_THRESHOLD}}} to the appropriate value. |
| 88 | |
| 89 | |
| 90 | [[BR]] |
| 91 | |
| 92 | == Additional Info about Registration == #reg |