Hello,
I am experiencing the following problem: my dispatcher module is losing
many calls when the scenario for balancing is about 175 CPS or more. Is
there a limit that the module can do? Where do I find this information?
Att.,
--
Rodrigo M.
(37) 9132-4539
(34) 9889-3069
Hi,
I have a scenario I’m not sure of the best way to solve.
I use alias_db and have multiple destinations for a single number, and have append_branches set to 1.
I then use lookup_branches to get details from the location table for each branch.
I then do t_load_contacts and t_next_contacts, then t_relay to parallel fork the calls to the destination, and all the phones ring at once.
This all works great if all the destinations from the dbaliases table are online.
However, if one of them is offline, lookup_branches says "Not found in usrloc”. This branch is still there, and the call is attempted. In my environment, this then does a DNS lookup, can’t resolve the domain, and the branch fails. This is the first branch that is tried, and when this branch has an error like this, it causes t_relay() to fail - I check for the output of t_relay() and reply with an error - per the default config that Kamailio ships with.
I guess what I need to figure out, is if there’s a way to have t_relay fail only if all branches fail? Or, is there a more elegant way to handle this?
I should add, I only allow a single registration per subscriber - so, lookup_branches only returns one branch per alias from alias_db_lookup.
--
Nathan Ward
Hello,
I would like to offer a $100 USD bounty if a developer is able to
provide a fix for the two topos problems I have experienced. I will add
another $50 if this can be solved within 48 hours of the time stamp of
this message.
The bug report is at: https://github.com/kamailio/kamailio/issues/1005
You may find the most relevant information in my last few updates.
Please refer to mar1-nat.txt and mar1-reinvite.txt for the most recent
SIP captures, and the post below that for example database records.
Steps to reproduce the NAT problem can be found at
https://github.com/kamailio/kamailio/issues/1005#issuecomment-283255720
Some fine print to clarify the offer:
Payment is contingent on resolving both described use-cases. Payment
will be sent via your choice of PayPal, cheque drawn on a US bank, or
cheque drawn on a Canadian bank. Payment will be issued once the patch
is accepted by the Kamailio project, although the bonus for a quick
resolution simply requires a suitable patch to be submitted to the bug
tracker within 48 hours from now.
Thanks!
--
Trevor Peirce
AcroVoice Solutions Inc
Hello,
I believe LCR Target list is stored in the database and any changes made
here should affect the behaviour of the calls imedialtely.
I have changed one of my Target List Rule , where I changed my gateway Id
to another gateway. But the calls are still being routed via previous
gateway.
Is there something I can do to make the changes in production hours.
Sometimes one of carriers delivers bad call quality I would like to switch
the carriers.
--
Regards,
Nitesh Lohchab
Hi,
One of our customers is using a SEMS box to place two outbound calls using our sip trunk.
Once the first call is connected a second call is placed and when the second call answers their server sends a re-invite to switch audio ports so the rtp traffic doesn't flow through their server anymore but is routed inside our platform.
Basically, they just switch SDP's of both calls.
It seems like a random issue, and is not really reproducible, except for placing multiple calls and sometimes both parties can hear each other, other times they can't, because rtpengine fails (I think) to update the endpoint and keeps sending rtp back to their server for one of the call legs.
We tried to reproduce the case using a freeswitch box and it worked every time. After the reinvite, the rtp remained within our platform.
The signaling in both cases still goes through the freeswitch or sems for call control.
Does anyone have experience with this case? Or seen the issue before where rtpengine keeps sending rtp to the original endpoint?
Regards,
Grant Bagdasarian
CM
Hi,
Is it possible to access an avp variable from a different sip transaction?
On an INVITE is set an avp, but on ReINVITE I would like to access this avp again and get the value. Currently the value is null, which makes sense.
Not sure if this is possible and if it violates any rules inside the Kamailio engine?
I guess I could use a htable, but I'm just wondering if there is a built-in way for doing this.
Regards,
Grant Bagdasarian
CM
Hi,
I'm in need of making/tweak an existing Kamailio Presence setup which is
giving some tough time.
*Whats already working:*
BLF dialog states changes are already sent across the users. SCA is working
as well.
*What isn't working:*
When a User comes online then it sends SUBSCRIBE with *Event: dialog* and
don't get notified of its subscribers state right then unless the monitored
extensions make a call (BLF works)
*Why is it not working:*
As evident from wireshark traces, the user IP phones (Test sets: Polycoms,
Yealink, CISCO, Grandstream) don't send our *Event: presence* rather only
*Event:dialog* and Kamailio do not send NOTIFY out to everyone. Though yes
there is an internally generated PUBLISH seen and handled properly upon
registration state changes.
Jitsi has been tested and Kamailio send out these registration state change
info to jitsi, somce jitsi sends *Event:presence *in SUBSCRIBE.
I need dialog based NOTIFY to be sent out on registration state-change.
Need pointers and help on the topic, looking forward to some feedback.
Regards,
Sammy
Hi Daniel,
Thanks for your suggestions. The approaches which you have suggested are good, event I thought before initiating this query (since am working with kamailio for last three years), but my requirement is to distribute on single connection. Since it requires code change, started working on it. Really thanks for understanding my concern.
@juha:
Dear juha, it is not broken TCP implementation, kamailio TCP stack well implemented. If you would like to build a server to handle HTTP and MSRP protocols at higher rate, here is the place. But for SIP we have options to handle either UDP/TCP.
Thanks
surendra
