24 Jun
2009
24 Jun
'09
7:44 p.m.
El 24 de junio de 2009 18:04, Raúl Alexis Betancor
Santana<rabs(a)dimension-virtual.com> escribió:
On Wednesday 24 June 2009 13:06:52 Zeljko Lovrincevic
wrote:
Hi Raúl, I can't get what you mean with the last phrase, but according
to RFC 3261, a proxy could receive various 200 OK for an INVITE and it
MUST bypass all of them to the UAC. The UAC is responsible of
accepting all the 200 OK (by sending an ACK) and sending an inmediate
BYE for all of them except the first one.
This is true since an client invite transaction (in the proxy) is
terminated upon receipt of the first 200 Ok, so when the second 200
arrives to the proxy, the proxy has no info about the corresponding
transaction (already ended) and should route the 200 *stateless*.
However there is a draft modifying this behaviour:
"Correct transaction handling for 200 responses to SIP"
http://tools.ietf.org/html/draft-sparks-sip-invfix-03
It states that the the client invite transaction is not terminated
when receiving the first 200. Instead it remains in memory for a while
so new 200 are absorbed.
This new behaviour can be achieved in Kamailio in two ways:
- With a new parameter: drop_stateless_replies
http://kamailio.org/docs/modules/1.6.x/tm.html#id2530689
- Dropping manually the responses matching no responses:
onreply_route {
if ! t_check_trans() {
xlog("L_WARN", "Response with no transaction received
=> drop\n");
drop();
}
}
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
Hi,
I need SIP forking proxy, and I would like to use OpenSER for that
purpose.
I have few questions if you could help.
I am interesting for behavior when 200 OK INVITE is received for each
forked dialog.
Should only first 200 OK INVITE be passed to UA (the other will be
terminated by proxy), or 200 OK for all forked dialogs should be passed
to UA?
As RFC said .. first 200 OK is relayed to UAC requesting the INVITE, the other
forked UAC will receive an OpenSER generated CANCEL.