Hi MS,
You can use the Call-ID to correlate with the dialog. For example, use
the localcache to store (when creating the dialog) a record having as
key the call-id of the call and as value the time to start. In the
generic on_reply you can look for that records into localcache and to
the
Hi all,
I need to catch the replies to OPTIONS (ping) packets that
Create_dialog("Pp") sends to both sides, and then based on response code
and some other transaction information, i.e. I need to calculate the call
length (from pick up till that moment) to send Interim-Updates to RADIUS.
My
Hi Patrick,
Thanks for testing - I did the backport to 1.11 too.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 08.10.2014 23:12, Patrick Wakano wrote:
Hi Bogdan!
Just tested your patch and it worked!!!
Thanks a lot for your support!!
Hi Patrick,
Shortly, I found a flow in the logic of validating the send socket (the
dialog module is forcing an send socket for the OPTIONS, taken from the
dialog info).
I made a fix on trunk/master - see:
Hi Bogdan!
Just tested your patch and it worked!!!
Thanks a lot for your support!!
Patrick
On Wed, Oct 8, 2014 at 6:22 AM, Bogdan-Andrei Iancu bog...@opensips.org
wrote:
Hi Patrick,
Shortly, I found a flow in the logic of validating the send socket (the
dialog module is forcing an send
Hello list,
I was having a problem in which my Opensips was not sending the Options of
the dialog ping mechanism. After debuging I found out that Opensips could
not send it because it was not listening to the primary IP of the
interface. I am in a mhomed scenario and using Linux-HA so the virtual
Hi Brett,
The dialog module will end the call on the next ping interval.
What is the issue that you are having ?
Best Regards,
Vlad Paiu
OpenSIPS Developer
http://www.opensips-solutions.com
On 02/08/2013 06:12 PM, Brett Nemeroff wrote:
Hello List,
Question regarding dialog pinging. If
I was expecting that every 30 seconds a ping goes out. If the ping gets a
negative reply, it's immediately sent a BYE. The delay between the failure
code and the BYE is causing some confusion.
Not anything technically wrong with it, but not what's expected. Anyway to
change that behavior? Can you
Hello List,
Question regarding dialog pinging. If dialog pinging is enabled and so is
the B flag, how long after a failed ping should opensips send the BYE in
either direction?
Thanks,
Brett
___
Users mailing list
Users@lists.opensips.org
Hello,
How are you calling create_dialog() ? Could you maybe paste a snippet
from the cfg file ?
If should be called like
create_dialog(Pp);
to enable pinging.
Regards,
--
Vlad Paiu
OpenSIPS Developer
On 07/13/2011 10:14 PM, osiris123d wrote:
When the call is initially set up
I am pretty much doing the following
if (method==INVITE !has_totag() ) {
if ( create_dialog(PpB) )
{
xlog(L_INFO, - !*!*!*!**!*!*!*!*!**! Successfully created Dialog
Pp);
};
};
I will send you a personal email showing you what I am really doing.
On Thu, Jul 14, 2011 at
Hello Duane,
Just took a look at your config.
What was happening is that you were first calling trace_dialog(), which
creates the dialog structure internally. When the call to
create_dialog(PpB) came later on, it already found that the dialog was
created and did not set the needed flags for
On Thu, Jul 14, 2011 at 9:34 AM, Vlad Paiu vladp...@opensips.org wrote:
**
Hello Duane,
Just took a look at your config.
What was happening is that you were first calling trace_dialog(), which
creates the dialog structure internally. When the call to
create_dialog(PpB) came later on, it
That fix did fix my issue. This is what I am seeing now and I am guessing
this could be an issue. Figure it might have something to do with the fact
that I change the To: and From: headers maybe?
U 2011/07/14 09:55:01.570108 173.XXX.XXX.107:5060 - 64.132.245.122:15073
OPTIONS
Hello,
Glad to see that it has worked.
I see that the To and From headers are different in the generated pings,
sip:90133x9...@irock.com mailto:sip%3a90133x9...@irock.com vs
sip:933x9...@irock.com mailto:sip%3a933x9...@irock.com .
Are you using uac_replace_to/uac_replace_from to mangled the
I thought that might be the issue. I will look into what I am doing.
On Thu, Jul 14, 2011 at 10:17 AM, Vlad Paiu vladp...@opensips.org wrote:
**
Hello,
Glad to see that it has worked.
I see that the To and From headers are different in the generated pings,
sip:90133x9...@irock.com vs
Not sure if it is an issue or not. When I test with Jitsi or Bria client
they respond to the OPTIONS message with a 200 OK. I will post this on the
Blink mailing list and see what they have to say. Thanks for the help and
fixing the issue.
On Jul 14, 2011 10:18am, Duane Larson
When the call is initially set up between the two clients should I see sip
OPTIONS messages being sent to both clients every X seconds? I have this
set up and I don't see any OPTIONS messages being sent at all during the
duration of the good call.
--
View this message in context:
Hello Brett,
You are right, this was a bug, and I just commited a fix on trunk. Until
now, the reply handler only considered internal OpenSIPS timeouts, and
disregarded explicit 408 replies. Please update and let me know if it is ok.
Regards,
--
Vlad Paiu
OpenSIPS Developer
On
Hello Brett,
Yes, the OPTIONs messages are dialog specific. They contain the proper
to tag, from tag and callid, as well as the appropriate CSEQ header, etc.
If one end-point isn't alive anymore, or if it responds with a messages
telling that the end point is not aware of the dialog the
Vlad,
I just tested this today. Basically made a call with eyebeam, and once the
call was up, I forcefully killed eyebeam. After that, I saw OPTIONS goto
eyebeam and fail (retransmit). There was a dispatcher between the opensips
box and eyebeam, so the dispatcher told opensips 408. At that point,
Hello All,
I had a question regarding the new dialog ping feature. Does this just
check if the endpoints involved in a dialog are alive? Or is there anything
dialog specific in the OPTIONs message?
Thanks,
Brett
___
Users mailing list
22 matches
Mail list logo
