[SIPForum-discussion] Why ACK is different trnsaction..

Murali Natesh murali87ece at gmail.com
Tue May 20 04:26:03 UTC 2014


Hello Nitin,

Here are the definitions.

*Transaction*
a message request + his own response, a transaction is identified by his
« branch id » + « Cseq »

*Dialog  (also Call Leg)*
a set of transactions, identified by his « call id » + tag within the
« to » and « from » header

SIP is based on an HTTP-like request/response transaction model.You can
differentiate the ACK for 200Ok and others using Method.


Could you please share me an example trace of 200OK ACK having new
transaction and non 200OK not having new transaction?





*-- Thanks and RegardsN.Murali*


On Sun, May 11, 2014 at 11:42 PM, nitin jain <nitincs2006 at gmail.com> wrote:

> Hello Team,
> I am struggling to understand below mentioned mechanism/considerations-
>
> 1. Why ACK for 200 OK is a new transaction ?
>      -If we say because of TU & transaction layer isolation then it is
> matter of design; it could be designed in any other way also, Why it is
> mandatory to do in this way ?
> -RFC says because TU/core alone take responsibility to transmit it- What
> does it mean ? when it will be retransmitted ?
> -How UAS alone can take responsibility to deliver 200 OK ?
>
> 2. Why ACK is not different transaction for Non-200 Ok response ? How it
> is different from ACK for 200 OK ? if it is going hop-by-hop so what is the
> matter here that it is treated differently ?
>
> I have gone through various blogs & documents but could get the clarity.
>
> Any help will be highly appreciable...
>
> Thanks in advance...
>
> Regards,
> Nitin Jain
>
>
> _______________________________________________
> This is the SIP Forum discussion mailing list
> TO UNSUBSCRIBE, or edit your delivery options, please visit
> http://sipforum.org/mailman/listinfo/discussion
> Post to the list at discussion at sipforum.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20140520/5514b681/attachment-0002.html>


More information about the discussion mailing list