I tried making multicast to work on 3.3.2 version and I don't know if this is a bug in linphone.
(If I make a normal call with this disabled below it works normally)
What I did was enabled, on Linphone service initialization
LinphoneManager.getLc().enableAudioMulticast(true);
LinphoneManager.getLc().setAudioMulticastAddr("224.0.0.100");
I make a call from
.4.12(IP) 102(PBX number) to .4.26(IP) 116(PBX number) device
(On 102 I am calling SIP number 116)
Call then works normally, and if I check in Wireshark I see that
4.12 - Sending data over UDP to 224.0.0.100
4.26 - Starts sending STUN Binding Request after 15 seconds, and is sending it once each second till the call stops
This is all that is going on, and then after 30 seconds call just ends.
On receiving end, on 4.26, I also tried adding
params.enableAudioMulticast(true);
but nothing changes
Questions:
Why does this call drop after 30 seconds? Do I have to enable something else, because I don't see this anywhere in documentation
How can I make all devices, which are listening on 224.0.0.100 to receive the call? If I make a call from 102 - 116, how can for example device, which is registered on 120, has multicast enabled, also receive this call? Should I make a call somehow differently?
Related
call comes in pstn gateway
Rings ring group
Extensions in the ring group have call forwarded to pstn numbers
The call should ring the pstn numbers
e.i: ring group test_rg has two extensions 1000 and 1001 and 1000 are registered from IP phone and in IP Phone I set call forwarding to my mobile number. When I call ring group it called 1000 and 1001. 1000 return 302 Temporary moved with new contact header with my mobile number. But FreeSWITCH is not processing 302 message and IP phone continues to send 302 until timeout.
I am facing this issue only when ring group strategy is the enterprise in all other it working fine.
Thank you in advance for your help.
There maybe a fix for this in the next major release 4.4 and already in the master branch. Reason this would may work is the Call Forward was completely rebuilt to prevent a user causing and infinite loop with their call forward.
When 4.4 is released follow the version upgrade instructions carefully. Make sure your delete your 'user exists' dialplan then go to Advanced -> Upgrade -> App Defaults for it to generate a new on for you.
Update 4.4 has been released as of 5 April 2018.
I'm writing simple SIP-proxy application which stands between Astreisk and SIP client (any softphone). The purpose of the application is to calculate the duration of the call.
Below is example of regular flow:
Client sends INVITE to SIP-Proxy, SIP-Proxy resends INVITE to Asterisk
Asterisk answers with 200 OK, SIP-Proxy resends 200 OK to client.
Client answers with ACK, SIP-Proxy resends ACK to Asterisk
Whenever one of the parties sends BYE, conversation should be finished.
On step 2 I assumes that call is started (e.g. rtp media flow is started). Then I wait for BYE message to calculate duration of the call. However I noticed that some clients never goes to step 3 and 4. No call end notification received from any parties after step 2. And duration of such call is infinitely.
What is the best way to find out start/stop time of the SIP call without sniffing RTP flow ? Should I wait for step 3 to mark the start of the call ? What if client omit ACK or what if UDP datagram with ACK is missed in the network ?
For now I used to think there is no reliable way to figure out that SIP call is started. Maybe I should use Astrisk channels API instead to track active calls.
Another option is to generate a RE-INVITE to test the existence of the Session. Dont have to negotiate a timer or anything. Just using re-invite could help. Reuse the SDP to ensure that no media changes happen. But then your application is moving out of being a Proxy in the path of the call to being a application server.
Also the duration can only be capped to nearest interval for this re-invite request and not necessarily the exact time the call was released.
Your problem seems to be at SIP level, because your proxy does not add itself into the message path using a Route header. This process is called Record Routing. If doing so, all subsequent requests in your dialog will also traverse it (ACKs and BYEs included).
You should not reinvent the wheel by writing a SIP proxy. For example, you could use a open-source, flexible, powerful and completely customizable SIP Proxy in order to build any possible scenario you could think of: OpenSIPS!
I'm currently working on a project which requires to hook TCP send and recv API in IE to monitor the TCP data. It works fine on IE9 and IE10. But it stop working on IE11. After some research, I found IE11 uses WSASend and WSARecv to send and receive data. So I decided to hook WSASend and WSARecv.
WSARecv is an overlapped operation. There are 3 ways to get the result of overlapped operations. When overlapped operations are used, they either have an associated event, a completion routine, or are associated with an I/O Completion port.
I checked the overlapped structure when IE11 calls WSARec and found both event and completion routine are NULL, so I assume IE11 uses IO completion port to get the result of the overlapped operations.
The problem is GetQueuedCompletionStatus or GetQueuedCompletionStatusEx is never called by IE11. I use API monitor or hook those 2 functions directly and never see those 2 functions are called. I don't know if IE11 uses a different sets of APIs to get the result of WSARec.
I wonder if anyone has encounter the similar problem. Which API should I hook? If there is an alternative way to achieve the same goal. Basically what I want to do is monitor TCP data in IE11.
you can set a breakpoint in ntdll!NtDeviceIoControlFile, which all socket APIs are finally routed to, so you can know which one is used.
You need to hook CreateThreadpoolIo.
You also need to filter the winsock extension functions like WSARecvMsg, WSASendMsg, for this you need to hook the WSAIoctl & replace the extension function pointer
I'm using Asterisk 11, a Cisco SPA303 Phone, and Twilio.
I can make outgoing phone calls without any issue and the call quality is top notch. On an incoming call however, my extension (and phone) ring, however when I answer the phone, there is no audio on either end and 30 seconds later, both calls end. Using Twilio's PCAP log, it shows that my asterisk server sends a BYE when answered. Asterisk however does not log a single thing on incoming calls. (All SIP traffic is logged on outgoing calls). Does anyone have any idea what's going on?
Update:
Turns out that I had my incoming extensions in the wrong context, once that was updated, incoming and outgoing calls worked without a hitch. I marked #arheops as the answer because the logging of unanswered calls lead to the diagnosing of the problem.
Very likly(but you not informed) your asterisk installation is after NAT.
IF so, you have configure asterisk as described in http://www.voip-info.org/wiki/index.php?page_id=410
Also may need change ports on router/disable SIP ALG on router etc.
Logging(you mean cdr,right?) is controled by /etc/asterisk/cdr.conf
Most likly you have ananswered=no in that file.
I have a simple client<>server setup where the client sends UDP packets to the server on say port 2000 many times per second. The server has a thread with an open BSD socket listening on port 2000 and reads data using a blocking recvfrom call. That's it. I've set up a simple tic toc timer around the recvfrom call in the server and plotted the results when running this over Wifi.
When the server is connected to the access point via Wifi, it's similar in that usually the recvfrom call also take 0.015 seconds. However, after a short period of radio silence where no packets are sent (about half a second) the next packet that comes in on the server will cause the recvfrom call to take an extremely long time (between 0.6 and 3 seconds), followed by a succession of very quick calls (about 0.000005 seconds) and then back to normal (around 0.015 seconds). Here's some sample data:
0.017361 <--normal
0.014914
0.015633
0.015867
0.015621
... <-- radio silence
1.168011 <-- spike after period of radio silence
0.000010 <-- bunch of really fast recvfrom calls
0.000005
0.000006
0.000005
0.000006
0.000006
0.000005
0.015950 <-- back to normal
0.015968
0.015915
0.015646
If you look closely you can notice this on the graph.
When I connect the server to the access point over a LAN (i.e. with a cable), everything works perfectly fine and the recvfrom call always takes around 0.015 seconds. But over Wifi I get these crazy spikes.
What on earth could be going on here?
P.S. The server is running Mac OS X, the client is an iPhone which was connected to the access point via Wifi in both cases. I've tried running the client on an iPad and get the same results. The access point is a Apple Airport Extreme base station with a network that is extended using an Apple Airport Express. I've also tried with a Thompson router and a simple (non WDS network) and still get the same issue.
UPDATE
I rewrote the server part on Windows .NET in C# and tested it over the Wifi keeping everything else the same and the issue disappeared. So it suggests that it's a OS/network stack/socket issue on Mac OS X.
I don't think you can do anything about it. Several things can happen:
The WiFi MAC layer must allocate bandwidth slots to multiple users, it will usually try to give a user long enough time to send as much traffic as possible. But while other users are busy, this client can't send traffic. You even see this with only one user (consequence of the 802.11 protocol), but you'll notice this most with multiple active users of course.
IOS itself may have some kind of power saving and buffers packets for some time to send bursts, so it can keep some subsystems idle for a period of time.
You have some other radio signal that interferes.
This is not an exhaustive list, just what I could think of on short-notice with only the given input.
One thing: 0.6 to 3 seconds is not an extremely long time in the wireless domain, it might be 'long', but latency is with reason one of the biggest issues in all wireless communications. Don't forget that most wifi AP's are based on quite old specs, so I wouldn't say these numbers are extreme (I wouldn't expect 3s gaps however).