On Thursday 13 November 2014, Juha Heinanen wrote:

Alex Hermann writes:

...

...

is there a means to check if reply to t_relay()ed request is retransmission? there is t_is_retr_async_reply(), but that does not apply to regular transactions.

I don't think there is a built-in for that. I ended up storing the Via branch parameter of the reply in a htable.

how do you access branch value of the first via? do you use transformations since looks like there is no pv for that?

I use a select:

$sel(via[0].branch)

Juha Heinanen writes:

there is new piece of information in your reply though. based on the example on select wiki page, i was going to use index 1:

Example:

return the IP of top most Via header

@via[1].host

based on your answer, looks like there is a mistake in the example.

no, the example is correct. index needs to be 1.

-- juha

i tried to drop 200 ok in default onreply_route if it is retransmission. it didn't work out, however, since looks like branch flags (that i need to make dropping decision) are not available in default reply route. is this intentional?

-- juha

On Thursday 13 November 2014, Juha Heinanen wrote:

i tried to drop 200 ok in default onreply_route if it is retransmission. it didn't work out, however, since looks like branch flags (that i need to make dropping decision) are not available in default reply route. is this intentional?

You can try calling t_check_trans() beforehand.

On Thursday 13 November 2014, Juha Heinanen wrote:

I read about INVITE server transactions in rfc3261 and looks like the transaction can stay in Completed state (i.e, absorbing 200 OKs) at least 32 seconds. It means that the via branch hash table must in a busy proxy be quite large.

I don't think it adds much overhead.

Another possibility is to keep state in the transaction, via a flag or avp.

I also use $T_reply_last (tmx module) to check if the current response has a different (or same) code as the last response. Maybe you can use that?

Since the same info must be available somewhere in the depths of tm module, would it be better if someone with tm knowledge would write a function to access it?

I don't think tm recognises a retransmitted reply. It remembers the last reply and it does notice that a reply has already been sent (locally or forwarded).