Vinayak49
Vinayak49

Reputation: 87

Why do we send 100 Trying to an INVITE, but not to UPDATE or BYE messages?

I am trying to understand SIP and have one question regarding it. Why do we need to send 100 Trying to an INVITE but the same logic is not used for say BYE,UPDATE, NOTIFY etc msgs ?

Upvotes: 3

Views: 4164

Answers (3)

Dmitry Poroh
Dmitry Poroh

Reputation: 3825

Long story short. You may use or not use 100 Trying when it is reasonable.

Non-INVITE:

You can use 100 Trying for non-INVITE messages (non-INVITE transaction). But all these messages are designed to be replied as soon as possible.

So it is recommended to to reply fast on all non-INVITE messages. 100 Trying is not recommended in this case. If you cannot reply fast then you MAY use 100 Trying for non-INVITE transactions to prevent retransmits (slow down retransmits to T2 interval).

This recommendation is designed only to reduce network interactions for non-INVITE transactions.

INVITE:

Also you MAY avoid sending 100 Trying for INVITE messages if you can reply fast. RFC 3261 says:

The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms...

Upvotes: 1

AymericM
AymericM

Reputation: 1745

From rfc3261:

21.1.1 100 Trying

This response indicates that the request has been received by the
next-hop server and that some unspecified action is being taken on
behalf of this call (for example, a database is being consulted).
This response, like all other provisional responses, stops
retransmissions of an INVITE by a UAC. The 100 (Trying) response is
different from other provisional responses, in that it is never
forwarded upstream by a stateful proxy.

100 Trying is a provisional response used to stop retransmission on previous hop. As written above, it is not forwarded by a stateful proxy.

This is mainly useful for transaction that will require time to complete: ie, when a final answer can't be sent as soon as possible.

Thus, the main use-case is for initial INVITE, where reaching the final hop and getting a final answer is delayed by long operation: database search, routing and of course ringing time...

NOTE1: When "database search and routing" is quick enough, 1xx could acheive the same goal (stop the retransmissions), but as they are not "reliable", they may be lost on the path. Thus, 1xx for INVITE can't replace 100 Trying in a reliable way.

NOTE2: 100 Trying can be sent for any request. However, SIP requires that any non-initial-INVITE request should be given an immediate final response ASAP, so if somewhere, you have a long time delay, this means your implementation (or deployment) may not be correct or optimal.

Upvotes: 2

Daniel Voina
Daniel Voina

Reputation: 3215

enter image description here

Because the called party might not be available (busy, no presence, etc). The answer is a provisional one so that the caller, or any in-between proxy, can activate some timers until it drops the call. As you can see in the following call-flow the INVITE from proxy to the called party is sent after the TRYING. In case that the INVITE is propagated through several proxies ot through gateways this might be a lengthy process until an RINGING or OK is received.

For BYE - one can always hang up abruptly.

UPDATE, NOTIFY, INFO are in-call messages there the parties have already established the session.

Upvotes: 0

Related Questions