9 Feb
2021
9 Feb
'21
10:38 a.m.
Hello,
the idea of sending 100 trying was to stop retransmissions from upstream
and then wait for 200ok from downstream, not to send 200ok immediately
after the 100trying.
Is the forwarding to next hops done in parallel or it is serial forking?
Cheers,
Daniel
On 08.02.21 14:51, Denys Pozniak wrote:
Hello!
I do not understand what is difficult, to configure the
next hop application to send 100 trying? Or maybe you can
provide a diagram of how sip traffic is routed on your case.
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>
--
BR,
Denys Pozniak
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla
the 200ok for PUBLISH contains some additional
headers (e.g., relate
to ETag) that must be used in follow-up PUBLISH requests, are
you sure
that replying from intermediary proxy, not the presence server is
resulting in what you want to have?
Yes, in our current logic the fields SIP-ETag, SIP-If-Match, Expires
are not needed yet.
If the first 200ok is to stop retransmission,
then I said, try with
100 trying response from intermediary proxy.
Added 100 Trying from Intermediate Proxy to Upstream direction, but
nothing has changed (Intermediate Proxy ignores 200ok from Presence
and sends PUBLISH again).
пт, 5 февр. 2021 г. в 11:57, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
the 200ok for PUBLISH contains some additional headers (e.g.,
relate to ETag) that must be used in follow-up PUBLISH requests,
are you sure that replying from intermediary proxy, not the
presence server is resulting in what you want to have?
If the first 200ok is to stop retransmission, then I said, try
with 100 trying response from intermediary proxy.
Cheers,
Daniel
On 04.02.21 14:33, Denys Pozniak wrote:
I do not
understand what is difficult, to configure the next
hop application to send 100
trying? Or maybe you can provide a
diagram of how sip traffic is routed on your case.
1) Diagram below is the case I described in the initial email.
Here you can see incoming SIP PUBLISH and 3 forked legs towards
Presence Servers.
As soon as Kamailio Proxy receives SIP PUBLISH it sends 200 Ok back.
The Presence Server that has active subscription answers with 200
OK otherwise 404 Not Found.
So the question was how to drop sending 200 OK (and any other
replies) from Proxy to the left side.
image.png
2) When I drop 200 OK in *reply_route*, Kamailio Proxy
retransmits SIP PUBLISH to Presence Server.
image.png
чт, 4 февр. 2021 г. в 14:55, David Villasmil
<david.villasmil.work(a)gmail.com
<mailto:david.villasmil.work@gmail.com>>:
I think he’s trying to reply to the client immediately with a
200 and consume and not forward the 200 coming from the
presence servers.
On Thu, 4 Feb 2021 at 12:43, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>> wrote:
On 04.02.21 12:59, Denys Pozniak wrote:
If you
need to stop the retransmission, a 100 trying
should be sent instead of
200ok. Can you reconfigure the
next hop to do that? Or is it out of your control?
Looks it is difficult to do this as Kamailio Proxy forks
via append_branch() incoming SIP PUBLISH to all Presence
Servers. And even if Presence Server answers
200 OK, the Kamailio
Proxy still sends a repeated SIP PUBLISH there within
the fr timer.
This remark is also not clear, is the 200ok handled by
Kamailio, sent upstream, but then Kamailio still resends
the PUBLISH?
Cheers,
Daniel
чт, 4 февр. 2021 г. в 13:04, Daniel-Constantin Mierla
<miconda(a)gmail.com <mailto:miconda@gmail.com>>:
Hello,
if the 200ok is consumed by tm, it will destroy the
transaction very soon. I am not sure this is a good
path to go.
If you need to stop the retransmission, a 100 trying
should be sent instead of 200ok. Can you reconfigure
the next hop to do that? Or is it out of your control?
Cheers,
Daniel
On 04.02.21 11:47, Denys Pozniak wrote:
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla>
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
<mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Regards,
David Villasmil
email: david.villasmil.work(a)gmail.com
<mailto:david.villasmil.work@gmail.com>
phone: +34669448337
--
BR,
Denys Pozniak
Hello!
In the configuration below Kamailio Proxy creates a
transaction for the SIP PUBLISH to get info from
the HTTP server in async mode.
But before creating a transaction, a synthetic 200
OK is sent, so that I need somehow to drop the real
200 OK from the upstream Presence Server.
If drop 200 OK in *reply_route*, tm module starts
to retransmit.
Those it is necessary that the 200 OK be consumed
by the tm module, but does not go further.
/if ( !is_method("PUBLISH") ) {
/
/ sl_send_reply("200", "Ok");
t_newtran();
/
/ $http_req(suspend) = 1;
http_async_query("$var(url)", "CALLBACK");
/
/}/
/
/
/route[CALLBACK] {
/
/ <some header manipulation>/
/ t_on_reply("PUBLISH_REPLY");
route(RELAY);
exit;
/
/}/
/
/
/onreply_route[PUBLISH_REPLY] {
if ( t_check_status("200") ) {
*drop; # Does not work!!!*
}
}
/
Any advice is appreciated
--
BR,
Denys Pozniak
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org <mailto:sr-users@lists.kamailio.org>
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
--
Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com>
www.twitter.com/miconda <http://www.twitter.com/miconda> --
www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>
Funding: https://www.paypal.me/dcmierla
<https://www.paypal.me/dcmierla>
--
BR,
Denys Pozniak
