What is a sip transaction?
Вставка
- Опубліковано 15 вер 2024
- - "Is an acknowledgment (ACK) for a non-2XX response considered a separate transaction in the context of SIP (Session Initiation Protocol)?
- CANCEL request for an INVITE in SIP includes the same branch parameter as the original INVITE request. Is the CANCEL request considered part of the same transaction as the INVITE request?"
Related pcap files for this video can be found on my GitHub here: github.com/Omi...
More videos on my Patreon page: / omidmohajerani
Nice Very good explanation , thanks Omid bro
Thank you.
Thank you very much Omid for sharing the good informations!
In my start of learning SIP I had a lot of issues to understand the SIP transcation, how to tell if a message belongs to which transaction, also as the part of branch parameter of Via header about Cancel and ACK for non 200 SIP Response.
I would like to add also that CSeq header is important to identify which response to which request!
for the case of the CANCEL which Cancels the INVITE, we have 2 subsequent responses, 487 and 200, you may say which response for which request? To answer this check the CSeq method name in addition the Via branch parameter, the 487 will have the following CSeq Value "CSeq: 2 INVITE" I made number 2 because the CSeq number of this INVITE is 2. and the CSeq of 200 is "CSeq: 2 CANCEL".
So you can say that we can identify the transaction of a SIP message by the Via branch parameter and the CSeq method name.
PS: many different SIP implementation sends 200 first then 487. but the RFC says that the 487 should be sent first.
Your videos about freeSWITCH are very good!
Thank you
Thank you for the info and explanation . I will read more about that. The question that I could not find answer for it is that is the ACK after a non- 2XX response considered as one transaction ? It is a different branch parameter but do we name it a transaction? As I find some articles that specified that as a transaction and some guides like kamailio SIP guide that it did not show as a transaction( www.kamailio.org/docs/tutorials/sip-introduction/#sip_transactions )
@@omidmohajerani I am happy to contribute and learn, sir. The ACK is part of the INVITE transaction and shares the same transaction identifier, known as the 'Via branch parameter'. Different articles or organizations might explain it in their own ways, and the actual implementations can vary.
😂 Karsten likes it. Alice calls Bob aka Omid calls Karsten
Yes thats 2024 version of it .😂
Nice! so interesting! I use sngrep for trace sip flows!.
you can find the related Pcap files for this video here :
github.com/Omid-Mohajerani/Learn-Kamailio/tree/main/siptranscations-pcap
Question1: Is an acknowledgment (ACK) for a non-2XX response considered a separate transaction in the context of SIP (Session Initiation Protocol)
Answer1: No, the ACK belongs to the INVITE Transaction.
Question2: CANCEL request for an INVITE in SIP includes the same branch parameter as the original INVITE request. Is the CANCEL request considered part of the same transaction as the INVITE request?"
Answer2: No, even though that CANCEL request have the same transaction ID identifier "via branch parameter" and CSeq counter, it is considered as a new transaction within the parent transaction. Moreover this CANCEL request should receive a final response which is 200 Ok.
Great. thank you . What about an ACK with 200 OK . Is it considered as a transaction ( just with one request that is ACK ? )
@@omidmohajerani ACK following 200 ok (sip reply for INVITE) is considered as a new self contained transaction « meaning a new transaction with its new Via brach parameter », even if it doesn’t have SIP responses.
But different SIP implementors may say this is not a new transaction.
Yes . I have not seen this in sip rfc . Can u refer me to the page ?
@@omidmohajerani
Section 8.1.1.7 says
"...
The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges.
..."
Section 13.2.2.4 2xx Responses says
"...
Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example.
The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately.
..."
Section 17.1.1.3 Construction of the ACK Request says:
"
...
The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the "original request"). The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request. The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to "ACK".
...
"
Here may be confusing because it says that "The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request"
it doesn't cover the part of the branch parameter or no explanation for 200 or non-200 as discussed in the Section 8.1.1.7
Thank you ! It’s my first time knowing the branch . It’s like a unique uuid .