Android-WebRTC: MediaStream.removeVideoTrack is called after setting local description - java

We are developing an Android Application with Scala, WebRTC and the Java SDK. Our current task consists of receiving the remote track that is sent in a second SDP negotiation when the Callee enables video. Thus the Caller is accessing that video track in the onAddTrack method of the peer-connection observer. In fact, the track is contained in the Array of MediaStreams, and then we are able to attach it to the VideoRenderer via a ProxySink - pretty much like in this example: https://webrtc.googlesource.com/src/+/refs/heads/master/examples/androidapp/src/org/appspot/apprtc/CallActivity.java#133.
This is the piece of code in charge of that:
override def onAddTrack(rtpReceiver: RtpReceiver, mediaStreams: Array[MediaStream]): Unit = {
info("FLOW: onAddTrack")
rtpReceiver.SetObserver(rtpObserver)
call.getCallType match {
case BothVideo(CallRoles.Caller) | RecvPeerVideo(CallRoles.Caller) => {
if (mediaStreams.size > 0) {
val mediaStream = mediaStreams(0)
val videoTracks: Buffer[VideoTrack] = mediaStream.videoTracks.asScala
this.remoteMediaStream = Some(mediaStream)
info(s"FLOW: onAddTrack, call-type: ${call.getCallType}")
if (call.callerShouldReceiveVideo(call.getCallType) && videoTracks.size > 0) {
info(s"FLOW: onAddTrack, enabling video-track")
val videoTrack: VideoTrack = videoTracks(0)
mediaStream.addPreservedTrack(videoTrack)
videoTrack.setEnabled(true)
videoTrack.addSink(flowManager.remoteProxySink)
...
}
}
}
The problem is that we are not able to get the frames from the Callee's remote track, and this is a bit surprising since we were already able to successfully set the Caller's remote track and render the frames when the Caller initiates the call with video and has to send the remote track to Callee.
We have detected that dispose is being called on the MediaStream (https://webrtc.googlesource.com/src/+/refs/heads/master/sdk/android/api/org/webrtc/MediaStream.java#75) right after setLocalDescription is called in the SdpObserver set when creating the answer, and we think this might be cause of our issue.
Creating answer:
pcConn.setRemoteDescription(sdpObserver, sdp)
peerConn.createAnswer(sdpObserver, WebRTCCall.sdpMediaConstraints())
In SdpObserver:
override def onCreateSuccess(sdp: SessionDescription) = {
...
peerConn.setLocalDescription(this, sdp)
...
}
What can be triggering the MediaStream.dispose method inside native setLocalDescription ?
Update
We found something interesting in the sdp, video track seems to have sendonly direction.
v=0
o=- 2191449863069826960 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 2 3
a=msid-semantic: WMS stream0
m=audio 56825 UDP/TLS/RTP/SAVPF 111 103 9 102 0 8 105 13 110 113 126
c=IN IP4 35.167.127.194
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:2294452033 1 udp 2122260223 192.168.2.159 60968 typ host generation 0 network-id 3 network-cost 10
a=candidate:559267639 1 udp 2122202367 ::1 39373 typ host generation 0 network-id 2
a=candidate:1510613869 1 udp 2122129151 127.0.0.1 56438 typ host generation 0 network-id 1
a=candidate:1876313031 1 tcp 1518222591 ::1 59473 typ host tcptype passive generation 0 network-id 2
a=candidate:344579997 1 tcp 1518149375 127.0.0.1 47922 typ host tcptype passive generation 0 network-id 1
a=candidate:842163049 1 udp 1686052607 201.233.49.70 60968 typ srflx raddr 192.168.2.159 rport 60968 generation 0 network-id 3 network-cost 10
a=candidate:1600295039 1 udp 41885439 35.167.127.194 56825 typ relay raddr 201.233.49.70 rport 60968 generation 0 network-id 3 network-cost 10
a=candidate:3811514541 1 udp 41885695 34.221.141.99 60923 typ relay raddr 201.233.49.70 rport 60968 generation 0 network-id 3 network-cost 10
a=ice-ufrag:GGkb
a=ice-pwd:owqpzSht95NQb92cgzKNkQmJ
a=ice-options:trickle renomination
a=fingerprint:sha-256 45:76:5A:81:C1:CD:6B:C8:17:C6:CB:7B:20:CD:C6:DD:59:A3:DC:11:47:78:D3:E1:E1:EE:55:1F:83:A5:32:E4
a=setup:passive
a=mid:0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:stream0 audio0
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:9 G722/8000
a=rtpmap:102 ILBC/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:1249625177 cname:IgXNTJvPXp2HndWi
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 127
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:GGkb
a=ice-pwd:owqpzSht95NQb92cgzKNkQmJ
a=ice-options:trickle renomination
a=fingerprint:sha-256 45:76:5A:81:C1:CD:6B:C8:17:C6:CB:7B:20:CD:C6:DD:59:A3:DC:11:47:78:D3:E1:E1:EE:55:1F:83:A5:32:E4
a=setup:passive
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:12 urn:3gpp:video-orientation
a=extmap:2 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://tools.ietf.org/html/draft-ietf-avtext-framemarking-07
a=extmap:9 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendonly
a=msid:stream0 video0
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 red/90000
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:127 ulpfec/90000
a=ssrc-group:FID 1487952389 3127747783
a=ssrc:1487952389 cname:IgXNTJvPXp2HndWi
a=ssrc:3127747783 cname:IgXNTJvPXp2HndWi
m=application 9 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
b=AS:30
a=ice-ufrag:GGkb
a=ice-pwd:owqpzSht95NQb92cgzKNkQmJ
a

Related

Java: HttpServletRequest.getRemoteAddr() not shows IP same as CURL or IFConfig

My QA Server IFConfig is showing following IP:
docker0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 172.16.0.1 netmask 255.255.0.0 broadcast 0.0.0.0
ether 02:42:73:6e:ba:54 txqueuelen 0 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eno16780032: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 146.213.179.50 netmask 255.255.255.210 broadcast 146.213.179.119
inet6 fc80::250:56ff:fea0:6dc9 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:a0:6d:b9 txqueuelen 1000 (Ethernet)
RX packets 529734790 bytes 285217050121 (265.6 GiB)
RX errors 0 dropped 19 overruns 0 frame 0
TX packets 502519153 bytes 423616456297 (394.5 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eno33559296: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.1.2 netmask 255.255.255.240 broadcast 10.0.1.14
inet6 fc80::250:56ff:fea0:498c prefixlen 64 scopeid 0x20<link>
ether 00:50:56:a0:49:8b txqueuelen 1000 (Ethernet)
RX packets 176687369 bytes 54833457460 (51.0 GiB)
RX errors 0 dropped 14 overruns 0 frame 0
TX packets 180706064 bytes 34257419515 (31.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
eno50338560: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.0.2.8 netmask 255.255.255.240 broadcast 10.0.2.10
inet6 fc80::250:56ff:fca0:67c7 prefixlen 64 scopeid 0x20<link>
ether 00:50:56:a0:67:a7 txqueuelen 1000 (Ethernet)
RX packets 3322039516 bytes 2382840054404 (2.1 TiB)
RX errors 0 dropped 20 overruns 0 frame 0
TX packets 2212620398 bytes 2317370292546 (2.1 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 0 (Local Loopback)
RX packets 130568922 bytes 39557947765 (36.8 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 130568922 bytes 39557947765 (36.8 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
When i use curl command on QA; it shows following:
curl bot.whatismyipaddress.com
153.110.231.215
But when i write following java Rest API on same Machine (wildfly server)
and call that API from another client in same machine (wildfly server) using public domain name. I get following IP:
146.192.61.46
Code:
#GetMapping("/customers/all")
public List<XxtoneCustomersV> getAllCustomers(HttpServletRequest request){
LOG.info("Remote Addr: " + request.getRemoteAddr());
When i hit same rest api from local i get my correct IP Address.
Why is such difference in IP in linux commands and java code? Am i using correct java method?
Also the one i retrieved from Curl appears Public IP (if ifconfig returns internal ones) so same should not get in remoteAddr?
This is probably because the second client in the QA machine routes the request through local interface instead of the Internet. To overcome this, first check which IP the second client resolves for the public domain name. If it resolves an internal IP, then you may add the public IP to the host file to force the second client to use Internet route.

Java InetAddress.getLocalHost().getHostAddress() returns invalid IP

And when I say invalid, I mean invalid. I get an IP address that's not associated with any of my machine's interfaces. I'm aware there are similar questions on the site, but they're more about people getting the address of an interface they didn't want (e.g., 127.0.0.1 instead of LAN IP), but this is not that. I want to know where this IP is coming from, and how do I get rid of it.
Whenever I call InetAddress.getLocalHost().getHostAddress(), I get 10.65.90.34. This is not the assigned IP from my router, my ISP, my VPN, anything. There is no mentiond of this IP in the output from ifconfig. I have no idea where this IP is coming from. It was suggested to enumerate all interfaces on a different question, and here's what I get when I do that:
public void localIPTest() throws UnknownHostException, SocketException {
String hostAddress = InetAddress.getLocalHost().getHostAddress();
System.out.println(hostAddress);
Enumeration Interfaces = NetworkInterface.getNetworkInterfaces();
while (Interfaces.hasMoreElements()) {
NetworkInterface Interface = (NetworkInterface) Interfaces.nextElement();
System.out.println(Interface.getDisplayName());
Enumeration Addresses = Interface.getInetAddresses();
while (Addresses.hasMoreElements()) {
InetAddress Address = (InetAddress) Addresses.nextElement();
System.out.println(Address.getHostAddress());
}
}
}
This outputs:
10.65.90.34
utun0
fe80:0:0:0:a3c9:7561:3c37:3943%utun0
awdl0
fe80:0:0:0:b458:bbff:feac:2ee8%awdl0
utun1
172.20.97.60
en0
fe80:0:0:0:c88:b30a:16fc:4dbe%en0
192.168.0.106
lo0
fe80:0:0:0:0:0:0:1%lo0
0:0:0:0:0:0:0:1
127.0.0.1
This issue only happens when I am connected to my company's VPN network. And yet this IP is not coming from the VPN interface (utun1) - as can be seen in the above output that is 172.xx.
I tried to see whether this IP is coming from the underyling OS (macOS in my case), but that's not the case either.
$  ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*'
inet 127.0.0.1
inet 192.168.0.106
inet 172.20.97.60
$  curl ifconfig.me
183.82.20.54
Output of traceroute 8.8.8.8 as suggested:
$  traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 192.168.0.1 (192.168.0.1) 2.317 ms 1.067 ms 0.847 ms
2 broadband.actcorp.in (106.51.140.1) 2.220 ms 2.585 ms 2.501 ms
3 broadband.actcorp.in (202.83.20.173) 3.120 ms 2.199 ms 4.124 ms
4 broadband.actcorp.in (202.83.20.181) 2.501 ms 2.534 ms 2.635 ms
5 * * *
6 72.14.194.18 (72.14.194.18) 43.590 ms 41.858 ms 42.637 ms
7 74.125.242.131 (74.125.242.131) 42.560 ms
108.170.253.121 (108.170.253.121) 42.911 ms
108.170.253.122 (108.170.253.122) 40.468 ms
8 72.14.239.59 (72.14.239.59) 42.028 ms
74.125.252.165 (74.125.252.165) 41.743 ms
209.85.248.251 (209.85.248.251) 43.130 ms
9 64.233.175.215 (64.233.175.215) 41.679 ms
72.14.236.223 (72.14.236.223) 43.124 ms
209.85.242.12 (209.85.242.12) 42.816 ms
10 216.239.35.145 (216.239.35.145) 42.076 ms
66.249.94.185 (66.249.94.185) 42.791 ms
216.239.35.167 (216.239.35.167) 42.456 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * google-public-dns-a.google.com (8.8.8.8) 41.985 ms *
Also adding full output for ifconfig:
$  ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
options=1203<RXCSUM,TXCSUM,TXSTATUS,SW_TIMESTAMP>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
nd6 options=201<PERFORMNUD,DAD>
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
XHC20: flags=0<> mtu 0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether a4:5e:60:e5:b2:8b
inet6 fe80::c88:b30a:16fc:4dbe%en0 prefixlen 64 secured scopeid 0x5
inet 192.168.0.104 netmask 0xffffff00 broadcast 192.168.0.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
p2p0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 2304
ether 06:5e:60:e5:b2:8b
media: autoselect
status: inactive
awdl0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1484
ether b6:58:bb:ac:2e:e8
inet6 fe80::b458:bbff:feac:2ee8%awdl0 prefixlen 64 scopeid 0x7
nd6 options=201<PERFORMNUD,DAD>
media: autoselect
status: active
en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether 6a:00:00:58:9d:c0
media: autoselect <full-duplex>
status: inactive
en2: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=60<TSO4,TSO6>
ether 6a:00:00:58:9d:c1
media: autoselect <full-duplex>
status: inactive
bridge0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=63<RXCSUM,TXCSUM,TSO4,TSO6>
ether 6a:00:00:58:9d:c0
Configuration:
id 0:0:0:0:0:0 priority 0 hellotime 0 fwddelay 0
maxage 0 holdcnt 0 proto stp maxaddr 100 timeout 1200
root id 0:0:0:0:0:0 priority 0 ifcost 0 port 0
ipfilter disabled flags 0x2
member: en1 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 8 priority 0 path cost 0
member: en2 flags=3<LEARNING,DISCOVER>
ifmaxaddr 0 port 9 priority 0 path cost 0
nd6 options=201<PERFORMNUD,DAD>
media: <unknown type>
status: inactive
utun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 2000
inet6 fe80::a3c9:7561:3c37:3943%utun0 prefixlen 64 scopeid 0xb
nd6 options=201<PERFORMNUD,DAD>
utun1: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
inet 172.20.97.60 --> 172.20.97.60 netmask 0xffffffff
From the docs for InetAddress.getLocalHost():
This is achieved by retrieving the name of the host from the system, then resolving that name into an InetAddress.
So if you have a bogus hostname, then this function will return a bogus IP address.
You can run the hostname command to see what your machine reports as its hostname, then use nslookup to see what that name resolves to (or alternatively, ping $(hostname), which will do the name resolution).
If that is the problem, and you have admin access on your Mac, then you can change the name (see man hostname for instructions). However, you'll probably need to talk with your IT department to learn what the correct hostname should be.
Finally managed to fix it.
The issue, as #guest pointed out, is for some reason connecting to VPN messes up name resolution, so that my localhost is resolved to some remote IP.
The solution was to simply add an /etc/hosts entry, manually mapping my hostname to 127.0.0.1. That fixed it.

vmstat pidstat result analysis for Java program

vmstat 1 100
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
1 0 0 2307452 283392 712136 0 0 2 2 17 21 0 1 99 0 0
3 0 0 2307436 283392 712136 0 0 0 0 10677 3455 21 43 35 0 0
4 0 0 2307436 283392 712136 0 0 0 0 10700 3620 22 42 36 0 0
3 0 0 2307436 283392 712136 0 0 0 0 10549 3523 21 43 36 0 0
pidstat -I -w -p 3809 2
PID cswch/s nvcswch/s Command
3809 0.00 0.00 java
3809 0.00 0.00 java
3809 0.00 0.00 java
I am doing a pressure test. The server program is a WebSocket server, which accepts 10,000 client connections. Each client connection sends a message to server every 2 seconds, and server responds a message to each client every 2 seconds.
My question is :
1) From vmstat 1 100, it seems that the cpu( sy is 42%, us is 21% around) is doing much system-level work instead of user-level work. So I think there are too much context switch for CPU.
However, from pidstat, the cswch/s and nvcswch/s are all 0 for the server program. I think this result means that there are not much context switch for CPU.
Could anybody help explain the result of the Linux server monitoring result?
pidstat is referencing to process 3809
vmstat is measuring all the processes of the system cause you set only the sampling frequency

pcap4j gotPacket(..) returns non ascii chars before SIP message. Why?

I am using PCap4j (a simple Java wrapper for libpcap) to sniff SIP packets on localhost in promiscuous mode. The SIP packets are sent and received by SIPP - a SIP packet test generator.
When receiving a UDP packet in the gotPacket() method, there are a number of strange chars in the start of the received raw packet data. Why is this so? What am I missing here?
I need the buffer to start with SIP INVITE. Is there another protocol wrapping the SIP data? How does one reliably remove the gibberish in the front from the SIP messages. The libpcap filter is set to "udp port sip".
Much appreciate
PacketListener listener = new PacketListener() {
public void gotPacket(Packet packet) {
String p = new String(packet.getRawData());
System.out.println(p);
}
}
E(0#��(INVITE sip:service#127.0.0.1:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5061;branch=z9hG4bK-99365-511233-0
From: sipp <sip:sipp#127.0.0.1:5061>;tag=99365SIPpTag00511233
To: service <sip:service#127.0.0.1:5060>
Call-ID: 511233-99365#127.0.0.1
CSeq: 1 INVITE
Contact: sip:sipp#127.0.0.1:5061
Max-Forwards: 70
Subject: Performance Test
Content-Type: application/sdp
Content-Length: 129
v=0
o=user1 53655765 2353687637 IN IP4 127.0.0.1
s=-
c=IN IP4 127.0.0.1
t=0 0
m=audio 6001 RTP/AVP 0
a=rtpmap:0 PCMU/8000
A packet in gotPacket() includes an Ethernet header, an IP header, and a UDP header (if you get it from Ethernet network).
To get its UDP payload, do the following: packet.get(UdpPacket.class).getPayload().getRawData()

How to connect asterisk to skype using siptosis?

I've been trying to do this for weeks and still have not yet figured out how to connect to skype. The best progress I've found out was from this tutorial
http://translate.google.com/translate?hl=en&sl=it&u=http://www.voipandhack.it/archives/linux/asterisk-failover-e-registrazioni-sip&ei=nqJRTNTPB8OfrAfDovGDAw&sa=X&oi=translate&ct=result&resnum=2&ved=0CBoQ7gEwAQ&prev=/search%3Fq%3Dasterisk%2Bauto%2Bfallthrough%2Bsiptosis%26hl%3Den
But whenever I tried to make an echo123 call, my asterisk would show
== Using SIP RTP CoS mark 5
-- Executing [*123#phones:1] Dial("SIP/1004-00000030", "SIP/siptosisuser/echo123") in new stack
== Using SIP RTP CoS mark 5
-- Called siptosisuser/echo123
-- SIP/siptosisuser-00000031 is ringing
-- SIP/siptosisuser-00000031 is circuit-busy
== Everyone is busy/congested at this time (1:0/1/0)
-- Auto fallthrough, channel 'SIP/1004-00000030' status is 'CONGESTION'
and my siptosis will show:
2010-07-30 10:48:21,596 Failed to select RTP format
2010-07-30 10:48:21,597 ### local descriptor=v=0
o=skypests 1280512101 0 IN IP4 192.168..
s=Session SIP/SDP
c=IN IP4 192.168..
t=0 0
m=audio 63202 RTP/AVP 0 8 98 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:98 iLBC/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=silenceSupp:off
2010-07-30 10:48:21,597 ### remote descriptor=v=0
o=root 1729829715 1729829715 IN IP4 127.0.0.1
s=Asterisk PBX 1.6.2.8
c=IN IP4 127.0.0.1
t=0 0
m=audio 18104 RTP/AVP 3 101
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv
I've changed my IP address to 192.168.. just for security reasons. It seems to be connecting one way or another but I'm assuming I'm doing something wrong somewhere in the code? I also haven't touched the siptosis.cfg because the tutorial I specified didn't do it. The cfg file also didn't come with the siptosis package I downloaded but I was able to find a copy from another tutorial on the nerdvittle website
This is suppose to be the tutorial that makes it easy to setup but it doesn't seem to work on mine. I just want to have some call to echo123 and it seemed to be not working. I'm working on ubuntu and most tutorials are on CentOS so there's not much to solve my problem. I also am not using static skype, will that be a problem?
Any hints/tip/answers would be very much appreciated!
Thank you for your time and thank you in advance!
I'm not familiar with SipToSis but you may want to look at the Skype Connect (previously known as Skype for SIP) solution which allows you to make and receive calls direct to/from sip.skype.com using SIP. Unlike Skype for Asterisk, it's free.
Apologies if you already know this and are looking for specific features of SipToSis which are not provided by Skype Connect. Good luck.

Categories