ACK is considered as a separated transaction when INVITE has a 200 OK response.
But a request associated with all the responses untill a final response is obtained is considered as a transaction.
How ACK request In SIP INVITE is called a transaction when there is no response for it.
When the UAC receives 200 OK, the client transaction is destroyed at TL.
This is done because, the TL is unaware of the above core. The above
core can be a Proxy or an UAC core.
In case of proxy, the 200 OK is forwarded whereas in case of UAC, an
ACK is generated. Now this ACK has to
create a new transaction (transaction created by INVITE had been
destroyed)at TL for its transmission, hence the ACK for 200 OK is
outside the INVITE transaction.
For other non-2xx final responses, the client transaction at TL is not
destroyed and the ACK is generated by TL.
Hence in this case, the ACK is within the transaction.
Related
Trying to determine the correct behavior in this scenario. A SIP B2BUA sends Invite to SBC, the SBC responds with 200 OK but before receiving the ACK the SBC sends a re-Invite to modify SDP, to which the B2BUA responds with 500 Race Condition.
Call flow:
Client B2BUA SBC
| Invite -> | |
| | Invite -> |
| | <- 200 OK |
| <- 200 OK | |
| | |
| | <- re-Invite |
| | 500 Race -> |
| | |
In RFC3261 I can't find any reference that it's necessary to wait for ACK.
In section 14.1 I do see reference:
2. If there is an ongoing INVITE server transaction, the TU MUST
wait until the transaction reaches the confirmed or terminated
state before initiating the new INVITE.
Looking at the INVITE server transaction diagram it appears the 200 OK has moved the server transaction to terminated state but I'm not sure that's the correct context for this scenario.
Must the SBC wait for ACK before sending re-Invite or should the B2BUA accept the re-Invite?
It is normal that you get race condition because B2BUA is trying to handle two INVITE request at the same time, first INVITE needs to properly processed. Inside the same document that you've sent:
Note that a UAC MUST NOT initiate a new INVITE transaction within a
dialog while another INVITE transaction is in progress in either
direction.
1. If there is an ongoing INVITE client transaction, the TU MUST
wait until the transaction reaches the completed or terminated
state before initiating the new INVITE.
2. If there is an ongoing INVITE server transaction, the TU MUST
wait until the transaction reaches the confirmed or terminated
state before initiating the new INVITE.
So you should wait to retrieve the ACK first to be sure about that the first INVITE is done processing, because according to result of INVITE transaction, some message is expected to close the dialog . For an accepted INVITE, this needed message is ACK. After that you can send RE-INVITE to make some changes about SDP or something.
This question is regarding the ACK request in SIP (Session Initiation Protocol). Quoting RFC-3261 - 18.1.1 Sending Requests
If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP.
This looks OK for the INVITE and other non-invite request except ACK. Below are the points why i think the above statement may not be applicable for ACK.
ACK is just a request and not transaction. So the SIP transaction State Machine must not be applicable for ACK request. Since State Machine is the only place which talks about the retransmission, So the 18.1.1 is not applicable for ACK request. Quoting 3261 - "17.1 Client Transaction" - in favour for above argument.
There are two types of client transaction state machines, depending
on the method of the request passed by the TU. One handles client
transactions for INVITE requests. This type of machine is referred
to as an INVITE client transaction. Another type handles client
transactions for all requests except INVITE and ACK. This is
referred to as a non-INVITE client transaction. There is no client
transaction for ACK. If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.
ACK can be re-transmissted only if next B-party retransmits the final response.
Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?
Quoting 3261 - "17.1 Client Transaction" -
If the TU wishes to send an ACK, it passes one
directly to the transport layer for transmission.
Q:- What does TU wishes mean? Does it mean that TU can send any time it wish OR it means whenever final response come then only TU sends?
Regards,
Sudhansu
1) Let's go back to basic stuff
"If an element sends a request over TCP because of these message size
constraints, and that request would have otherwise been sent over
UDP, if the attempt to establish the connection generates either an
ICMP Protocol Not Supported, or results in a TCP reset, the element
SHOULD retry the request, using UDP."
My comments :-
"SHOULD retry the request" --> It says SHOULD retry not MUST retry request.
So this is not mandatory at all to send ACK request.
2)
Q:- Is my assumption correct that SIP ACK request can not be retransmitted on receiving the transport error (such as connection error, ICMP error)?
Quoting 3261 - "17.1 Client Transaction" -
If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission.
comments :- This clearly states if TU ( Transaction user ) wishes to {not must} pass ACK request to transport layer for tranmission.
So as per statement, it's application wish that don't do anything once you pass that to ACK to transport layer. OR if on another side if application wants if there any TCP error (ICMP) then it can retransmit same ACK request over UDP.
See RFC will never exclude ACK from this, it is application responsibility & how it is implemented.
Also please can also ask question at Sip-implementors mailing list. You will get more like minded people.
First some clarifications. From [RFC3261 Section 6][1]:
SIP Transaction: A SIP transaction occurs between a client and a
server and comprises all messages from the first request sent
from the client to the server up to a final (non-1xx) response
sent from the server to the client. If the request is INVITE
and the final response is a non-2xx, the transaction also
includes an ACK to the response. The ACK for a 2xx response to
an INVITE request is a separate transaction
So an ACK to a non-2xx is part of the same transaction as the INVITE, any 1xx responses and the final response. In particular it has the same CSeq and the same branch tag. ACKs to non-2xx responses are hop-by-hop.
An ACK to a 2xx is a new transaction (although this is a special ACK transaction, and there are no responses). It has the same CSeq, but a different branch tag. ACKs to 2xx responses go all the way from the client to the server.
On your specific point, section 17 is about the transaction Layer. Here ACKs are only ever re-transmitted in response to a re-transmitted final response. When the Transaction Layer decides it needs to send an ACK, it sends it to the Transport Layer, and it is the Transport Layers job to deliver it.
Section 18 is about the Transport Layer. An ICMP error or a TCP reset are Transport Layer errors, they are not covered by the SIP transaction model. If the Transport Layer needs to promote a message from UDP to TCP, or to fall-back from TCP to UDP, that is separate from the Transaction Layers model. In fact, if the TCP socket cannot be established, the ACK has not been transmitted yet. In this case the Transport Layer isn't retransmitting it, it is attempting to transmit it for the first time, by a different protocol.
In practise, this case is going to be rare. For the size of the ACK to be a problem for UDP, it has to be larger then both the INVITE and the final response - these have already succeeded via UDP. In the usual case the INVITE and final response contain an SDP body; in every success case the 2xx contains a body. The only case where the ACK is going to be larger is if there was no SDP in the INVITE and the ACK adds to the headers or body.
If you hit this case - TCP not supported and ACKs too big for UDP, you may be heading for failure anyway.
[1]: https://www.rfc-editor.org/rfc/rfc3261#section-6
I have below question on behavior of SIP Core in SIP communication.
Suppose party A calling party B. B receives INVITE and generates a '200 OK'. After generating '200 OK', B reaches the terminating state (SIP State Machine) and consequently there is no state machine in B.
Now if '200 OK' does not reach A, B is suppose to re-transmit '200 OK' as it has not receive ACK. RFC 3261 says it is SIP Core responsibility to re-transmit the '200 OK'.
So what is trigger in B's SIP core to send this re-transmit? Does it maintains any timers? Or is it implementation dependent?
Regards,
Sudhansu
The restransmission of 2xx from B is explained in Section 13.3.1.4 The INVITE is Accepted
The exact text is this one:
The 2xx response is passed to the transport with an
interval that starts at T1 seconds and doubles for each
retransmission until it reaches T2 seconds (T1 and T2 are defined in
Section 17). Response retransmissions cease when an ACK request for
the response is received.
The end of retransmission is explained after:
If the server retransmits the 2xx response for 64*T1 seconds without
receiving an ACK, the dialog is confirmed, but the session SHOULD be
terminated. This is accomplished with a BYE, as described in Section
15.
This means that the application layer (ie: not the transaction layer)
needs to manage the timers.
The timers T1 and T2 are defined in table 4: A Table of Timer Values.
T1 500ms default Section 17.1.1.1 RTT Estimate
T2 4s Section 17.1.2.2 The maximum retransmit
interval for non-INVITE
requests and INVITE
responses
T4 5s Section 17.1.2.2 Maximum duration a
message will
remain in the network
Is it allowed to modify the T1, T2 and T4 values. However, in theory, for usual Internet, they shouldn't be changed.
For example, if all ACK are lost, the retransmission would be made within those intervals:
500ms
1s
2s
4s
4s
4s
4s
...
until total is 64*T1 = 32 seconds
In Spray, for chunked response we can send chunked message with an ack like
peer ! MessageChunk(buffer).withAck(MyAck(k))
and we can get ack message back which confirms the message delivery to the OS network layer. Do we have something like timeouts for these acks ?
I don't think there is an Ack Timeout feature built in to spray.
It should be possible, for the Chunking Actor to keep track of sent messages & timeouts if your Ack contains details about the sent chunk. See ChunkingActor[T] used to marshall Stream[T] in the spray source code to get an idea of how this could be done. You may choose to have this actor keep track of the last chunk sent along with the time sent. If an Ack does not come back for that chunk during the set timeout, you can handle the case where chunk delivery has "timed out".
I'm reading the XEP-0124 / BOSH specification and do not understand the following sentence in chapter 9.1 Request Acknowledgements:
The only exception is that, after its
session creation response, the
connection manager SHOULD NOT include
an 'ack' attribute in any response if
the value would be the 'rid' of the
request being responded to.
In my words: I should not send an ACK if the respond is dedicated for the last and only request (in connection manager's queue).
But: There is a client with it's own state machine. Maybe the client already send a second request -- where the first one is not replied -- and expect to get two answers. In this case the client except a ACK with RID of the "older" request and the connection manager have to set ACK.
Conclusion: The connection mananager MUST set ACK as long multiple requests are allowed.
I'm not sure, but is this text paragraph dedicated only for the use case where no further request is send by the client but the session creation phase is finished successfully and the connection manager have to send "ping" messages to the client due to "wait" timeouts ?
So, as I read it:
If the highest RID (in sequence) that you have received is 11 (you might have received 14 after that, but it is out of sequence since 12 & 13 are missing), and you are responding on:
The same request, then you should not (it is recommended that you do not, but if you have a good reason to, then you may) send an 'ack' attribute.
An earlier held request (say RID 10) then you should set 'ack' to 11 since that is the highest in-sequence RID that you have received so far.
It's okay if the client sent multiple requests and the server doesn't yet know about them. This is because there is a chance that when the client sent 11, the server has no held connections and it will respond back on the same connection. In that case, there are 2 requests sent out (11 & 12), but the response for each one acks that same request since the server always has something to send back immediately.