Hi, and sorry if I am getting repetitious but since I am not getting any
replies on what I thought was an important question(rfc-complicance)
I need to ask the question again...(at least indicate why you disagree
with me?)
I was hoping someone could comment on what I thought was some fairly clear
rfc-references, that indicate that an ACK for 2xx should NOT match the
INVITE transaction, since it should be terminated at reception/sending
of 2xx.
I hope I dont offend in any way, I would just like to get some
clarification on this.
I hope you can clarify your standpoint, especially if you disagree with
me, which I get the feeling you do.
Kind Regards
Taisto Qvist
Taisto Qvist wrote:
> I seems like we dont agree on the interpretation of the txn handling
> for invite. Sure, there is a timer for handling retransmitted responses,
> but thats in earlier states than Terminated.
> Sure, there is nothing that says that the inner workings of your
> transactions
> must exactly behave as the statemachine diagrams in the rfc as long as
the
> external behavior stays the same, but still, I think that the ACK for 2xx
> should not match the INVITE txn.
> (It probably boils down to how rfc-isch you want to be.)
>
> >The end-to-end ACK establish a separate transaction (RFC 3261) and these
> >ACKs are not match as part of the INVITE transactions, but correlated
> >with them.
>
> [TQ]
> Where does it say that ACKs establish a separate transaction?
> There is no defined ACK transaction, only INVITE/nonInvite, server and
> client.
> The ACK is either a part of the INVITE txn, or its a separate request,
> but I would
> never call it a standalone transaction.
> The real purpose of txn's (in my view), is to enable/simplify forking,
> and to
> handle retransmissions. Retransmissions of ACK and 2xx, are done by
> the UAC/UAS,
> so there is no need for a ack-txn.
>
> >but even describe the wait timer. So, there is no contradiction.
> [TQ]
> I'd say there is. Where does it describe that this wait-timer should be
> used for all responses, or for matching ALL acks?
>
> My two main reasons for saying that ACKs for 2xx should not be matched,
> come from the following two texts. (17.1.1.2, and 17.2.1)
>
> 17.1.1.2 (client invite txn)
> The client transaction MUST be destroyed the instant it enters the
> > "Terminated" state. This is actually necessary to guarantee correct
> operation. The reason is that 2xx responses to an INVITE are treated
> differently; each one is forwarded by proxies, and the ACK handling
> in a UAC is different. Thus, each 2xx needs to be passed to a proxy
> core (so that it can be forwarded) and to a UAC core (so it can be
> acknowledged). No transaction layer processing takes place.
> Whenever a response is received by the transport, if the transport
> layer finds no matching client transaction (using the rules of
> Section 17.1.3), the response is passed directly to the core. Since
> the matching client transaction is destroyed by the first 2xx,
> > subsequent 2xx will find no match and therefore be passed to the
> core.
>
> [TQ]
> It even says "actually nessesary to guarantee...."
> Since the txn's are there to (among other things) absorb retransmissions,
> the receiving the 2xx MUST destroy the txn, so that when the next
> retransmission
> of 2xx is received, it is not consumed by the txn layer.
> This is what your txn-layer does for 3++ right? Any additional 3++
> received on
> a txn while waiting for Timer D to expire, will just be consumed, and
> the proxy
> core will never have to process it.
>
>
> 17.2.1. (server invite txn)
> The purpose of the "Confirmed" state is to absorb any additional ACK
> messages that arrive, triggered from retransmissions of the final
> response.
> ..snip...
> Once the transaction is in the "Terminated" state, it MUST be destroyed
> immediately.
>
> [TQ]
> The Confirmed state is there to absorb retransmissions, not the
> terminated.
> When receiving 2xx you go directly to terminated bypassing confirmed.
>
> Also, in 18.2.1 the text explicitly says:
>
> .. Note that when a UAS core sends a 2xx response to INVITE,
> the server transaction is destroyed. This means that when the ACK
> arrives,
> there will be no matching server transaction, and based on this rule,
> the ACK is passed to the UAS core, where it is processed.
>
> Thats faily clear right? :-)
> The think that puzzles my a little bit though, is that you must have
added
> "extra" code for this matching...?
> I mean, you're using the ;branch=z9xxxx for transaction matching
right, if
> its there? And the ACK for 2xx doesnt have the same branch, indicating
> a "new txn".
>
> So matching ALL ACKs would imply that for any ACK that doesnt match a
txn,
> your really checking up Call-Id's, tags and stuff, just to be able to
> match
> this ACK to the 2xx?
>
> Or are you checking callid's, cseq's, tags, and stuff, for ALL
> requests in your
> txn matching?
>
> Now, I been working on a sip-stack the last few years myself, and I
> naturally
> know that there is often a need to match the ACK, and the stack I've
> build has
> similar functions, it just doesnt do it on the txn layer, where we try
> to be as
> RFC-isch as possible.
>
> What I would like, is simply have some function-parameters to the
> t_check_trans(<DEFANGED_param>),
> or even better in my little mind, a "modparam("tm",
> "ack_2xx_matching", 1)".
>
> I am looking forward to hearing your reply, and in the mean time,
> thanks to all of you developers for an extraordinary software :-)
>
> Regards
> Taisto Qvist
>
> > Hi guys,
> >
> > Just to bring some clarifications on the TM module.
> >
> > once a transaction is completed (negative or 2xx reply), it is put on
> > wait (wait timer - see RFC3261) for catching any potential
> > retransmissions of replies.
> > So, the transaction is completed, but not removed from memory - RFC
does
> > not say that you need to trash immediately all the transaction
> > information, but even describe the wait timer. So, there is no
> > contradiction.
> >
> > The ACK (for 2xx)catching is done based on the completed INVITE
> > transaction (from wait timer) - nothing else.
> >
> >
> > Inaki, could you please detail what you mean by:
> >
> > <quote>
> > In my opinion OpenSer does a special treatment for ACK in tm mode,
> even if
> > they are for failed transaction (hop-by-hop ACK's) or succesfull INVITE
> > (end-to-end ACK's).
> >
> > </quote>
> >
> > Maybe I can explain you more if I understand you question....
> >
> > Regards,
> > Bogdan
>
----
Taisto Qvist, IP-Solutions
Mobile: +46-708-88 02 63
"We are Pentium of Borg. Division is futile, You will be approximated"
_______________________________________________
Users mailing list
Users@lists.openser.org
http://lists.openser.org/cgi-bin/mailman/listinfo/users
