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?
Is it possibly to define some static configuration how to fork a dialogs or we always need REGISTER?
Thanks in advance.
BR/Zeljko
On Wednesday 24 June 2009 13:06:52 Zeljko Lovrincevic wrote:
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.
Is it possibly to define some static configuration how to fork a dialogs or we always need REGISTER?
You don't need to REGISTER to be able to process the INVITE's, but for forking you will need a filled location table or doing manual append_branch() call
El 24 de junio de 2009 18:04, Raúl Alexis Betancor Santanarabs@dimension-virtual.com escribió:
On Wednesday 24 June 2009 13:06:52 Zeljko Lovrincevic wrote:
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.
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(); } }
El Miércoles, 24 de Junio de 2009, Iñaki Baz Castillo escribió:
- Dropping manually the responses matching no responses:
I mean "Dropping manually the responses matching no transaction"