SBC On Media path
yulian_o
In our days there are a lot of customers that are behind NAT for any
reason.
From customer point of view its almost impossible to know if he is
behind NAT or not
( there are solutions like STUN and ICE but they also have problems ).
Therefore customer will send packets with INTERNAL IP Address ,
actually the only
ip address he knows he has.
When this packet comes to SIP gateway , it can see that packet came
from different
destination that wrote in SIP Headers ( CONTACT , etc ) , therefore it
can inform other
nodes in network by adding received and rport to VIA headers.This way
SIP problem can
be solved.
Together with that customer sends also same local address in SDP data.
When this happens there is no way to know what is the correct ip
address and port
that where opened in firewall to allow the traffic for RTP ( also for
RTCP ) since NAT
can use single IP address , different IP addresses , can try to assign
same port to
packet , can manipulate the port in packet.
Lets imagine the following situation.
Client have internal ip address 10.0.0.15 , and opens 2 ports for
media 2350 and 2351.
Also i uses port 5472 for SIP ( all ports are UDP ).
When the packet is sent it passes through the firewall.
Firewall have 15 ip addresses for NAT 80.80.80.1 to 80.80.80.15.
For SIP it creates translation :
10.0.0.0.15:5472 to 80.80.80.9:3212
For RTP and RTCP it creates
10.0.0.15:2350 to 80.80.80.10:48182
10.0.0.15:2351 to 80.80.80.10:43213
Please pay attention that customer receives from you only VOIP
services , and its not
firewall managed by you.That means that you can not change the way
firewall translates
packets.
For SIP server there is no way if the data wrotten in SDP is correct
or not. The only thing
it knows is that ip address for SIP changed. If SIP server will try to
modify the SDP and set
IP address he knows nothing will be changed since different IP address
is used.Also port
translation is not symmetric so there is no chance it will select
correct ports for RTP and RTCP
Therefore media path will be broken and media server will not be able
to send packets to correct
destination what will lead to one-way-sound problem.
You may try to set STUN or ICE server and work with it.But there are
several disadvantages.
1) Firewall can disallow packet to STUN/ICE server since he did not
received its ip address/port
in 200 OK SDP. It may simply be blocked.
2) It requires client configuration.Now imagine that you have million
of clients , all are behind nat ,
and they are not located in same network all the time ( Going abroad ,
using WIFI , etc ).It will
require from you a huge afford to give all them support.In one network
they will not need settings
at all , in other they will need STUN , in some networks STUN will not
help them.More then that
if customer will have an option to choose application he will use to
connect to VOIP services you
will have to learn your support team all the clients , also part of
them may not have STUN or ICE
support what will lead to problems.
From other point of view there is a way to know what is the IP address
and port.And thats because
client will send you RTP packets by himself ( some clients will send
RTCP also , but some will wait
for server to send RTCP first ).So when first packet will arrive to
media server , it will know EXACTLY
what is the remote address/port , exactly as SIP SERVER does and
therefore will be able to send
the packets to correct destination.More then that no customer
configuration will be needed.
This is the base idea that stands behind the SBC. The goal is to put
Media Server ( Proxy ) in network
entrance , this proxy will wait for packet from client and will set
correct addresses.
Please pay attention that the case i have presented in my example is
REAL. that means that
Israelis mobile companies uses NAT , and because they are not
interested in VOIP calls ( since
then client will make less mobile calls and pay less money ) they are
using assymetric nat ,
SIP IP address may be different from RTP IP Address , RTP and RTCP
ports are not one after another
but are selected randomly.
Therefore i would recommend to implement SBC leg ( or as i call it
PROXY Leg ) in mobicents media.
It will lead to broader market usage for the product.
So what do you think?
Best regards
Yulian Oifa
Ivelin Ivanov
Thank you for the elaborate description of the problem.
Would you mind sharing a diagram (maybe gdocs) that shows the call
flow of the use cases that the MMS Proxy leg will handle.
I think I understand the problems that you are describing, but I don't
quite see how the solution will work. For example it is not clear to
me how the proxy will help in the scenario where the initial SDP
arrives to the SIP app with the intranet IP address and port for the
UA and the SIP app tries to initiate an IVR connection via MMS. It
seems to me that MMS will try to connect to the IP/Port from the SDP,
which would be bad. At some later point of time the UA will send RTP
packets to the server, which will reveal the NAT mapping on the
client's network. The question is how will Mobicents components
interact such that the original problematic SDP IP/Port are replaced
with the public IP/Port on the client's NAT and all this without
transparent to the caller.
Thank you,
Ivelin
yulian_o
Please take a look at : http://www.sipcenter.com/sip.nsf/html/WEBB5YP4SU/$FILE/Data_Connection-SBCinIMS.pdf
This document describes SBC requirements for IMS.
Page 16 shows UNI ( user network interface ).
PCSCF accepts SIP packets ( controls ) and communicates with SPDF
through Diameter Gq'
SPDF is media control ( intermediate ) that communicates through mgcp
with media proxy.
It is required only in IMS network , since SPDF allows to manage
different type of access.
ABGF is media proxy.
In standart SIP network it will be SIP Proxy and Media Proxy only.Also
its not must to
have proxy.media server itself can implement sbc functionality.
Page 7 shows a complete diagramm.
RTP packets will go by following path :
UE - Proxy ( ABGF ) - Media Server ( MRFP ) .....
About the implementation.
I think that point that you are missing is that SDP will
be modified , that means that media server will receive Proxy SDP
and not UE SDP , therefore it will know where to send a packets.
So Proxy - Media Server leg will work as normal ( Packet Relay ) leg
and because they are in same network no NAT will occure.
Proxy will not SET IP address port for remote destination on UE-Proxy
leg
based on SDP.That means that it will open UDP port but will accept ANY
packet that arrives to that port and will not send anything untill
first packet
arrived.
When it receives first packet it will set the correct
IP address and port for remote destination and will send packets in
correct
destination.
Hope this helps.
Best regards
Yulian Oifa
Tom Uijldert
> Therefore i would recommend to implement SBC leg ( or as i call it
> PROXY Leg ) in mobicents media.
> It will lead to broader market usage for the product.
>
> So what do you think?
Brilliant.
I'm not aware of any VoIP operator that doesn't deploy an SBC and paying
good money for it.
"Mobicents-SBC" anyone?
Regards,
Tom Uijldert.
Ivelin Ivanov
Thank you for the pointers, see comments inline:
On Thu, Oct 6, 2011 at 1:17 PM, yulian_o <oifa....@gmail.com> wrote:
> Hello Ivelin
> Please take a look at : http://www.sipcenter.com/sip.nsf/html/WEBB5YP4SU/$FILE/Data_Connection-SBCinIMS.pdf
> This document describes SBC requirements for IMS.
> Page 16 shows UNI ( user network interface ).
> PCSCF accepts SIP packets ( controls ) and communicates with SPDF
> through Diameter Gq'
> SPDF is media control ( intermediate ) that communicates through mgcp
> with media proxy.
> It is required only in IMS network , since SPDF allows to manage
> different type of access.
> ABGF is media proxy.
>
> In standart SIP network it will be SIP Proxy and Media Proxy only.Also
> its not must to
> have proxy.media server itself can implement sbc functionality.
>
> Page 7 shows a complete diagramm.
> RTP packets will go by following path :
> UE - Proxy ( ABGF ) - Media Server ( MRFP ) .....
>
> About the implementation.
> I think that point that you are missing is that SDP will
> be modified ,
What I am also missing is exactly in what point in the interaction and
where exactly will the SDP modification occur. It would help a lot if
you can diagram the complete message flow from the User Phone to SBC
to SIP App Server to Media Server.
Currently there is no SBC component from Mobicents, but there is a SIP
Load Balancer that is recommended in production deployment. I would
like to understand where the proposed Media Proxy fits, both in the
message path and in the architecture. I think you say it fits as a
Media Server component, but the Media Server is not involved in the
call until after the initial SIP INVITE with the original SDP is
received by SIP LB and SIP App Server. I am sure I am missing
something.
> that means that media server will receive Proxy SDP
> and not UE SDP , therefore it will know where to send a packets.
> So Proxy - Media Server leg will work as normal ( Packet Relay ) leg
> and because they are in same network no NAT will occure.
>
> Proxy will not SET IP address port for remote destination on UE-Proxy
> leg
> based on SDP.That means that it will open UDP port but will accept ANY
> packet that arrives to that port and will not send anything untill
> first packet
> arrived.
> When it receives first packet it will set the correct
> IP address and port for remote destination and will send packets in
> correct
> destination.
This makes sense, but I am still missing answers to some of the
details. Please diagram the interaction with an example IVR call and
the components before and after the Media Proxy/SBC is implemented.
Ivelin
yulian_o
Please take a look on diagram one:
http://web-ukraine.com/pathWithProxy.jpg
Now lets move over the packets :
1) UE Sends SIP Invite to incoming SIP Proxy.SDP Data it contains
haves local addresses.
Example :
v=0
o=alice 1234 1234 IN IP4 10.10.2.2
s=
c=IN IP4 10.10.2.2
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
2) Sip Proxy ask from media proxy to create endpoint connection ( it
creates new connection for connection 2 on image ).
3) Media Proxy creates a connection and sends ITS OWN SDP in mgcp
message.
v=0
o=alice 1234 1234 IN IP4 80.80.80.10
s=
c=IN IP4 80.80.80.10
t=0 0
m=audio 5324 RTP/AVP 0
a=rtpmap:0 PCMU/8000
4) Sip proxy modifies SDP and sends a message to SIP Server.SDP taken
is SDP from mgcp.
v=0
o=alice 1234 1234 IN IP4 80.80.80.10
s=
c=IN IP4 80.80.80.10
t=0 0
m=audio 5324 RTP/AVP 0
a=rtpmap:0 PCMU/8000
5) Sip server asks from media server to create endpoint connection
( it creates new connection for connection 2 on image ).
6) Media Server creates a connection and sends ITS OWN SDP in mgcp
message.
v=0
o=alice 1234 1234 IN IP4 80.80.80.15
s=
c=IN IP4 80.80.80.15
t=0 0
m=audio 2348 RTP/AVP 0
a=rtpmap:0 PCMU/8000
7) Sip server modifies SDP and sends a message to SIP Outgoing
Proxy.SDP taken is SDP from mgcp.
v=0
o=alice 1234 1234 IN IP4 80.80.80.15
s=
c=IN IP4 80.80.80.15
t=0 0
m=audio 2348 RTP/AVP 0
a=rtpmap:0 PCMU/8000
8) Sip Outgoing proxy asks from outgoing media proxy to create
endpoint connection ( it creates new connection for connection 2 on
image ).
9) Outgoing media proxy creates a connection and sends ITS OWN SDP in
mgcp message.
v=0
o=alice 1234 1234 IN IP4 80.80.80.11
s=
c=IN IP4 80.80.80.11
t=0 0
m=audio 16778 RTP/AVP 0
a=rtpmap:0 PCMU/8000
10) Sip outgoing proxy modifies SDP and sends a message to UE2.SDP
taken is SDP from mgcp.
v=0
o=alice 1234 1234 IN IP4 80.80.80.11
s=
c=IN IP4 80.80.80.11
t=0 0
m=audio 16778 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Then ringing occures , till UE2 answers the call.
11) UE2 sends 200 OK to outgoing proxy.SDP It has
v=0
o=bob 2332 2333 IN IP4 172.20.0.15
s=
c=IN IP4 172.20.0.15
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
12)Sip Outgoing proxy asks from outgoing media proxy to create
endpoint connection ( it creates new connection for connection 1 on
image using SDP received in SIP Invite).
13) Outgoing media proxy creates a connection and sends ITS OWN SDP in
mgcp message.
v=0
o=bob 2332 2333 IN IP4 80.80.80.11
s=
c=IN IP4 80.80.80.11
t=0 0
m=audio 16780 RTP/AVP 0
a=rtpmap:0 PCMU/8000
14)Sip Outgoing proxy modifies SDP and sends 200 OK to SIP Server.SDP
taken is SDP from mgcp.
v=0
o=bob 2332 2333 IN IP4 80.80.80.11
s=
c=IN IP4 80.80.80.11
t=0 0
m=audio 16780 RTP/AVP 0
a=rtpmap:0 PCMU/8000
15)Sip Server asks from media server to create endpoint connection
( it creates new connection for connection 1 on image using SDP
received in SIP Invite).
16) media server creates a connection and sends ITS OWN SDP in mgcp
message.
v=0
o=bob 2332 2333 IN IP4 80.80.80.15
s=
c=IN IP4 80.80.80.15
t=0 0
m=audio 2350 RTP/AVP 0
a=rtpmap:0 PCMU/8000
17)Sip Server modifies SDP and sends 200 OK to Sip Incoming Proxy.SDP
taken is SDP from mgcp.
v=0
o=bob 2332 2333 IN IP4 80.80.80.15
s=
c=IN IP4 80.80.80.15
t=0 0
m=audio 2350 RTP/AVP 0
a=rtpmap:0 PCMU/8000
18)Incoming Sip Proxy asks from incoming media proxy to create
endpoint connection ( it creates new connection for connection 1 on
image using SDP received in SIP Invite).
19) incoming media proxy creates a connection and sends ITS OWN SDP in
mgcp message.
v=0
o=bob 2332 2333 IN IP4 80.80.80.15
s=
c=IN IP4 80.80.80.15
t=0 0
m=audio 2350 RTP/AVP 0
a=rtpmap:0 PCMU/8000
20)Incoming Sip Proxy modifies SDP and sends 200 OK to UE1.SDP taken
is SDP from mgcp.
v=0
o=bob 2332 2333 IN IP4 80.80.80.10
s=
c=IN IP4 80.80.80.10
t=0 0
m=audio 5326 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Therefore UE1 knows only 80.80.80.10 ( Incoming Media Proxy ) , UE2
knows only 80.80.80.11 ( Outgoing media proxy )
and Media Server knows both 80.80.80.10 and 80.80.80.11 ( Incoming
media proxy and outgoing media proxy , which
by the way can be same server ).
SBC should be implemented on Incoming Media Proxy Leg 1 ( that comes
to UE1 ) , and on Outgoing Media Proxy Leg 2 (
that comes to UE2 ).
Media Server works as usually , because he contacts only servers in
local network.
UE1 and 2 does not knows what is the ip address of serving media
server , so topology hiding also takes place on media
path.Since each media nodes sends its own SDP data , SDP changes
occures on each node.
There are other ways of operation ( for example creating both
connections for endpoint immediately when SIP invite
received , from one point it allows codec negotiation in more early
stages , but from other will cause a timeout
problem since in HALF_OPEN state connection can be kept only for 5
seconds ( as defined by Oleg ).
Similar SDP manipulation can be made without SIP and Media Proxy , by
using a single node , see
http://web-ukraine.com/pathWithoutProxy.jpg
In this way , SDP will be changed only once , and no topology hiding
will have place.
Best regards
Yulian Oifa
yulian_o
By using diagram 2 NO CHANGES are required.
UE1 sends SIP Invite to SIP Server.
SIP Server request to create endpoint on media server.
Media server answers with its own SDP.
SIP Server sends 200 OK to UE1.
On this stage UE1 sends ACK , and starts sending RTP.
First RTP packet received by Media Server , it changes
the IP address of remote destination and starts sending packets
to destination.
Best regards
Yulian Oifa
Ivelin Ivanov
The picture is much more clear now.
I think we need to implement the Proxy Leg functionality in MMS as you suggest.
The 20 step process seems to be bullet proof, but it adds overhead on
the network and complicates the sip app logic. For the latter maybe we
can provide some kind of container configuration or helper libraries
to reduce boiler plate code.
For your other diagram with symmetric RTP support for both UE and
Media Servers, the magic is transparent to the SIP app. However it
will not work if the RTP packets from the UE travel between multiple
hops (as in some IMS architectures) before they arrive at the Media
Server. In such scenarios, the IP address of the RTP packet may not be
the public IP address of the UE NAT.
I am having a chat with Sergio Garcia, founder of the MCU project and
member of the GSMA RCS committee. Segio supports your analysis and is
helping me understand the various alternatives. I will forward our
chat transcript in a few minutes.
Ivelin
Ivelin Ivanov
A question related to your statement below:
> Please pay attention that the case i have presented in my example is
REAL. that means that
Israelis mobile companies uses NAT , and because they are not
interested in VOIP calls ( since
then client will make less mobile calls and pay less money ) they are
using assymetric nat ,
SIP IP address may be different from RTP IP Address , RTP and RTCP
ports are not one after another
but are selected randomly.
How would the SIP App on the server know which RTP packet is related
to which SIP Dialog if the RTP IP address is different than the SIP
INVITE IP address?
Ivelin
Ivelin Ivanov
waiting for RTP packets from the UE that sent the INVITE.
Ivelin Ivanov
several sequence diagrams that helped understand the various NAT
cases.
This is the one that shows the most complicated case with "unfriendly"
telco nat that splits the IPs for SIP and RTP:
http://www.image-share.com/ipng-981-205.html
Amazingly it appears that all the complexity can be handled with an
intelligent SBC, such that the NAT issues are transparent to the SIP
app.
So far the following requirements seem to make sense for an SBC:
- SIP Load Balancing
- SIP Proxy
- Media Proxy
- STUN/ICE Server
Modules for future consideration:
- Denial of Service Defense
- Fraud Detection and Prevention Service
Looking forward to additional community feedback.
Ivelin
---------- Forwarded message ----------
From: Sergio Garcia Murillo <sergio.gar...@gmail.com>
Date: Fri, Oct 7, 2011 at 3:04 PM
Subject: Chat with Sergio Garcia Murillo
To: ivelin.atan...@gmail.com
11:54 AM
me: Hi Sergio
Sergio: hi ivelin
me: did you see the SBC on Media Path topic on mobicents-public?
Sergio: I seen that there was a huge post .. :)
i think it was really interesting
11:55 AM
so I was going to take a good look at it
me: I am trying to understand. It seems to make sense now.
But I just remembered Vladimir telling me
that he had a similar discussion with you recenly
Sergio: yes
me: and you pointed out an RFC that addresses NATs
11:56 AM
can you please take a look at the topic and let me know if the RFC is applicable
Sergio: I will check
me: thank you
I wouldn't want us to reinvent the wheel
12:00 PM
Sergio: i see the explanation of the problem correct
but don't really understand what he is propossing
12:02 PM
basically there are two ways of managing NAT in SIP/IMS scenarios
the first one is to put an SBC in your access border
12:04 PM
so it mangles de SDP, and puts a media proxy in the middler of th call
(as kamailio does with the media proxy)
12:05 PM
this usually applies to IMS enviroments, were you deploy serveral AS
behind the SBC and problably in a private network
if you are in a stand-alone deployment (that's everything inside a
mobicent server)
12:06 PM
then you just need to implement simetric media
and send the media to the originating IP addres of the message instead
of the one declared in the SDP
(as we did in the test server)
12:07 PM
me: got it
what is the RFC for these cases?
Sergio: http://tools.ietf.org/html/rfc4961
12:08 PM
but the second case won't work in a IMS network, as probably the IMS
INVITE will get throught several nodes (P-SCF,S-SCF,etc) before geting
to the AS
12:09 PM
me: do you mean that if the invite passes via several nodes
12:10 PM
so will the first rtp from the UE to the media server
and the RTP packet that the media server sees will not have the public
IP of the UE NAT?
12:11 PM
Sergio: i mean if the INVITE passess throught many nodes.. and you
just use the remote IP address, the mcu will send the media to the
latest node instead of the SBC one
12:12 PM
so the behaviour should be different if the media server is on the
border or inside it..
me: ok, so the media server using the IP from the RTP packet is not
always a workaround
Sergio: depends on the deployment
12:13 PM
the best way would be to have an external component that handles first
the INVITE and does the correct thing
me: the sip app needs to specifically ask the media server to respond
to the RTP IP instead of the SDP IP
Sergio: so the media application do not worry about where to send the
media.. just uses the IP in the SDP
12:14 PM
me: you mean, the best way os the long road that Yulian describes? 20 steps.
Sergio: I have not been able to fully read it.. :)
check also this one
12:15 PM
http://mediaproxy.ag-projects.com/
12:17 PM
me: the 20 steps solution is to use SBC
12:18 PM
with inbound/outbound proxies for SIP and RTP
Sergio: yes.. that's the full flavor
and it is correct
the only thing is that not all the deployments would need so much logic
me: and the SIP Application knowing about the SIP/Media proxies and
working with them to build the bridges from UE1 - inproxy - app/media
server -outproxy - UE2
12:19 PM
yes, it seems pretty complex and error prone
Sergio: for me that should be transparent to the sipp app
me: we can probably write a few helper libraries to simplify the
boiler plate code
Sergio: i mean, the sbc/mediaproxy should be configured and handles
everything internally
me: yes, ideally the sip app wouldn't care
Sergio: so when it gets to the sipp app the sbc is modified
12:20 PM
me: maybe a configuration parameter
because in some cases it would be unnecessary overhead
Sergio: or like a different load balancer
yes
and in some cases the only thing that would be needed is to override
the IP in the SDP with the received IP address of the SIP message
12:21 PM
and use symetric media
(like in the case of the test server)
me: the RFC you sent me only talks about symmetric RTP/RTCP, which is
required on the UE side. But it does't talk about the SBC on the
server
Sergio: it is not needed
i mean
if the media server also does symettric media the nat problem is solved
12:22 PM
let's try to explain what happened to the mcu in the test server
12:23 PM
the sip softphone is inside a nat, so when it sends the SDP, it sets
the internal IP in it
12:24 PM
the SDP is received by the mobicent server, which is in a public ip
address (or in a private address but with port forwarding)
if it sends the media to the IP in the SDP it will fail
but if it sends the media to the IP of the received addres (the public
ip of the nat) it will work
12:25 PM
I will make a quick drawing
12:26 PM
me: I think I am following, but a drawing would be great.
I would like to forward our chat transcript to the forum topic if you don't mind
Sergio: no prob.. :)
but this topics are better explained with a drawboard.. :)
12:30 PM
me: absolutely
that's why I asked Yulian to draw diagrams after several attempts to
understand his text
12:32 PM
Sergio: :)
22 minutes
12:54 PM
Sergio: I will upload the image to a img share
12:55 PM
http://www.image-share.com/ipng-981-155.html
this is how the test server works with nat
12:58 PM
me: In the Mobicents Server box
can you please annotate which specific Mobicents component does what
SIP AS, Media Server, MCU?
Sergio: ok
12:59 PM
if you want I could put them in different ips
to make everything more complicated.. ;)
wel.. let's put it everything in the same box
1:00 PM
so people does nor get confused
me: just show it exactly how it is in the test server
1:01 PM
Sergio: rigth now or how it should be?
1:05 PM
here it is
http://www.image-share.com/ipng-981-162.html
1:09 PM
me: perfect. Thank you. I will share with the community now.
1:10 PM
Sergio: I am sending you a new drawing about how it would be with an
SBC instead of a firewall (without media proxy)
me: When you have some time, please chime in how we should go about
implementing the 20 step process in a way that is transparent to the
sip app.
ok, great
it would complement nicely Yulian's step by step text
1:11 PM
Sergio: I willl do it in the next drawing.. :)
1:12 PM
this is the case with a simple SBC
http://www.image-share.com/ipng-981-163.html
without media proxy
1:15 PM
me: in this diagram it is not clear how the SBC knows which MCU IP and
port to forward to RTPs from the UE
1:20 PM
Sergio: if you only have one media server you could do static port forwarding
i.e send all rtp ports to the mcu
would not work in most cases thought
1:22 PM
check this one for the full flavor
http://www.image-share.com/ipng-981-166.html
1:25 PM
me: hm, it seems like in this setup the SBC is transparent to the sip app
is that the case?
Sergio: in this case yes
1:28 PM
that last case is the typicall in IMS scenarios
me: hm, I must be missing something
1:29 PM
in Yulian's 20 steps, the app has to be quite involved in the
interaction with the proxies
Sergio: I beleive he put the media server in the middle of two enpoints
me: yes
1:30 PM
if you had to extend your last diagram to cover his call scenario
wouldn't it be still transparent to the sip app
1:31 PM
as long as the sbc knows to automatically modify outbound SDP the way
it does for inbound?
Sergio: yes
1:32 PM
me: 192.* <-> 80.*
Sergio: Let me do it
i have the visio opened and would be easy
well.. in fact it is yust duplicating everithing
me: ok, I'm still scratching my head. In what case would the app need
to know about the SBC and interact with the Media Proxy.
1:33 PM
Sergio: if the SBC does everything, then there is no need to
me: ok, please do it so its clear beyond any doubt.
Sergio: let me also check again which is his use case to not miss anythin
1:34 PM
me: Thomas Quintana (Restcomm lead) is just telling me that the Media
Proxy smart should probably coexist in an SBC with the SIP Load
Balancer
1:37 PM
it can also have the extra intelligence of skipping translation and
not being in the media path when the UEs have IPv6 or public IPv4
addresses
Oh, I just noticed something in Yulian's messages
the UE NAT may intentionally split the Public IP of the SIP and RTP packets
1:38 PM
which is why he suggests that the Media Proxy waits for a first RTP
packet from the UE
assuming the public SIP IP for the RTP won't always work
1:39 PM
Sergio: umm.. i won't do that
i mean i wouldn't do that
1:40 PM
first, which crazy UE will be behind a nat with two IPs on the first case
1:41 PM
well, in the case for example of a SOHO with two adsl and a firewall
doing load balancing
but if the use has that complex network connectivity, i expect him to
solve the nat correctly and put in place a NAT aware router
1:42 PM
me: I think he said its realistic in cases when the ISP is the telecom
Sergio: second, i would only recomend to listen for packets from the
originating IP in order to avoid any security issue
me: he was talking about Israel
telcos intentionally splitting the IPs to make VoIP calls more difficult
1:43 PM
Sergio: well.. that woudl be the only case i can think about
me: but then if the RTP comes from a different IP, how can you tell
which SIP dialog its related to?
1:44 PM
Sergio: by the port in which it is received
but it is a blind match
you could have men in the middle attacks that way
as you are not checking the sender IP to match the one in SIP
1:45 PM
but in any case, whatever the SBC does should be transparent to the SIP app
1:47 PM
me: I asked the question on the forum
1:48 PM
not sure how the corelation can be made between rtp and sip, if they
are from different IP addreses
Sergio: but I beleive that having a load balancer+sbc+media proxy is a
very powerfull product
me: he says the ports are selected randomly
Sergio: acme packet only do that and is performing quite well.. ;)
me: yes, I am starting to appreciate the power.
1:49 PM
Sergio: yes, you can make the port random..
me: what's the solution to that without ICE/STUN?
Sergio: but I could send RTP packets randomly to the udp ports and you
will suffer a dos attack
1:50 PM
the ICE/STUN is for the UE
so it includes the public IP on the SDP and openes the nat
I am not really aware of how it works
1:51 PM
but the solution I put was wihout ICE/STUN
just symmetric media
(i.e. you send and receive the packets in the same udp port)
1:53 PM
me: yes, I understand your solution
and I like it how its transparent to the sip app
1:54 PM
its perfect for IVR and conferencing apps
Sergio: yes
me: when the server has to stream media
Sergio: in fact I need that for the jsr 309 implementation
me: for peer to peer calls it may be overkill
Sergio: because I have no access to the remote ip addr
1:55 PM
but for peer to peer, if both ends are behind nat is the only way to do that
use an external entity to rely media
(as the picture I sent you about the kamailo media proxy)
5 minutes
2:00 PM
Sergio: by the way
i have a question regarding the jsr 309
me: yes, or the other case is for UEs to know ICE/STUN
2:01 PM
Sergio: yep, that's right
me: if the SBC offers ICE/STUN it can relieve a lot of the work for
passing media through in p2p calls
ICE/STUN just use the SBC to help the UEs discover their public IP/ports
2:02 PM
Sergio: yes
me: the requirements for the SBC are growing...so is the value of
having one that actually works :)
Sergio: the good solution is that the SBC is smart
me: the one remaining issue is Yulian's case where the UEs don't know
ICE/STUN and their NAT splits the IPs for SIP and RTP
Sergio: and only route the media through the media proxy if both are
behind a bad nat..
2:03 PM
i beleive that the SIP negotiation is the same
2:04 PM
the only thing is that the media proxy cannot send the IP to the
public IP address of the SIP INVITE
but needs to wait until the first rtp packet is received in the port,
to get the remote IP address
2:07 PM
me: yes, exactly. But even when that happens
how does the media server know...
oh wait
I'm so dumb
forgot that the media server port was open specifically for the SIP INVITE
so the packet will come from the UE that sent the SIP INVITE
2:08 PM
Yulian thought it through!
2:11 PM
Sergio: exactly
2:12 PM
me: do you see a way that this can be done without the sip app involvement?
2:13 PM
Sergio: which step number?
2:14 PM
me: the part where the UE needs to be told to send RTP packet to an
external IP/port on the SBC
I guess your diagram still works
2:15 PM
Sergio: yes, it will work
no need for the sipp app to do anything
the sbc should do that internally
me: the SBC just needs to have a little patience
Sergio: is just a matter of where to send the outgoing packet to
yes
me: and not assume the SIP IP is the RTP IP right away
Sergio: exactly
2:16 PM
anyway, the nat won't be opened until the UE sends an rtp packet
me: Awesome! Can you please create a new diagram that extends the
previous for this case?
that's right
Sergio: the only issue is that perhaps it is good for the sipp app
when the rtp data has arrived
2:17 PM
so no packets are lost
2:18 PM
it may be very problematic for video, because for example, if in h264
the sps/pps packets are lost (the first two ones), there willbe no
video at all until next iframe
2:19 PM
me: how would they get lost with SBC?
2:20 PM
Sergio: umm.. there can be two approaches for the media proxy, either
drop any packets received by the media server before it receives the
first packet from the UE
or it drops them
both approaches are dangerous
6 minutes
2:27 PM
me: so for video the SBC might need to buffer RTP packets from the server?
2:28 PM
Sergio: that's something I have yet to figure what is the best way to do it
2:29 PM
probably this diagramsn will help me to understand it better
me: Yes, that is what I would suggest
2:30 PM
lets diagram the cases we discussed so far and continue after you had
a chance to think more
2:31 PM
Sergio: umm.. i have a question about the strange case
which port would the SBC send to
2:32 PM
me: don't understand the issue
2:33 PM
Sergio: I am sending you the diagram
2:34 PM
for example
http://www.image-share.com/ipng-981-200.html
2:38 PM
me: nice
can you please modify the bad telco nat area
2:39 PM
and use concrete examples
e.g. 201 for IP
its a bit confusing with X, Y
2:41 PM
Sergio: the nat will change the originating port
2:44 PM
me: right, can you please make it clear what happens
Sergio: http://www.image-share.com/ipng-981-204.html
2:45 PM
I added how I beleive it should work
2:46 PM
I think that the SBC should not send the ACK to the sip app until it
receives the first packet
i am not really sure if this case will never work with the bad telco
in the middle
2:47 PM
me: Yuilan thinks it will. What is your concern?
Sergio: the destination port
2:48 PM
well.. yes.. it may work..
2:49 PM
me: yes, it seems doable. I can't come up with other issues right now.
2:50 PM
Sergio: http://www.image-share.com/ipng-981-205.html
the only thing is that the bad telco nat, has to be a bit nice
2:52 PM
me: You are suggesting that the ACK arrives after the UE sends an RTP
to avoid the media server sending RTP first?
2:56 PM
Sergio: yes
that the SBC waits for the first video rtp to send the ack
2:57 PM
me: now I wonder what will happen in case of early media
like Trying tones
maybe not something to worry about too much
2:58 PM
Sergio: probably in that cas we are f#cked
or if the video is muted
2:59 PM
me: :)
let's pause for now
Sergio: yep
Henrique Cunha
It's a good start learning from their experience.
Signaling and media splitting is very common today.
Tks
Henrique
yulian_o
You are completely right that media path may be completely independent
from sip path ( control path ) and
sip applications should not know anything about whats going on on
media path ( except sending and receiving data
from mgcp or any other protocol that is used to control media server).
Several comments to your last post
1)STUN/ICE requires client settings and can be blocked also they have
nothing to do with SBC , since if you
have STUN configured on client , client can know what is his external
ip address/port therefore it always
sends correct sdp data to media server.So its either STUN/ICE ( client
side based ) or SBC ( server side )
2) About SIP : as i wrote SIP RA already have capabilities to handle
NAT issues, it does not requires any
addional development on stack layer , only correct header changes on
application.So basically mobicents SIP RA is
NAT friendly.
3) Please pay attention that its not required to put Media Proxy
before Media Server.Media server can have 2 functions
in one.If you will take a last code submitted on issue 2605 and
configure any media example as follows
1) in configuration for media server set correct local network address
in proxy.cnf
2) Change mgcp commands to use /proxy leg instead of packet relay or
whatever is used there.
Any network you will have will be correctly handled by media
server( NAT , PAT , Assymetric PAT , etc )
See
http://code.google.com/p/mobicents/issues/detail?id=2605&can=1&q=Proxy%20Leg&colspec=ID%20Priority%20Component%20Milestone%20MSPS%20SLEE%20SubComponent%20Version%20Release%20Type%20Status%20Owner%20Summary
to get a code.Please check the netstat periodically and you will see
that ports are first opened for any and when packet are
received they changed their remote address listening to correct
address. the only problem is that this solution is
based on 2.1.0 Beta 1 , that is old version.
You are right about the DOS and Fraud detection as those are features
that naturally feats on SBC. But start without them
is still good start.
Best regards
Yulian Oifa
Ivelin Ivanov
and Kamalio.
Agree that we can learn from rtpproxy.
Ivelin Ivanov
1. I understand that STUN/ICE are not always an option, but when they
are they can save the overhead of passing media through the SBC.
Especially in the case of peer to peer calls. Also, when clients
support STUN/ICE, they still need a STUN/ICE server to help them find
out their public NAT IP/port. Which is why I suggested that the
Mobicents SBC maybe includes STUN/ICE server as a feature. Do I make
any sense?
2. What does it mean that the SIP RA is NAT friendly? Do you mean that
the SIP RA allows SDP modifications to be made by the app? If the
application makes all SDP modifications then it is intrinsically aware
of the NAT workarounds. According to Sergio and Thomas, the SBC should
do the SDP modification magic such that the SIP app does not to behave
any differently whether the UEs are behind NAT or not. Do you agree or
disagree?
3. I reopened issue 2605 and added a comment. It seems to me that you
are suggesting that with your patch, the sip application developer
doesn't have to know anything about the NAT issues. All that needs to
be done is configure the media server. However I can't find proxy.cnf
in the RAR file you attached. Maybe Vladimir or Oleg can comment
further, because they are a lot more familiar with the Media Server
inner workings than I am. Its hard for me to figure out your changes
from the many files in the RAR.
Can you confirm that with your proposed patch to the media server, any
sip app code that uses JSR 309 RA or the MGCP RA will NOT have to
change at all in order to support SIP phones behind NAT?
Returning back to the standalone SBC discussion, do you agree that the
diagram suggested by Sergio will work? Since NAT translation is
required for both SIP and RTP, it does seem logical that all that code
should be in a component outside the SIP app server and outside the
Media Server.
Are you familiar with the current Mobicents SIP Load Balancer project?
Can you see how that can be extended with the SBC features we are
discussing on this thread?
Ivelin
yulian_o
1) If you implement STUN/ICE you dont need SBC on your path, since
you know you will receive correct addresses in SIP packets.
2)That means that if you create Announcement example it will work
without
any changes , since you will send 200 OK to client based on initial
SIP Invite
which in turn have received and rport set in VIA header if NAT is on
the way.
3)its located in deploy/endpoints/proxy-beans.cnf ( sorry for name )
4) With several limitations :
--- You will have to set different endpoint name
--- This endpoint is currently based on packet-relay , therefore
conference is
not supported yet. Thats because in SBC all legs are one-to-one.Same
support can
be added to conference without much code changes.
5) Yes , it will work similar way.
6) Please pay attention that media SBC is application independent ,
while SIP SBC
is application dependent.So if you want to implement complete solution
you will have
to make several implementation :
----- SIP Proxy + Media SBC ( for regular sip network )
----- PCSCF + SPDF + Media SBC ( for IMS network )
There may be other sip implementations that will require specific
implementation.
Media SBC will always be a same.
7) Since SIP SBC is application specific , there is not much you can
do on stack level.
Therefore i dont see much that can be done on SIP Load Balancer. If it
works in similar way
to regular sip stack ( that means that it sets received and rport when
there is nat , by comparing
UDP/IP header and SIP header ) its maximum you can do there.
Best regards
Yulian Oifa
Ivelin Ivanov
better understand his perspective.
Attached diffs to what I thought were the most essential changes he proposes:
http://code.google.com/p/mobicents/issues/detail?id=2605#c5
SBC as a logical component on the network is meaningful, but there is
no hard rule that all SBC related features have to be colocated in one
standalone server.
As Yulian points out, in the case of media connection from a client
behind an unfriendly NAT, the earliest when the public IP/port of the
client can be determined is when the client sends an RTP packet to the
server.
Given that the solution to this case is just a few lines of code added
to MMS, it seems to make the most practical sense.
One can even make the argument that the ProxyRtpConnection should be
the default connection type, because it offers more convenience to the
app developer. With a few configuration parameters, it can act as
regular RtpConnection when the SDP offers IP from a local network or
public range and respectively implement late binding otherwise.
Thoughts? Are there cases when the proposal won't work?
Ivelin
Thomas Quintana
- Media traffic will eventually impact signaling latency unless there is hardware support (which we won't have in a cloud environment).
- Scaling and Failover become difficult to deal with.
Thomas
Jean Deruelle
Oleg Kulikov
v=0
o=- 3 2 IN IP4 192.168.1.102
s=CounterPath eyeBeam 1.5
c=IN IP4 192.168.1.102
t=0 0
m=audio 42566 RTP/AVP 18 101
a=x-rtp-session-id:593E50B33BABBDC4935DCF244795482A
a=fmtp:18 annexb=yes
a=fmtp:101 0-15
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=alt:1 3 : hziPI5Cc 7WcQVDM2 80.68.1.102 42566
a=alt:2 2 : EhKFe60O XlYxYefC 172.16.32.1 42566
a=alt:3 1 : YzH9jDfx LJqo6/5p 192.168.106.1 42566
a=sendrecv
The another known way to specify alternative sources.
v=0That's not it yet even. Address can be underspecified, say 0.0.0.0 or 80.69.146.0....
o=Laura 289083124 289083124 IN IP4 one.example.com
t=0 0
c=IN IP4 192.0.0.1
a=group:ALT 1 2
m=audio 20000 RTP/AVP 0
a=mid:1
m=audio 30000 RTP/AVP 0
a=mid:2
Application makes decision either specify exact address, provide alternatives or underspecify address totaly. What else needed?
Oleg
PS.
It seems to me that SBC is another story. Let's try to keep cuttlets separated from flys.
Tom Uijldert
> From: mobicent...@googlegroups.com [mailto:mobicents-
> pub...@googlegroups.com] On Behalf Of Oleg Kulikov
[snip]
> That's not it yet even. Address can be underspecified, say 0.0.0.0 or
> 80.69.146.0....
>
> Application makes decision either specify exact address, provide
> alternatives or underspecify address totaly. What else needed?
Although my name is Thomas, I do not doubt your knowledge here :)
But where in the specs can I find this?
Thanks in advance,
Tom Uijldert.
Sergio Garcia Murillo
If it is implemented only inside Mombicents Media Server, how would it
be re-used by another media server/jsr309 implementation?
Best regards
Sergio
On Oct 10, 10:27 am, Oleg Kulikov <oleg.kulik...@gmail.com> wrote:
> Once again, SDP spec defines attribute called alternative (alt). This
> attribute can contains the alternative source of media content. Let's
> consider the use cases for it.
>
> v=0
> o=- 3 2 IN IP4 192.168.1.102
> s=CounterPath eyeBeam 1.5
> c=IN IP4 192.168.1.102
> t=0 0
> m=audio 42566 RTP/AVP 18 101
> a=x-rtp-session-id:593E50B33BABBDC4935DCF244795482A
> a=fmtp:18 annexb=yes
> a=fmtp:101 0-15
> a=rtpmap:18 G729/8000
> a=rtpmap:101 telephone-event/8000
>
> The another known way to specify alternative sources.
>
> v=0
> o=Laura 289083124 289083124 IN IP4 one.example.com
> t=0 0
> c=IN IP4 192.0.0.1
> a=group:ALT 1 2
> m=audio 20000 RTP/AVP 0
> a=mid:1
> m=audio 30000 RTP/AVP 0
> a=mid:2
>
> That's not it yet even. Address can be underspecified, say 0.0.0.0 or
> 80.69.146.0....
>
> Application makes decision either specify exact address, provide
> alternatives or underspecify address totaly. What else needed?
>
> Oleg
>
> PS.
> It seems to me that SBC is another story. Let's try to keep cuttlets
> separated from flys.
>
Thomas Quintana
First for all of those who aren't aware of the alt attribute it is documented in RFC4796.
alt: the media stream is taken from the alternative source. A
typical use case for this is an event where the ambient sound is
separated from the main sound. The alternative audio stream could
be, for example, the sound of a jungle. Another example is the
video of a conference room, while the main stream carries the
video of the speaker. This is similar to the 'live' role in
H.239.Second, I would like to state that even though Oleg's solution makes sense it seems to me
that adding the alternative source for the media stream is something that the user agent
would be responsible for and that is assuming the user agent even supports RFC4796.
Finally, to Oleg's point there definitely is always a big debate on the need to add an SBC (and extra hop)
to the signaling and media paths. My take is that it really depends on network topology and
the requirements that the network will fulfill but I certainly wouldn't scratch it out of my tool box.
My 2 cents,
Thomas
yulian_o
2 Oleg :
attribute can contains the alternative source of media content. Let's
consider the use cases for it.
neither
alternative source nor multiple sources/destinations for single
connection).
That means that code has to be changed anyway if you want to give a
fight for
NAT problems.We are not talking generally about all media servers that
exists on market,but
about specific product.Currently it does not have any support for nat
issues.
2)If you dont want additional node on the path , thats all right , use
different
endpoint on media server and you are done.Please pay attention that
SBC implementation
does not break current media server implementation in any way.If you
dont take into account
security issues you can make simple changes : instead of binding udp
to specific remote destination
open it to any , when you receive packet - accept it , when you want
to send packet send it
to address you know. This way works some switches i know.
to Ivelin : please pay attention that my solution is based on 2.1.0
Beta 1
so it have to be rewriten for new version of product.
Best regards
Yulian Oifa
Oleg Kulikov
The my point is that for such kind of problems (may be useful on practice) no need in implementation of any kind proxy legs. Everything can described in terms of SDP. Why invent the new wheel?
You are absolutely right that media server works with exact address only since this problem has never high priority for us. This is work for two hours and who need will do it or we can include into roadmap upon user request. This problem does not cost long debates.
Going forward, I would note that the implementation of SBC on top of media server possible however not effective. Handling packets at IO level is much much much more efficient.
Oleg
yulian_o
Lets take a look once again.
1) Client side - Client does not have any idea about whats going on on
his way to server.It can use stun or ice , buts not always it have
support for that ( or because of application implementation or because
those services are simply blocked on the way for any reason )
2) Server side SIP - it gets only SDP , and possibly a knowledge that
NAT is on the way.This knowledge is not enough to know the real RTP
and RTCP addresses.
3) Server side Media - it gets only SDP , if its not correct it will
send data to incorrect location.
So practically SBC does resolves NAT issues ( it does also other jobs
for example security , etc , but nat traversal is part of its
features )
More then that connect client behind NAT without STUN or ICE support
to any mobicents media server implentation and see what happens.Client
will not receive any data.
After that use proxy leg ( its just a name by the way ) and magic ,
you get a sound.
So it does helps.May be its not well implemented , but it works.
Also let me point to what you wrote "Handling packets at IO level is
server changes are required to make things happen.I did not
implemented some new feature but modified IO files.The only reason i
did it with
new endpoint is because i did not wanted to make changes to existing
ones.
Best regards
Yulian Oifa
Ivelin Ivanov
1. Thanks to Thomas Q for pointing to the RFC for alt. Being an
alternative (or additional) source of sound is not what Yulian is
suggesting to solve.
2. Thanks to Sergio for pointing out that if we implement the Media
Proxy feature in MMS it may not benefit MCU. I am not sure what's the
best way to address this point yet.
3. It is quite clear that Yulian's patch is solving a real problem and
its worthwhile implementing. Its only a few lines of code and it
magically enables communication with a range of SIP Clients without
extra configuration on the client side.
4. A design question is where does the logic fit best. Does it apply
to any end point that receives rtp packets from external sources. If
so, what is the optimal way to implement it? Yulian's patch copies
most of the existing code and adds the extra logic for lazy remote
address binding. Should we just replace the existing classes with the
new ones and make the proxy a feature that can be enabled/disabled
when the rtpconnection is initialized?
Oleg Kulikov
Great discussion. I am learning a ton.
1. Thanks to Thomas Q for pointing to the RFC for alt. Being an
alternative (or additional) source of sound is not what Yulian is
suggesting to solve.
2. Thanks to Sergio for pointing out that if we implement the Media
Proxy feature in MMS it may not benefit MCU. I am not sure what's the
best way to address this point yet.
3. It is quite clear that Yulian's patch is solving a real problem and
its worthwhile implementing.
Its only a few lines of code and it
magically enables communication with a range of SIP Clients without
extra configuration on the client side.
4. A design question is where does the logic fit best.
Does it apply
to any end point that receives rtp packets from external sources. If
so, what is the optimal way to implement it? Yulian's patch copies
most of the existing code and adds the extra logic for lazy remote
address binding.
Should we just replace the existing classes with the
new ones and make the proxy a feature that can be enabled/disabled
when the rtpconnection is initialized?
Oleg Kulikov
Hello Oleg
Lets take a look once again.
1) Client side - Client does not have any idea about whats going on on
his way to server.It can use stun or ice , buts not always it have
support for that ( or because of application implementation or because
those services are simply blocked on the way for any reason )
2) Server side SIP - it gets only SDP , and possibly a knowledge that
NAT is on the way.This knowledge is not enough to know the real RTP
and RTCP addresses.
3) Server side Media - it gets only SDP , if its not correct it will
send data to incorrect location.
So practically SBC does resolves NAT issues ( it does also other jobs
for example security , etc , but nat traversal is part of its
features )
More then that connect client behind NAT without STUN or ICE support
to any mobicents media server implentation and see what happens.Client
will not receive any data.
After that use proxy leg ( its just a name by the way ) and magic ,
you get a sound.
So it does helps.May be its not well implemented , but it works.
Also let me point to what you wrote "Handling packets at IO level is
much much much more efficient"Its completely true.and RTP IO is part of media server.Therefore media
server changes are required to make things happen.I did not
implemented some new feature but modified IO files.The only reason i
did it with
new endpoint is because i did not wanted to make changes to existing
ones.
Best regards
Yulian Oifa
Laurent Schweizer
Hello all,
we are a small provider and we have same problem , 95% of our customer are behind a NAT and they have no idea of what is a NAT.
As we need to relay all voice channel ( firewall issue with part of our provider) we cannot use STUN and not so many device implement TURN so we are not using them.
So we use openser with RTPproxy in front of mobicents to solve all NAT issue, this solution work correctly with early media, Re-INVITE if you need to change codec, go to T38 and also if you need to change rtp port or connection IP.
by default, RTPproxy wait to get some packet to a defined port to configure it without checking the source IP , this was creating an issue for us as we can get an unexpected packet at start of the session and the port will be not correctly configured (it's also a security issue).
To solve this , we change the RTPproxy to only allow source of packet from a defined IP and we configure openser to send the correct source IP to the rtpproxy.
If openser detect that the connection IP in the SDP is a private IP then he will forward the source IP of the SIP packet, if the connection IP in the SDP is a public IP, he will send this public IP to the rtpproxy.
Regards
Laurent
De : Oleg Kulikov [mailto:oleg.k...@gmail.com]
Envoyé : jeudi 13 octobre 2011 09:06
À : mobicent...@googlegroups.com
Objet : Re: [mobicents-public] Re: SBC On Media path
Ivelin Ivanov
Thank you for sharing your experience with the NAT problem.
If I am not mistaken in your case, all client phones that are behind a
NAT use the same public IP for SIP and RTP packets.
In Yulian's case, an unfriednly NAT, uses different IPs for SIP and
RTP packets.
Your solution would inform RTPProxy of the SIP IP address to limit
exposure to noisy RTP packets, but it will not work, because RTP
packets bound for the client phone will go to the public NAT SIP IP,
which is not the same as the public NAT RTP IP.
Yulian, would it be a viable solution if the RTPProxy is allowed to
listen to the IP of the SIP packet and a small range of IPs around it?
Maybe a configurable mask can be applied towards the SIP IP address to
control the allowed range.
Ivelin
Oleg Kulikov
Anyone knows NAT which assignes two or more public ip to the same local address? Isn't it a conflict with nat idea in general?
On Oct 15, 2011 2:35 AM, "Ivelin Ivanov" <ivelin.atan...@gmail.com> wrote:
Laurent,
Thank you for sharing your experience with the NAT problem.
If I am not mistaken in your case, all client phones that are behind a
NAT use the same public IP for SIP and RTP packets.
In Yulian's case, an unfriednly NAT, uses different IPs for SIP and
RTP packets.
Your solution would inform RTPProxy of the SIP IP address to limit
exposure to noisy RTP packets, but it will not work, because RTP
packets bound for the client phone will go to the public NAT SIP IP,
which is not the same as the public NAT RTP IP.
Yulian, would it be a viable solution if the RTPProxy is allowed to
listen to the IP of the SIP packet and a small range of IPs around it?
Maybe a configurable mask can be applied towards the SIP IP address to
control the allowed range.
Ivelin
On Thu, Oct 13, 2011 at 2:44 AM, Laurent Schweizer
<laurent....@peoplefone.com> wrote:
> Hel...
Henrique Cunha
Laurent Schweizer
Hi,
yes in my case all my customer use same public IP for voice and SIP.
if you use the RTPproxy without any change, then you can have different IP for voice and SIP as he was not checking the IP sent by openser and use the first received packet to configure the relay.
this solution has a bad issue, with some pbx (like aastra inteligate PBX ). When he transfer a external SIP call to another external SIP call he do a reINVITE to both leg to connect RTP directly (so the pbx is not relaying the voice).
during this process, the pbx is still sending some rtp packet, so the reINVITE inform the RTPproxy to update the relay but he change the configuration with a wrong packet (old stream) so voice is not going to the correct destination.
Regards
Laurent
De : Henrique Cunha [mailto:rick...@gmail.com]
Envoyé : samedi 15 octobre 2011 09:38
À : mobicent...@googlegroups.com
Objet : Re: [mobicents-public] SBC On Media path
Ivelin Ivanov
Israel who sell broadband to their customers, intentionally split SIP
and RTP to make it more difficult for VoIP providers to compete with
their call services.
Ivelin Ivanov
>> NAT is on the way.This knowledge is not enough to know the real RTP
>> and RTCP addresses.
>
> It can modify SDP and send modified SDP to server with alternatives, modes
> and all required information.
Who exactly will modify the SDP: SIP app, SIP proxy? As Yulian stated
earlier and Henrique confirmed, the public RTP address on the client
NAT might be different than the public SIP address on the client NAT.
As Yulian, Sergio, Laurent, Thomas, and Henrique point out,
establishing the remote RTP address after the first packet is received
from the client is a valid, real world use case. Let's find a way to
accomodate it.
>> So practically SBC does resolves NAT issues ( it does also other jobs
>> for example security , etc , but nat traversal is part of its
>> features )
>
> Correct. And SBC in this case will be on perator side.
Can you elaborate. What do you mean that the SBC will be on operator's side?
There is the clint phone side, which is behind some NAT and there is
the sip app side.
Do you mean that the service provider (operator) hosting the Mobicents
sip app and the media server will have a separate SBC deployed, which
will take care of NAT issues? Similar to the implementation that
Laurent describes, where they deploy RTPProxy and OpenSer as SBC to
take care of NAT traversing.
The reasons why I think we should make the effort to accomodate better
NAT traversal somewhere in Mobicents are:
1. NAT traversal is very common
2. Currently it takes deployment, configuration and management of
third party open source or commercial products to solve these very
common problems.
3. It will take little effort to handle it in Mobicents.
>> After that use proxy leg ( its just a name by the way ) and magic ,
>> you get a sound.
>> So it does helps.May be its not well implemented , but it works.
>
> True. But what I trying to deliver to your mind that the problem is exact in
> implementation. It spawn much more problems then solves and it is a hiden
> bomb. And I proposed to you long time ago the better way to implement the
> same thing. Do you agree that alternatives allow you to reach the same goal?
Oleg, can you share with the rest of us the alternative proposal you
offered to Yulian.
Ivelin
Ivelin Ivanov
> The RFC describes the way how to instruct server about possible late binding
> or switching other party at runtime. This way is realy used in practice.
OK, I can see that it can be used in practice, but that won't solve
the problem at hand, because the remote client RTP IP is not know
until the client start sending packets.
>> 2. Thanks to Sergio for pointing out that if we implement the Media
>> Proxy feature in MMS it may not benefit MCU. I am not sure what's the
>> best way to address this point yet.
>
> Proxying can not so-exist effectively with media server core even.
Can you please elaborate. From reviewing Yulian's patch, I don't see
any extra workload that would impact the work of the scheduler. I may
be missing something.
>> 3. It is quite clear that Yulian's patch is solving a real problem and
>> its worthwhile implementing.
>
> 1. What will happen if media part on both sides are using this way and will
> wait each other to send a packet? say JSR-309 TCK. Specific configuration
> for TCK?
No, Mobicents supports STUN/ICE, so it can discover its own NAT IPs and ports.
> 2. What will happen if client is in receive only mode?
This is a new use case that will have to be analyzed and solved. Do
you have suggestions?
> 3. What will happen if client in send/recv mode but silence suppression is
> enabled?
Another use case that needs additional analysis. It does not make
Yulian's proposal weaker.
> 4. What will happen if another server will receive first broken packet from
> unexpected source (since it is UDP)
Good point. Laurent's proposal seems to help here. We can limit the
range of IPs that the media proxy accepts, based on the SIP IP. Not
sure what the exact mechanism should be, given that the SDP in the
MGCP from the SIP app server to the Media Server doesn't carry the SIP
IP information by default. Suggestions?
> 5. How to detect broken RTP connections if no packets has been received
> during some time: wait while client will start to send data or the
> connection is broken?
How do we do it now? Does it need to change? Timeout seems appropriate.
> 6. How to handle flood? If other packets (RTP or other UDP) will come
> periodicaly?
How do we handle that now?
> 7. What about security? Do you think that possible placing third persion
> into the existing call will be a good idea?
How does Yulian's patch escalate the security risk? Besides what was
already discussed above.
> 8. What about network attacks?
Same question. How does Yulian's patch escalate the security risk?
> 9. How to handle earlier media sessions?
Can you illustrate with a sequence diagram?
> 10. How to handle re-invitations( connection modifications, first packet has
> been received already)
What makes re-invitations harder than before?
> 12. How correlate late binding delays with pre-speech timers?
Can you please elaborate. I am not sure what this means.
Ivelin
Oleg Kulikov
inline:
OK, I can see that it can be used in practice, but that won't solve
> The RFC describes the way how to instruct server about possible late binding
> or switching other party at runtime. This way is realy used in practice.
the problem at hand, because the remote client RTP IP is not know
until the client start sending packets.
Can you please elaborate. From reviewing Yulian's patch, I don't see
>> 2. Thanks to Sergio for pointing out that if we implement the Media
>> Proxy feature in MMS it may not benefit MCU. I am not sure what's the
>> best way to address this point yet.
>
> Proxying can not so-exist effectively with media server core even.
any extra workload that would impact the work of the scheduler. I may
be missing something.
>> 3. It is quite clear that Yulian's patch is solving a real problem andNo, Mobicents supports STUN/ICE, so it can discover its own NAT IPs and ports.
>> its worthwhile implementing.
>
> 1. What will happen if media part on both sides are using this way and will
> wait each other to send a packet? say JSR-309 TCK. Specific configuration
> for TCK?
This is a new use case that will have to be analyzed and solved. Do
> 2. What will happen if client is in receive only mode?
you have suggestions?
Another use case that needs additional analysis. It does not make
> 3. What will happen if client in send/recv mode but silence suppression is
> enabled?
Yulian's proposal weaker.
Good point. Laurent's proposal seems to help here. We can limit the
> 4. What will happen if another server will receive first broken packet from
> unexpected source (since it is UDP)
range of IPs that the media proxy accepts, based on the SIP IP. Not
sure what the exact mechanism should be, given that the SDP in the
MGCP from the SIP app server to the Media Server doesn't carry the SIP
IP information by default. Suggestions?
How do we do it now? Does it need to change? Timeout seems appropriate.
> 5. How to detect broken RTP connections if no packets has been received
> during some time: wait while client will start to send data or the
> connection is broken?
How do we handle that now?
> 6. How to handle flood? If other packets (RTP or other UDP) will come
> periodicaly?
How does Yulian's patch escalate the security risk? Besides what was
> 7. What about security? Do you think that possible placing third persion
> into the existing call will be a good idea?
already discussed above.
it is possible to listen another calls.
> 8. What about network attacks?Same question. How does Yulian's patch escalate the security risk?
Can you illustrate with a sequence diagram?
> 9. How to handle earlier media sessions?
> 10. How to handle re-invitations( connection modifications, first packet hasWhat makes re-invitations harder than before?
> been received already)
Can you please elaborate. I am not sure what this means.
> 12. How correlate late binding delays with pre-speech timers?
Ivelin
Ivelin Ivanov
> The RFC describes the way how to instruct server about possible late bindingOK, I can see that it can be used in practice, but that won't solve
> or switching other party at runtime. This way is realy used in practice.
the problem at hand, because the remote client RTP IP is not know
until the client start sending packets.it defines address(es) from where client will send. application/developer guide server what to do instead of wild server logic to take first packet from anywhere.
>> 2. Thanks to Sergio for pointing out that if we implement the MediaCan you please elaborate. From reviewing Yulian's patch, I don't see
>> Proxy feature in MMS it may not benefit MCU. I am not sure what's the
>> best way to address this point yet.
>
> Proxying can not so-exist effectively with media server core even.
any extra workload that would impact the work of the scheduler. I may
be missing something.
it is not obvious from patch. proxying suppose io only and it is possible to ignore dependency of send/recv operation from packet length. it means that most optimal scheduler for such specific case is standard round-robbin multithreaded system. See Vladimir's blog how it works on practice. Mixing IO tasks with transcoding much more complicated task and we have to use heuristics to find optimal scheduling what is always not optimal. proxy with mms core on same scheduler makes any heuristics much less effective.
> 1. What will happen if media part on both sides are using this way and willNo, Mobicents supports STUN/ICE, so it can discover its own NAT IPs and ports.
> wait each other to send a packet? say JSR-309 TCK. Specific configuration
> for TCK?
The question is not about NAT. Nothing will work after patching, both ends will wait each other for sending.
This is a new use case that will have to be analyzed and solved. Do
> 2. What will happen if client is in receive only mode?
you have suggestions?The solution assumes removing Yulian patch and detailed alanysis of SDP instead.
> 3. What will happen if client in send/recv mode but silence suppression isAnother use case that needs additional analysis. It does not make
> enabled?
Yulian's proposal weaker.Again, solution suppose removing patch and analisys of SDP for alternatives and transmission modes
> 4. What will happen if another server will receive first broken packet fromGood point. Laurent's proposal seems to help here. We can limit the
> unexpected source (since it is UDP)
range of IPs that the media proxy accepts, based on the SIP IP. Not
sure what the exact mechanism should be, given that the SDP in the
MGCP from the SIP app server to the Media Server doesn't carry the SIP
IP information by default. Suggestions?Alternatives in SDP which excludes wrong addresses
> 5. How to detect broken RTP connections if no packets has been receivedHow do we do it now? Does it need to change? Timeout seems appropriate.
> during some time: wait while client will start to send data or the
> connection is broken?
Now it asumes the connection is established immediately.
> 6. How to handle flood? If other packets (RTP or other UDP) will comeHow do we handle that now?
> periodicaly?
No such problem now but it will be after patching without any way to fix it in future
How does Yulian's patch escalate the security risk? Besides what was
> 7. What about security? Do you think that possible placing third persion
> into the existing call will be a good idea?
already discussed above.
it is possible to listen another calls.
> 8. What about network attacks?Same question. How does Yulian's patch escalate the security risk?
it reacts on first packet from anywhere
Can you illustrate with a sequence diagram?
> 9. How to handle earlier media sessions?
SDP in 180 Ringing, transmission of media then 200 Ok with another SDP and another stream
> 10. How to handle re-invitations( connection modifications, first packet hasWhat makes re-invitations harder than before?
> been received already)
media path already established following to patch