I can register from my webclient to my freeswitch. But, when I try to make call the call gets rejected with 488 not acceptable here. From freeswitch console log im getting.
2014-07-22 22:03:59.673585 [DEBUG] switch_core_state_machine.c:53 sofia/internal/alice#192.168.146.133 Standard REPORTING, cause: INCOMPATIBLE_DESTINATION
I added
< action application="export" data="rtp_secure_media=true" />
with my extension; but no luck.
below is the SDP of my INVITE
v=0
o=Mozilla-SIPUA-31.0 26508 1 IN IP4 0.0.0.0
s=Doubango Telecom - firefox
t=0 0
a=ice-ufrag:13497e25
a=ice-pwd:515d61f08d909117e022674f3dce748e
a=fingerprint:sha-256 2E:CF:7E:8F:EC:1A:F4:B1:D3:CF:39:C3:8A:A0:D0:53:B3:46:00:D0:93:46:53:29:AB:B7:03:83:39:FB:23:32
m=audio 55760 UDP/TLS/RTP/SAVPF 109 0 8 101
c=IN IP4 184.69.59.132
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=setup:actpass
a=candidate:0 1 UDP 2128609535 172.16.1.188 55760 typ host
a=candidate:1 1 UDP 1692467199 184.69.59.132 55760 typ srflx raddr 172.16.1.188 rport 55760
a=candidate:5 1 UDP 2128543999 192.168.56.1 55761 typ host
a=candidate:10 1 UDP 2128478463 192.168.232.1 55762 typ host
a=candidate:15 1 UDP 2128412927 192.168.146.1 55763 typ host
a=candidate:0 2 UDP 2128609534 172.16.1.188 55764 typ host
a=candidate:1 2 UDP 1692467198 184.69.59.132 55764 typ srflx raddr 172.16.1.188 rport 55764
a=candidate:5 2 UDP 2128543998 192.168.56.1 55765 typ host
a=candidate:10 2 UDP 2128478462 192.168.232.1 55766 typ host
a=candidate:15 2 UDP 2128412926 192.168.146.1 55767 typ host
a=rtcp-mux
Below is my codec lists from freeswitch. I dont have opus installed, but I do have G711 ulaw and alaw
show codecs
type,name,ikey
codec,ADPCM (IMA),mod_voipcodecs
codec,AMR,mod_amr
codec,G.711 alaw,CORE_PCM_MODULE
codec,G.711 ulaw,CORE_PCM_MODULE
codec,G.722,mod_voipcodecs
codec,G.723.1 6.3k,mod_g723_1
codec,G.726 16k,mod_voipcodecs
codec,G.726 16k (AAL2),mod_voipcodecs
codec,G.726 24k,mod_voipcodecs
codec,G.726 24k (AAL2),mod_voipcodecs
codec,G.726 32k,mod_voipcodecs
codec,G.726 32k (AAL2),mod_voipcodecs
codec,G.726 40k,mod_voipcodecs
codec,G.726 40k (AAL2),mod_voipcodecs
codec,G.729,mod_g729
codec,GSM,mod_voipcodecs
codec,H.261 Video (passthru),mod_h26x
codec,H.263 Video (passthru),mod_h26x
codec,H.263+ Video (passthru),mod_h26x
codec,H.263++ Video (passthru),mod_h26x
codec,H.264 Video (passthru),mod_h26x
codec,LPC-10,mod_voipcodecs
codec,PROXY PASS-THROUGH,CORE_PCM_MODULE
codec,PROXY VIDEO PASS-THROUGH,CORE_PCM_MODULE
codec,Polycom(R) G722.1/G722.1C,mod_siren
codec,RAW Signed Linear (16 bit),CORE_PCM_MODULE
codec,Speex,mod_speex
codec,iLBC,mod_ilbc
What can be the issue?
Based on the logs it could also be a compatibilty issue with the m line that has all the transport protocols listed together.
UDP/TLS/RTP/SAVPF. This can be subject to compatibility issues as mentioned in these threads. Maybe you could try to restrict it to the simpler form and try it if possible.
https://code.google.com/p/webrtc/issues/detail?id=2796
http://lists.freeswitch.org/pipermail/freeswitch-users/2013-July/097617.html
Most often a 488 rejection is caused by codec mismatch. Please check the FS and the WebRTC settings. Usually WebRTC uses Opus so you need to make sure that selected in the FS Config [if possible].
A PCAP of the Issue or screen shots of the INVITE and the 488 can help narrow down the problem further.
Related
I am successfully using Kurento's RtpEndpoint type to connect to several Asterisk SIP servers as well as directly to several models of SIP phone, but connections to Avaya SIP servers do not work, and I am trying to figure out why. The symptom is that the connection is made but there is no media.
For the RTP Endpoint, Kurento generates the following SDP (which I munge to include the public IP address and remove the video portion) which I then include in the SIP INVITE:
v=0
o=- 3807878922 3807878922 IN IP4 192.0.2.95
s=Kurento Media Server
c=IN IP4 192.0.2.95
t=0 0
m=audio 18848 RTP/AVPF 96 0 97
a=setup:actpass
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=rtpmap:96 opus/48000/2
a=rtpmap:97 AMR/8000
a=rtcp:18849
a=sendrecv
a=mid:audio0
a=ssrc:2835743000 cname:user3268188862#host-ad591d54
A working connection with an Asterisk server returns the following SDP back to Kurento:
v=0
o=root 55778749 55778749 IN IP4 198.51.100.252
s=Asterisk PBX 13.28.1
c=IN IP4 198.51.100.252
t=0 0
m=audio 11704 RTP/AVPF 0
a=rtpmap:0 PCMU/8000
a=maxptime:150
a=sendrecv
In the Kurento log, I see that it says it is transcoding this connection.
A non-working connection with an Avaya server returns the following SDP back to Kurento:
v=0
o=- 1598890119 2 IN IP4 203.0.113.100
s=-
c=IN IP4 0.0.0.0
b=AS:64
t=0 0
m=audio 0 RTP/AVP 96 0 97
a=inactive
a=rtpmap:96 opus/48000/2
a=rtpmap:97 AMR/8000
a=ptime:20
As you can see, the Avaya server responds that it cannot use any of the available codecs and therefore will not send or receive media (a=inactive).
According to some Avaya documentation I found, Avaya SBCE supports transcoding at least the following codecs:
OPUS 12kbps narrowband
OPUS 16kbps narrowband
OPUS 18kbps wideband
G.722
G.711ulaw
G.711alaw
G.726
G.729AB
Kurento supports using PCMU (a.k.a. G.711ulaw) as shown in the working Asterisk sample, but Avaya seems to reject it. (Note: I previously thought that it wasn't included in the SDP, but it is there as the 0 in the m=audio line.) I tried to get it to force using PCMU using rtpEndpoint.setAudioFormat(AudioCaps(AudioCodec.PCMU, 8000)), but that didn't help.
My second thought was to change the OPUS bitrate using rtpEndpoint.setAudioFormat(AudioCaps(AudioCodec.OPUS, 18000)). When I tried this, not only did it not work with the Avaya phones, but it also stopped working with Asterisk since Asterisk was using PCMU. I thought of munging the SDP to change it to opus/18000, but that's not allowed, as RFC 7587 explicitly states:
The media subtype ("opus") goes in SDP "a=rtpmap" as the encoding
name. The RTP clock rate in "a=rtpmap" MUST be 48000, and the
number of channels MUST be 2.
How can I get Kurento and the Avaya SBCE to send media between themselves?
In the end, the only way I could get it to work was to put a Kamailio/RTPEngine server in between them and allow it to negotiate separately with both sides.
I have a TCP server and multiple clients attempting to connect to that server almost simultaneously. I notice that:
On the client side, connect may return 0 even though the 3-way handshake has not been completed yet.
On the server side, accept may not return even after the 3-way handshake has been completed.
To illustrate both points, here are the Wireshark traces (server is listening on port 1234):
1. Here are the Wireshark traces for the case where client's connect returns 0 even though the 3-way handshake has not been completed (missing last SYN from client):
// calls ::connect ...
59507 → 1234 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
1234 → 59507 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
// ... and ::connect returned 0, despite the above 2 lines
// forming an incomplete handshake. Why?
// after the ::connect, client calls ::send to send 8 bytes ...
59507 → 1234 [PSH, ACK] Seq=1 Ack=1 Win=262656 Len=8
// ... but we got reset by peer
1234 → 59507 [RST] Seq=1 Win=0 Len=0
// ... and as expected, ::send returned 10054 (WSAECONNRESET)
2. Server's accept doesn't return even after the 3-way handshake has been completed:
// server calls ::accept ...
59643 → 1234 [SYN] Seq=0 Win=64240 Len=0 MSS=1460 WS=256 SACK_PERM=1
1234 → 59643 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=256 SACK_PERM=1
59643 → 1234 [ACK] Seq=1 Ack=1 Win=262656 Len=0
// At this point, we have a complete handshake, but server's ::accept doesn't return. Why?
// In the next line, server sends a RST. This doesn't cause the server's ::accept call
// to return an INVALID_SOCKET, which doesn't seem unreasonable (since nothing is accepted),
// nor is this the point of the question, but I am including the RST trace here
// for completeness. The main point is that it's as if server's ::accept is oblivious
// to the successful handshake.
1234 → 59643 [RST] Seq=1 Win=0 Len=0
Questions:
When, exactly, does connect return? Apparently the traces above suggests that connect can return (and declare success with return value of 0) even if the handshake is incomplete.
When, exactly, does accept return? The traces above suggests that the completion of a 3-way handshake isn't good enough for accept to return, which is puzzling.
So, it's as if connect doesn't care about checking the handshake, while accept is so strict that a successful handshake is not good enough for it to return?
So to answer the question,
When does connect() and accept() return?
I am quoting from the source "Unix Network Programming" -- By W. Richard Stevens. The connect() returns after the first two steps of the handshake. While the accept() returns when an entry is placed in the completed queue. The meaning of queues are given as:
When the client requests a TCP connection, the server's TCP stack creates an entry in the incomplete queue, then the 3-way TCP handshake is managed by the server TCP stack. The connection is moved from the incomplete queue to the completed queue when the last message of the TCP handshake arrives (ACK or PiggyBacked ACK).
For other questions raised in the comments:
How does the backlog (2nd parameter of the listen()) affect the queue size?
backlog is not equal to the queue size, the queue size set by the backlog varies from system to system. Below table lists the backlog and corresponding queue values for some systems:
What does the server do when it gets SYN, and the queue is full?
If the queues are full when a client SYN arrives, TCP ignores the arriving SYN (pp. 930-931 0f TCPv2); it does not send an RST. Because the condition is considered temporary, and the client may retry after sometime, hoping to find the place in the queue. If instead RST is sent, then it is ambiguous whether the server queues are full or the server is not listening on that port.
In freeswitch dialplan I create a extension debug_001 and bridge to another freeswitch instance.
<extension name="debug_001">
<condition field="destination_number" expression="^\+(49301234567)$">
<action application="export" data="sip_invite_params=user=phone"/>
<action application="export" data="sip_cid_type=pid"/>
<action application="export" data="t38_passthru=true"/>
<action application="export" data="sip_from_uri=${sip_from_uri}"/>
<action application="bridge" data="sofia/gateway/FS2/$1"/>
</condition>
</extension>
That works fine, the extension match in the right case and the call is bridged to FS2. But in case the FS2 instance send a reinvite the FS1 instance do not bridge the (re)inivte to the caller. In the reinvite there is set a custom header field we want to parse on the Caller site.
Here is a ladderdiagram that show the SIP Flow.
Or more detailed with this diagram:
FS1 do not bridge the reinvite to the Caller. Maybe the reinvite was parse as a keepalive between FS1 and FS2 because nothing is change in SDP or something else, only the custom header ist inserted. What action I should define to passthrough the (re)invite in any case?
I think the problem is that Freeswitch only bypass the (re)invite if the SDP of the (re)invite was changed, in that case the SDP isnt diffrent and sofia indicate this as Duplicate SDP, as you can see here:
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:46.508841 [DEBUG] sofia.c:7048 Channel sofia/external/49301234567 entering state [ready][200]
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:46.508841 [NOTICE] sofia.c:8123 Channel [sofia/external/49301234567] has been answered
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:46.508841 [DEBUG] switch_channel.c:3773 (sofia/external/49301234567) Callstate Change EARLY -> ACTIVE
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:46.568848 [DEBUG] switch_rtp.c:7254 Correct audio ip/port confirmed.
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:54.228841 [DEBUG] sofia.c:7048 Channel sofia/external/49301234567 entering state [received][100]
fac8529a-e0d9-11e8-91c6-0d38c130bd96 2018-11-05 10:05:54.228841 [DEBUG] sofia.c:7055 Duplicate SDP
fac8529a-e0d9-11e8-91c6-0d38c130bd96 v=0
fac8529a-e0d9-11e8-91c6-0d38c130bd96 o=- 1541408745 2 IN IP4 10.1.11.10
fac8529a-e0d9-11e8-91c6-0d38c130bd96 s=-
fac8529a-e0d9-11e8-91c6-0d38c130bd96 c=IN IP4 10.1.11.10
fac8529a-e0d9-11e8-91c6-0d38c130bd96 b=AS:64
fac8529a-e0d9-11e8-91c6-0d38c130bd96 t=0 0
fac8529a-e0d9-11e8-91c6-0d38c130bd96 m=audio 10374 RTP/AVP 8 101
fac8529a-e0d9-11e8-91c6-0d38c130bd96 a=rtpmap:8 PCMA/8000
fac8529a-e0d9-11e8-91c6-0d38c130bd96 a=rtpmap:101 telephone-event/8000
fac8529a-e0d9-11e8-91c6-0d38c130bd96 a=ptime:20
So I need a solution to tell sofia send also duplicated SDPs or that Sofia also parse the custom header field in the (re)invite Header. In this JIRA Ticket Brian West wrote that this behavior is a proxy Feature and Freeswitch isn't a proxy. But in our case the SDP is the same but the custom header field is diffrent so it isnt a Proxy Behavior and should be bypass to the diffrent Call-Leg.
If I want to alert the traffic with the snort rule alert:
Ethernet II, Src: Xircom_c5:7c:38 (00:10:a4:c5:7c:38), Dst: 3comCorp_a8:61:24 (00:60:08:a8:61:24)
Try to use:
alert tcp any any -> any any (content:"|00 60 08 a8 61 24|"; content:"|00 10 a4 c5 7c 38|"; nocase; msg:"Alert")
It looks not working.....
Snort does not work at MAC address level, it works with TCP, UDP, ICMP and IP protocols.
Your rule is a tcp rule and therefore will have a minimum 20 byte header, possibly up to 60 bytes depending on options.
Since snort content rules only match in the payload, this means that each of your content terms content:"|00 60 08 a8 61 24|" and content:"|00 10 a4 c5 7c 38|" will only match after the initial header (20 - 60 bytes).
I have read about SIP and RTP packet flows but ended with a question about RTP packets flow logic between client-to client when the SIP session starts.
I have a running Kamailio (V 4.0.4) server on ubuntu (12.04) platform which is also configured fro DNS and DHCP servers.
And following are my test bed set-ups:
Kamailio server
(DNS+ DHCP+Kamailio)
|
Router <----------------------------> Switch<----------------------------> Router
| |
clientA <--------------------- RTP(audio/video) ? --------------------> client B
Now when the SIP session established (SIP Packets have to pass through all the routers and switch to reach Kamailio server), RTP session will start between Client A and B. But What is meant by client to client here ?
what is the RTP packets path between the clients to reach their destinations ?
Is the RTP packets have to pass through Routers and switch to reach its destination client ? (i.e Client A--->Router 1---->switch -----> Router 2-----> client B) ?
What if i connect both client A and client B to the same router ?
PS: I have not configured any media-relays (RTPproxy/Media-proxy)
Please help me in clarifying all this doubts.
Anybody's help will greatly appreciate.
Regards,
Nandini
In a "normal" SIP call the media RTP gets send directly between the clients. If you sniff the SIP traffic you can see where it's going.
In the SIP INVITE dialog, the body of the INVITE message is normally in 'SDP' format. You can see that's it's SDP format because the SIP message should include something like:
Content-Type: application/sdp
The INVITE message will normally contain, what is known as the SDP offer, and the 200 OK response (when it comes) will normally contain the SDP answer.
An example:
[Offer]
v=0
o=alice 2890844526 2890844526 IN IP4 10.1.1.10
s=
c=IN IP4 10.1.1.10
t=0 0
m=audio 49170 RTP/AVP 0 8 97
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 iLBC/8000
[Answer]
v=0
o=bob 2808844564 2808844564 IN IP4 10.1.1.11
s=
c=IN IP4 10.1.1.11
t=0 0
m=audio 49174 RTP/AVP 0
a=rtpmap:0 PCMU/8000
In this offer/answer the audio media will sent / received between
10.1.1.10:49170 <--> 10.1.1.11:49174
The will only be a audio codec and it will be encoded in the G711u format (PCMU 8hz).
If you are asking how psychically the network traffic will travel between the two endpoints. The would greatly depend of the psychical network. Logically it's just sending packets to/from each of those addresses and it doesn't go through any 'server'.