Juha Heinanen writes:
> > assigning $null to $sht(...) will remove the item from hash table.
>
> Ok thanks. I tried to find about that in pv wiki. I'll check again and
> if is is not mentioned, I'll add it.
I added note about $null assignment. While doing it, I noticed that
there is nothing o
Update, manually modifying the To-Domain in ACK has fixed this, I saved the
key value pair Call-ID/To-Domain of 200OK from CISCO and for corresponding
ACK with same Call-ID modified the $td
same problem appeared in BYE for the call, again same fix by modifying the
To-Domain for the same Call-iD in
Hello,
From the documentation for t_lookup_request()[1], it is not clear
whether it creates a new transaction if one does not exist:
"Checks if a transaction exists. Returns a positive value
if so, negative otherwise. Most likely you will not want to
use it, as a typical application
Daniel-Constantin Mierla writes:
> > there exists rpc command htable.delete that can be used to delete a key
> > from htable. is there a way to delete a key in the config file like
> > assigning $null to it or do i need to use sht_rm_name_re function that
> > feels like an overkill?
> >
> assigni
Hello,
On 12/05/15 16:32, Juha Heinanen wrote:
> there exists rpc command htable.delete that can be used to delete a key
> from htable. is there a way to delete a key in the config file like
> assigning $null to it or do i need to use sht_rm_name_re function that
> feels like an overkill?
>
assig
Daniel,
A question regarding when I should run your suggested gdb commands.
Do I run them at anytime after we see the issue on a particular port or
would you like me to run them at a particular instance/event after the
issue occurs (for example, make a test call and immediately run the
command;
Hi Daniel,
if the patch works fine, i can push it to the main repository. But in current
state, until it is not stable, i would not do it.
So that you asked: the interesting thing that this patch works fine on Debian
squeeze properly as expected, but on Ubuntu trusty, the NOTIFYs cannot reach
t
Yeah sure, attached here is the trace from the CISCO logs. Not in pcap
format.
Also this is the flow of the call.
+---+ +--+ +--+
|Provider |+> +Kamailio +-->+CISCO IAD |
+---+ +--+ +-+
Is the UAC in this case a 2543 endpoint by chance? Can you send a complete SIP trace of the entire setup?
Hi all,
I'm having a scenario where I'm sending call to CISCO IAD2431. The call
establishes with 200OK from CISCO and Kamailio sends back modified ACK.
Cisco at this points gives out an error and sends 200OK again, Kamailio
replies with ACK, and this cycle goes on until the call drops.
Here is th
there exists rpc command htable.delete that can be used to delete a key
from htable. is there a way to delete a key in the config file like
assigning $null to it or do i need to use sht_rm_name_re function that
feels like an overkill?
-- juha
___
SIP E
Hi Jason;
i configured cfg like below. Charging working but there is no information
about it is call forwarding and all the avps are about first session. When i
check dialog_ng hash , it can be updated. is there any flag to set call
forwarding or something.
or my problem is just logic. I am tryin
Hi Peter,
good you mentioned the the patch, overlooked it -- is it something that
you want to be pushed on main repository or some customization good for
your needs? Somehow I didn't understand properly if you think that is
the cause of the issue or is the solution.
If you want to be pushed to th
Hi Yasin,
I'd imagine this 'should' work already. The dialog will be torn down on the
BUSY, thereby sending a CCR(terminate). Theoretically you could re-arm the
RURI/dst and then call Ro_CCR again before t_relaying
Like I said, I have not tested this so if it doesn't work let us know and
we c
Thanks for reply.
i need to learn one thing? how to handle call forwarding charging in
IMS_charging. i mean that
A CSCF B C
|->INV-> |->INV-> | |
| |<-BUSY- | |
| |->INV-> -> -> ->|
it
Dear Daniel, community,
A few days ago I have already uploaded the diff that probably causes a rare
crash with kamailio, but as I mentioned, we have another issue as well.
Our clients are registered via TLS to kamailio, and we want to change their
presence ( to offline) when the TLS connection
Hello,
I am considering to release a new maintenance version from latest stable
branch - to be v4.2.5 - next week, most likely on Tuesday (May 19) or
Wednesday (May 20). If there is anything important to get in and not
discussed yet, bring the topic on development mailing list.
Cheers,
Daniel
--
On 12/05/15 10:06, Darren Campbell (Primar) wrote:
> Here's the full conversation. Makes me wonder whether the ACK needs to
> go back to the same host that handled the INVITE or whether it should
> be returned to the host mentioned in "c=IN IP4 PROVIDERMEDIAIP" in the
> 200 OK.
You still gave the
Hello,
On 12/05/15 10:50, José Seabra wrote:
> Hello Daniel,
>
> This issue was my mistake, I have a htable called fscache that
> connects the call-ids of each call with freeswitch ip, and now I'm
> re-using the same htable to save other information that i need and
> replicate it to others kamail
Hello Daniel,
This issue was my mistake, I have a htable called fscache that connects the
call-ids of each call with freeswitch ip, and now I'm re-using the same
htable to save other information that i need and replicate it to others
kamailios through DMQ.
The random values in cname field that i
Hello,
master is still the code to be 4.3, we will make a dedicated branch
sometime soon.
The patch will be backported to 4.2 as well. Thanks for helping to
troubleshoot and testing.
Cheers,
Daniel
On 12/05/15 10:03, Dirk Teurlings - SIGNET B.V. wrote:
> Hi Daniel,
>
> This fixes the problem, t
Hi Yasin,
The functionality of reviving Ro sessions on reboot is not yet 100%
complete. As you correctly noted, the groundwork is there w.r.t data being
stored in DB but I still need to rebuild the CDP sessions and restart the
structures, state and timing for the Ro sessions. It's something on my
Here's the full conversation. Makes me wonder whether the ACK needs to go back
to the same host that handled the INVITE or whether it should be returned to
the host mentioned in "c=IN IP4 PROVIDERMEDIAIP" in the 200 OK.
17:28:46.129459 IP 172.21.0.226.5060 > PROVIDERIP.5060: SIP, length: 1123
Hello;
as you know , S-CSCSF has IMS_charging module and dialog_ng
module for charging. When it is restarted , all dialog_ng hash is
vanish. So calls can continue but charging stops.
if dialog_ng has a db_mode when restart , it can be solved. or is
there a way to
Hi Daniel,
This fixes the problem, thanks very much,
Will this fix be included in the next (4.2 and/or 4.3) stable release?
Cheers,
Dirk Teurlings
On 11-05-15 17:25, Daniel-Constantin Mierla wrote:
Following quickly up, I pushed another patch that will remove the dialog
from keepalive list
The provider side is sending the BYE.
Also it's not that it is a second call affecting anything, the call ends
unexpectedly after 30 seconds.
To me it looks like provider keeps sending 200 OK and Asterisk keeps sending
ACK until provider timeout and sends BYE.
This initial issue with the 407 h
Hello,
can you show both received 200ok + ACK as well as those sent out? It is
important to see how Record-/Route, Contact and r-uri change on the way
to spot where the issue is.
Cheers,
Daniel
On 12/05/15 05:56, Darren Campbell (Primar) wrote:
> Hi all
>
> Experiencing a commonly reported issue
What do you mean it drops out? What side is sending the BYE?
Cheers,
Daniel
On 12/05/15 05:14, Darren Campbell (Primar) wrote:
> Had a closer look at the Digest being sent.
>
> Attempted to recreate Digest based on the username, realm, password,
> method & uri I was expecting versus the one creat
For sake of clarification, the r-uri is not related to the username for
authentication nor to To header uri. They can be completely different.
However, trunk provider might have various requirements in formatting
the r-uri and To uri, they usually say that in the interconnect docs.
Cheers,
Daniel
29 matches
Mail list logo
