When call is made between two chan_mobile channels, all works fine.
But not when call is established between SIP and chan_mobile (through simple bridge).
SIP -> mobile is clear and fine with controllable packet size in sip.conf
Reverse direction voice going in too small packets causing near 180 kbits/s and loosing packets because of out of order on SIP phone side (if not enabled permissive mode on RTP).
So question is how to increase packets size originated by chan_mobile and going to SIP?
Setting like
allow=ulaw:100
not works in chan_mobile.conf
Chan mobile to chan_sip connection is via sln internal bridge ALWAYS.
You can control only outgoing packets(from your server sip to remote sip) by set
allow=g729:20
Or similar form. Please note, that codec should support length of packet you asking.
You have no any way control other side, so no way control inbound direction.
For more info see https://wiki.asterisk.org/wiki/display/AST/RTP+Packetization
Related
When I capture network packets with wireshark or tcpdump on Linux, very often it saves segmented TCP which wireashark can reassemble (as long as Edit->Preferences->Protocols ... has this options checked for a protocol, for example HTTP).
However, I thought that the TCP/IP stack would reassemble the packets before delivering it to the user application, e.g. a WEB browser.
So my question is: is capturing packets bypassing some portion of TCP/IP stack?
Short answer: yes
Longer answer: "packet capturing" doesn't interfere with the normal packet handling -- it just makes copies of the packets at a point where they pass through the kernel. The normal place for this to happen is between the device driver and the networking stack, but depending on how you have filtering set up, it can happen other places as well.
I'm developing software feature for a Session Boarder Controller(SBC).
I'm trying to establish a SIP call using two SIP clients and a Session Boarder Controller(SBC). Asterisk is used as the soft-switch.
When I call, the SIP signalling is working fine. But I am getting audio only in one direction. I captured rtp packets on all interfaces using wireshark. I observed that rtp packets in one direction is being dropped by asterisk.
Note: There is no send only attribute in any of the SIP/SDP messages.
I would like to know if there is any settings in asterisk that may cause this issue?
One more thing that I would like to know is that, from where a SIP client gets the RTP connection information. The port information is present in the media attribute
m=audio 16388 RTP/AVP 8 0 101
From where does the client get the transport IP address? is it from the "o=" field or "c=" field in the SDP or any other fields in the SDP or SIP?
You should troubleshoot the problem by capturing the complete call with Wireshark. Then look carefully at:
Client A initial INVITE: which port is it expecting media on (m= line) which address is it expecting media on (c= line)
SBC for Client A initial INVITE: If the SBC is anchoring the media (I assume so) check m / c lines
SBC for Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client A expecting media on
Client B initial INVITE: Which port / ip (m/c lines) is SBC for Client B expecting media on
Are all nodes in this direction sending media on to the correct ports / ips (look at the RTP streams in wireshark)?
Then check the other direction (based on the SDP in the 183 or 200 (depending on your signaling flow)).
Note: In wireshark there is a nice feature which helps alot: Telephony --> VoIP Calls, which shows you the call flow more graphically
I am using csipsimple as sip client and asterisk server to set up call. Calls are made between 2 sip clients but voice is not getting transferred.
Calls are made between 2 sip clients using AMI.
I can give my asterisk cli log.
Can anybody please give me some idea to solve this issue?
Thanks
More info would be useful. First, make sure both clients are registered, and can use at least one common codec. In most cases, these aren't the problem. It's usually a NAT/Firewall issue. Are the two clients on the same subnet? Is there any firewall rules blocking the communication?
SIP signaling usually goes on udp:5060. But that seems working. Media is tricky. In each call, the ports for RTP audio changes, in the range specified in rtp.conf. This RTP traffic goes over UDP as well. By default it't 10000-20000.
If there is only routing done between the two endpoints, it should still be fine. NAT (Network Address Translation) is your main concern. Take a look at iptables, sip_nat_conntrack. To debug, use asterisk's sip set debug on command and look for the SIP headers and verify the correct IP addresses.
I have an RN-171 wifly module connected with a micro-controller.
I am using the UDP-protocol to communicate with the module. Also, I am using the firmware's UDP auto-pair feature to set the host ip. As soon as the module receives a UDP packet, it sets the host IP address to the ip from where it received the data. Now, this host ip cannot be changed without entering into the command mode.
I want the module to behave in the following way:
Every time it receives a UDP packet, it updates the host ip to the ip address from where that signal came from.
Also, I can use the TCP protocol but it only allows a single connection at a time. One more problem that I faced using the TCP protocol was that if I try to initiate a second TCP connection with the module, it not only refuses the second connection but also hangs the first stable connection. Even if the second connection initiation does not hang the module and it just gets refused, I will be ready to work with TCP.
I have been researching a lot on the web regarding this problem but since these modules are not widely used, they have a very limited support.
I've used RN-171 extensively and have many resolved tickets in their support system.
According to the WiFly Command Reference, Advanced Features and Applications User’s Guide, you cannot open more than one TCP port with the module. (the default number being 2000)
Unfortunately, regarding the UDP functionality, there's not much you can do. If you have a new host wishing to communicate over UDP, connect to the module over TCP, go into command mode and set the address using "$$$", "set ip host 0.0.0.0", "save", "exit" commands. Alternatively, instead of 0.0.0.0, you can enter the new host's own ip address: "$$$", "set ip host ###.###.###.###", "exit". Replace "###.###.###.###" with the ip address of the device.
This way, you won't get wrong host ip in case more than one device communicates over UDP at the same time. Also, by not using "save", the auto-pairing will still be saved to EEPROM memory. Also, you can send "ip flags 0x##" before "exit", this way you can also set bit[6] to 0 (UDP auto pairing disabled) temporarily by using the hex value that has this bit set to zero.
One of my problems that Microchip technical support tested around the summer of 2013 is that you cannot use RN-171 as an access point for other RN-171s since they have a firmware error preventing one from doing that and, as of firmware v4.41, released in January of 2014, there is no fix yet nor planned.
I myself do not recommend the latest firmware version v4.41, since it does not appear to work with most routers; however Soft AP mode on this works fine. On the other hand, v4.00.1 is much more compatible, however you should take care when cutting off the power since it has a potentially disastrous bricking problem if you cut the power when flash writing is in progress - the module may lock its memory forever.
I recommend registering and opening a Microchip ticket which usually will be answered within two business days and they're quite supportive. Their firmware update cycle is however quite long, and it usually takes a year or so for a new update.
In my college lab, all the PCs are connected via a hub. I want to capture data packets using Wireshark, but it only displays the interface of my own PC. How can I capture the packets of other PCs?
I've tried all the interfaces, and I can't get it to work.
Odds are you're connected to a switch rather than a hub. The problem there is that only packets intended for your network card's hardware (MAC) address and broadcast packets will be sent to your PC. The switch remembers the hardware address of devices plugged into it and performs packet forwarding based on those addresses. This vastly increases the potential bandwidth of your network segment, but makes snooping on other traffic more difficult. You will need to perform what's called ARP cache poisoning. Basically you need to trick every other computer connected to the switch to send its traffic to you rather than its true destination. You will then need to forward those packets not actually for you onto the correct destination otherwise it will take down the entire segment you're on and people will get nosy.
This type of redirection is possible, but it seems like you'll need to do quite a bit more research and understand exactly what is going on before attempting it. To get started, look into the Address Resolution Protocol; understand what a "layer 2" switch is doing; find out how to inject and reroute packets on the network; think about the consequences of getting caught.
If you're serious about moving forward, check out http://www.admin-magazine.com/Articles/Arp-Cache-Poisoning-and-Packet-Sniffing for some starting tips.