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'.
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.
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.
During application sharing with Microsoft Lync Client (Mac OS X), TCP ACK with RST flag is sent from my application end to Lync end against TCP Zero Window packets and call gets dropped.
FYI:
My Application End: 172.16.6.106:55848
Lync End (Remote): 172.16.14.58:18627
Environment:
My Application End: Centos/Linux
Lync End: Mac OSX
Shared Over Wifi.
EDIT
Wireshark TCP Dump
Lync BYE message to my Application:
BYE sip:172.16.6.106:48038;transport=tls;ms-opaque=28c9d310c1;ms-received-cid=BEED00;grid SIP/2.0
ms-user-logon-data: RemoteUser
Via: SIP/2.0/TLS 172.16.6.252:5061;branch=z9hG4bKB5634D63.2E095CFF28141DF6;branched=FALSE;ms-internal-info="agIDti2ZsTK4cWfhAGG1qbj2usseveww7YKemPpN3Jvhv_XAkuuCofIQAA"
Max-Forwards: 67
Via: SIP/2.0/TLS 192.168.2.3:51217;branch=z9hG4bK77E14D58.4A2E43E7B13911D2;branched=FALSE;ms-received-port=51217;ms-received-cid=BEE600
Authentication-Info: NTLM qop="auth", opaque="4207B105", srand="D2C8703A", snum="21", rspauth="010000008bc2daa4dc3b08b864000000", targetname="Lync-FE.LTN2013-Dev.local", realm="SIP Communications Service", version=4
Via: SIP/2.0/TLS 192.168.2.4:50740;branch=z9hG4bKFF62C04C.B8AD61CF28131DF6;branched=FALSE;ms-received-port=50740;ms-received-cid=1117700
Via: SIP/2.0/TLS 172.16.14.58:30689;received=172.16.14.58;ms-received-port=57719;ms-received-cid=BEE400
From: "" <sip:test1#ltn2013-dev.net>;epid=48777ee2e9;tag=dd8ced12ab
To: <sip:ilanaroom#ltn2013-dev.net>;tag=1442263920;epid=14422639
Call-ID: RkdVRZrTUlhKLke0Et9MiVaJTOJd5UMJKljncCC1
CSeq: 1 BYE
User-Agent: UCCAPI/4.0.7323.0 MC/14.0.5093.11 (Microsoft Lync for Mac 2011)
ms-client-diagnostics: 34; reason="Call terminated on a mid-call media failure where both endpoints are remote";MediaDebug="Diag:LastError:time out,time:3651253182890;LastRTP Seq:30662,SeqDelta:1,time:3651253152751;LastRTCP time:3651253151390;Last transport receive error:0x0,time:0;Last transport send error:0x0,time:0;"
Content-Length: 0
The capture excerpt shown indicates that Lync is sending data to your Ap Ok but, for whatever reason, is unwilling to accept any data from your Ap (since the advertised window from 172.16.14.58 is 0).
One possibilityfor the RST from your Ap: your Ap has data to send to Lync but can't (since the win = 0) and eventually gives up.
Obviously, this doesn't help much other than to suggest that there's a problem with the Lync end. It's possible that examining a complete capture would provide more information.
For example: was the Ap previously able to send data ? What was the history of the window advertised by Lync ? and so on.
Update:
*Examining the capture you've posted a link to:
It looks quite normal (other than the zero-window stuff at the end).
Starting at about the 91 sec point, the Lync server stops accepting data (win=0), sends some short messages back to your client and then your client sends an RST to the server 30 secs after the server stops accepting data.
So: there's not really any info in the capture which indicates anything much about what's going on with the Lync server.
I do note that just before the win=0 from the server, the windows advertised by the server are smaller than the range advertised previously. (Note: I expect that the actual window size is larger than that seemingly advertised because there's a "window size scale factor" greater than 1 involved. Wireshark doesn't know the scale factor since the original TCP connection establishment handshake is not part of the capture).
I am using SIPP to load test a proxy media server. I am not able to set the IP and port of the proxy media server on the SDP generated by SIPP,
I get the below error,
./sipp -sn uac -d 10000 -l 1000 -i 192.12.24.32 -p 50970 -mi 65.67.8.99 -mp 48321 10.12.24.32:5060 -sf uac_pcap.xml
Unable to bind audio RTP socket (IP=65.67.8.99, port=48322), errno = 99 (Cannot assign requested address).
v=0
o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip]
s=-
t=0 0
c=IN IP[local_ip_type] [media_ip]
m=audio [auto_media_port] RTP/AVP 8
a=rtpmap:8 PCMA/8000
Please help !!!
I'm not an expert in either sdp (sdp probably should be one of your tags, btw) or sipp but the sipp documentation says:
-mi : Set the local media IP address (default: local primary host IP address)
-mp : Set the local RTP echo port number. Default is 6000.
This means that sipp tries to open the port designed by -mp on the local IP designed by -mi.
From what you said I understand the IP:port combination you give in -mi/-mp to be the IP:port combination on the media server, not on the machine running sipp. This means that sipp is trying to open a port on an IP owned by the destination, hence why it "Cannot assign requested address".
The IP:port of the media server should not be part of the SDP generated by sipp. Sipp should describe its end of the media session, then the reply to the INVITE should contain an SDP coming in from 10.12.24.32:5060 with an SDP describing the other end of the media session, including the IP:port of the media server.
Think about it. In a real call you would know the destination SIP address (or sips or...) but you would have no idea of where their media would be. The exchange of SIP message is what establishes that (through an exchange of SDPs), so your sipp SDP should not contain information about a remote media server that it would not know about in a real call.
Try this*:
./sipp -d 10000 -l 1000 -i 192.12.24.32 -p 50970 -mi 192.12.24.32 -mp 48321 10.12.24.32:5060 -sf uac_pcap.xml
*You use both -sn to specify a built in scenario and -sf to specify a scenario file. In other word you are specifying two scenarios, so I removed the built in scenario from the line. Maybe you have good reasons for it to be here that I know nothing about, in which case put it back in.
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.