Hi,
I made some fixes regarding some similar cases - BYE not being
transmitted on the other side, but only in trunk now. I will make the
backport now and let you know when it is done.
Regards,
--
Anca Vamanu
www.voice-system.ro
On 10/06/2010 07:45 PM, thrillerbee wrote:
I've setup
Hello Anca,
Thank you for your quick answer.
If I understand correctly, with this patch, all the notify requests should have
state='partial'. My test shows that the publish request has actually
state=partial but the corresponding notify still have state=full for the
second call. So nothing
Well answering to myself, I have changed full by partial in
presence_dialoginfo/notify_body.c (patch attached) and this have solved my
problem: The notifications have also state=partial and the phones know how to
handle them (tested with linksys and aastra.) But I have no idea if there are
Anca,
After upgrade, the b2b_logic module will not initialize:
/usr/local/sbin/opensips[12083]: ERROR:b2b_logic:mod_init: DB_URL parameter
not set
/usr/local/sbin/opensips[12083]: ERROR:core:init_mod: failed to initialize
module b2b_logic
/usr/local/sbin/opensips[12083]: ERROR:core:main: error
Hi Vallimamod,
Indeed I should have changed there also. Now I have reexamined the flow
of operations and it was a bit inefficient with by first version, the
change was done two times. Can you please try the new version ( I have
just made a commit).
Thanks and regards,
--
Anca Vamanu
Hi,
Yes it does now, I have backported the db persistence from trunk today.
You need to install two tables also - use the script in
scripts/mysql/b2b-create.sql
Regards,
Anca
On 10/07/2010 05:21 PM, thrillerbee wrote:
Anca,
After upgrade, the b2b_logic module will not initialize:
Hi, is there any reason why Opensips would replace 503 with 500 ?
The UA initiating the call expect 503 to reroute somewhere else
INVITE :
10.0.20.14(UA) - 10.2.0.1(Proxy) - 10.0.4.202(UA)
RESPONSE :
U 10.0.4.202:5060 - 10.2.0.1:5060
SIP/2.0 503 Service Unavailable.
U 10.2.0.1:5060 -
Hi Julien,
see:
http://lists.opensips.org/pipermail/users/2010-September/014505.html
Regards,
Bogdan
Julien Chavanton wrote:
Hi, is there any reason why Opensips would replace 503 with 500 ?
The UA initiating the call expect 503 to reroute somewhere else
INVITE :
10.0.20.14(UA) -
Hi Bogden,
Thanks for explaining the child processes involved -- I misunderstood what
was happening.
Unfortunately, I don't have the core anymore. My recollection is that I
couldn't print anything useful due to compiler optimization. That said,
this should re-create pretty easily, and I'll get
Hi Nauman,
P1 detects some NAT presence by looking at the INVITE you sent to it.
So, you must check the INVITE and see if any private IPs are still
present in it before sending it to P1.
Regards,
Bogdan
Nauman Sulaiman wrote:
Hi Bogdan
Thanks, yes we have a public ip in our contact header
Julien,
I have been catching it in failure_route and sending it on up with this:
if (t_check_status(^503$)) {
t_reply(503, Service Unavailable);
exit;
}
I think you could use t_reply(503, $(replyrr)); (note the use of
reply to indicate the reply
Hi Nauman,
That means that P1 sees the incoming INVITE (from opensips) as coming
from behind a nat . So, do you do all nat-related fixes on opensips,
like fixing Contact hdr, SDP ?
Regards,
Bogdan
Nauman Sulaiman wrote:
Hi, using Opensips 1.6.2 we have the following setup.
UA1Opensips
12 matches
Mail list logo
