Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC
Brought to you by:
joegenbaclor
Menu
▾
▴
Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC
|
From: Joegen E. B. <joe...@gm...> - 2007-09-27 13:30:10
|
Hi Ashish,
Technically speaking, there is no rule that was broken by the scenario
you have just pointed out. However, far end media anchor requires that
rtp use synchronized ports for the hack to work. I guess you do not
have not have any choice but to do the routing of packets in the
application layer instead of using the driver layer to do it for you.
Joegen
Ashish Khare wrote:
> Hi Joegen,
> Please reply.
>
> -Ashish
>
>
> On 9/26/07, *Ashish Khare* <ash...@gm...
> <mailto:ash...@gm...>> wrote:
>
> Hi Joegen,
>
> Sorry for the not mentioning the problem exactly.
> I was using my sip stacks to modify the SDP parameters, and then
> using RTP proxy to route the RTP packets.
> There I hit this problem.
> So it means that RTP/RTCP should be send from the same port on
> which the RTP/RTCP packets are recieved.
> I need a suggestion from you?
> We are developing a Kernel based RTP proxy where will modify the
> IP rules in kernel for routing of RTP and RTCP packets.
> Can I handle this problem there also. where I will recieved UDP
> packet on one port and then send the UDP port from a
> nother port.
> Please reply.
>
> regards,
> Ashish
>
>
> On 9/26/07, *Joegen E. Baclor* <joe...@gm...
> <mailto:joe...@gm...>> wrote:
>
> I have checked the code and what you have stated is simply not the
> case. OpenSBC uses two separate RTP streams for leg1 and
> leg2. All
> packets to and from a leg should be using the same socket and
> port. I
> have pasted the relevant code here. You will see that all
> packets read
> from a leg is written using the other legs rtp stream.
>
> File: B2BMediaInterface.cxx
>
> void B2BMediaInterface::OpalMediaThread::Main()
> {
> PTRACE( 1, "RTP_UDP\tStarted Media Stream" );
> for(;;)
> {
> if( !m_IsPaused )
> {
> RTP_DataFrame frame;
> if( !m_Leg1->ReadData( frame ) )
> break;
>
> if( !m_Leg2->WriteData( frame ) )
> break;
> }
> }
> PTRACE( 1, "RTP_UDP\tClosing Media Stream" );
> }
>
>
> Joegen
>
> Ashish Khare wrote:
> > Hi Joegen,
> >
> > I have one more doubt regarding the RTP communication between
> two clients
> > when using the SBC architecture.
> >
> > Here is the scenario:
> >
> > 172.25.24.189:8000
> <http://172.25.24.189:8000/>
> 172.25.24.90:7000 <http://172.25.24.90:7000/>
> > A
> >
> >
> > RTP Proxy
> >
> > B
> > 172.25.24.155:9000 <http://172.25.24.155:9000/>
> > 172.25.24.90:6000 <http://172.25.24.90:6000/>
> >
> >
> > A is calling B through Proxy.
> > In INVITE , A sends SDP 172.25.24.189
> <http://172.25.24.189/>: and port 8000.
> > SBC modifies the Invite and sends to B with SDP
> 172.25.24.90:6000 <http://172.25.24.90:6000/>.
> > B see;s the Incoming SDP as 172.25.24.90:6000
> <http://172.25.24.90:6000/>.
> > Now in 183/200 OK, B replies with its own SDP as
> 172.25.24.155:9000 <http://172.25.24.155:9000/>
> > SBC modifies it and sends to A as 172.25.24.90:7000
> <http://172.25.24.90:7000/>.
> > A see's the incoming SDP as 172.25.24.90:7000
> <http://172.25.24.90:7000/>.
> > Initial RTP from B comes to RTP proxy at 172.25.24.90:6000
> <http://172.25.24.90:6000/> which RTP proxy
> > sends to A( 172.25.24.189:8000 <http://172.25.24.189:8000/>)
> using socket on 172.25.24.90:6000 <http://172.25.24.90:6000/>.
> > When A replies with RTP, RTP proxy recieves RTP on
> 172.25.24.90:7000 <http://172.25.24.90:7000/> and
> > sends to B( 172.25.24.155:9000 <http://172.25.24.155:9000/>)
> using socket 172.25.24.90:7000 <http://172.25.24.90:7000/>.
> > Now B see's that RTP is coming from new port 7000 and start
> sending the RTP
> > on the new port 172.25.24.90:7000 <http://172.25.24.90:7000/>.
> >
> > Because of this problem, my RTP messages from B are lost.
> > Is it necessary that the port on which the RTP messages are
> recieved from a
> > particular entity, the same port should be used to send the
> RTP messages to
> > that particular entity.
> > Please reply.
> >
> > regards,
> > Ashish
> >
> >
> >
> >
> >
> > On 9/5/07, Ashish Khare < ash...@gm...
> <mailto:ash...@gm...>> wrote:
> >
> >> Thanks Joegen,
> >> Your inputs will certainly help us.
> >>
> >> -Ashish
> >>
> >>
> >> On 9/5/07, Joegen E. Baclor < joe...@gm...
> <mailto:joe...@gm...>> wrote:
> >>
> >>> Ashish Khare wrote:
> >>>
> >>>> But against what you will check the SSRC of the first RTP
> packet
> >>>>
> >>> recieved
> >>>
> >>>> from A.
> >>>> Means against what you will check the SSRC of incoming
> first RTP
> >>>>
> >>> packet from
> >>>
> >>>> A.
> >>>>
> >>>>
> >>> I can see where you are coming from. The basis of which
> SSRC to accept
> >>> would be hard if not impossible to determine. I guess
> this is a
> >>> limitation of remote media anchoring and implementors must
> put up other
> >>> mechanisms to prevent such malicious attacks from
> happening. If you
> >>> have control over your UA, one possible way is to compute
> the SSRC from
> >>> the Session ID offered in the SDP and have that as the
> basis for which
> >>> SSRC you must accept.
> >>>
> >>>
> >>>> -Ashish
> >>>>
> >>>>
> >>>> On 9/5/07, Joegen E. Baclor < joe...@gm...
> <mailto:joe...@gm...> > wrote:
> >>>>
> >>>>
> >>>>> Ashish Khare wrote:
> >>>>>
> >>>>>
> >>>>>> But then in second case
> >>>>>> does it will pose a security threat ?
> >>>>>> Because anyone can spoof an IP address and sends the RTP
> from
> >>>>>>
> >>> different
> >>>
> >>>>> port
> >>>>>
> >>>>>
> >>>>>> ?
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> Technically yes. But this can be augmented by checking
> the ssrc of
> >>>>>
> >>> the
> >>>
> >>>>> RTP packet. OpenSBC can be set to ignore RTP packets if
> the ssrc has
> >>>>>
> >>>>> changed.
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>> On 9/5/07, Joegen E. Baclor < joe...@gm...
> <mailto:joe...@gm...>> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> Ashish Khare wrote:
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Hi Joegen,
> >>>>>>>>
> >>>>>>>> I have two questions for RTP communication in openSBC.
> >>>>>>>>
> >>>>>>>> 1) clients have to use the same RTP ports to send the
> RTP packets
> >>>>>>>>
> >>> on
> >>>
> >>>>>>>>
> >>>>>>> which
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> they recieve RTP packets. So if the client is
> recieveing RTP
> >>>>>>>>
> >>> packets
> >>>
> >>>>> on
> >>>>>
> >>>>>
> >>>>>>> port
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> 8000, Cient will use 8000 only to send the RTP packets?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Most implementations do this, yes. In fact this
> behavior is needed
> >>>>>>>
> >>> for
> >>>
> >>>>>>> OpenSBC NAT traversal to work.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> 2) When natted client initiated the call, for example
> Client A
> >>>>>>>>
> >>> which
> >>>
> >>>>> is
> >>>>>
> >>>>>
> >>>>>>>> behind a NAT, calls B through openSBC, the first RTP
> packets need
> >>>>>>>>
> >>> to
> >>>
> >>>>> be
> >>>>>
> >>>>>
> >>>>>>>> recieved from Client A, at openSBC, in order to send
> the RTP
> >>>>>>>>
> >>> packets
> >>>
> >>>>>>>>
> >>>>>>> from
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Client B to Client A. this is because of NAT device,
> the RTP
> >>>>>>>>
> >>> packets
> >>>
> >>>>>>>>
> >>>>>>> from A
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> comes from different port than what was said in the
> SDP offfer and
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> therefore
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> RTP packets from B need to be send to this new
> port. is my
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> understanding
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> correct. Please clarify.?
> >>>>>>>>
> >>>>>>>> Please reply.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Yes, this is exactly how its done in OpenSBC.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>> Thanks.
> >>>>>>>>
> >>>>>>>> -Ashish
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>
> -------------------------------------------------------------------------
> >>>
> >>>>>>>> This SF.net email is sponsored by: Splunk Inc.
> >>>>>>>> Still grepping through log files to find problems? Stop.
> >>>>>>>> Now Search log events and configuration files using
> AJAX and a
> >>>>>>>>
> >>>>>>>>
> >>>>> browser.
> >>>>>
> >>>>>
> >>>>>>>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>>>>>>> _______________________________________________
> >>>>>>>> opensipstack-devel mailing list
> >>>>>>>> ope...@li...
> <mailto:ope...@li...>
> >>>>>>>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>
> -------------------------------------------------------------------------
>
> >>>
> >>>>>>> This SF.net email is sponsored by: Splunk Inc.
> >>>>>>> Still grepping through log files to find problems? Stop.
> >>>>>>> Now Search log events and configuration files using
> AJAX and a
> >>>>>>>
> >>> browser.
> >>>
> >>>>>>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>>>>>> _______________________________________________
> >>>>>>> opensipstack-devel mailing list
> >>>>>>> ope...@li...
> <mailto:ope...@li...>
> >>>>>>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>
> -------------------------------------------------------------------------
>
> >>>
> >>>>>> This SF.net email is sponsored by: Splunk Inc.
> >>>>>> Still grepping through log files to find problems? Stop.
> >>>>>> Now Search log events and configuration files using AJAX
> and a
> >>>>>>
> >>> browser.
> >>>
> >>>>>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>>>>> _______________________________________________
> >>>>>> opensipstack-devel mailing list
> >>>>>> ope...@li...
> <mailto:ope...@li...>
> >>>>>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> <https://lists.sourceforge.net/lists/listinfo/opensipstack-devel>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>
> -------------------------------------------------------------------------
>
> >>>
> >>>>> This SF.net email is sponsored by: Splunk Inc.
> >>>>> Still grepping through log files to find problems? Stop.
> >>>>> Now Search log events and configuration files using AJAX
> and a
> >>>>>
> >>> browser.
> >>>
> >>>>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>>>> _______________________________________________
> >>>>> opensipstack-devel mailing list
> >>>>> ope...@li...
> <mailto:ope...@li...>
> >>>>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> <https://lists.sourceforge.net/lists/listinfo/opensipstack-devel>
> >>>>>
> >>>>>
> >>>>>
> >>>
> -------------------------------------------------------------------------
>
> >>>
> >>>> This SF.net email is sponsored by: Splunk Inc.
> >>>> Still grepping through log files to find problems? Stop.
> >>>> Now Search log events and configuration files using AJAX
> and a
> >>>>
> >>> browser.
> >>>
> >>>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>>> _______________________________________________
> >>>> opensipstack-devel mailing list
> >>>> ope...@li...
> <mailto:ope...@li...>
> >>>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> <https://lists.sourceforge.net/lists/listinfo/opensipstack-devel>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> -------------------------------------------------------------------------
>
> >>>
> >>> This SF.net email is sponsored by: Splunk Inc.
> >>> Still grepping through log files to find problems? Stop.
> >>> Now Search log events and configuration files using AJAX
> and a browser.
> >>> Download your FREE copy of Splunk now >>
> http://get.splunk.com/
> >>> _______________________________________________
> >>> opensipstack-devel mailing list
> >>> ope...@li...
> <mailto:ope...@li...>
> >>>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> <https://lists.sourceforge.net/lists/listinfo/opensipstack-devel>
> >>>
> >>>
> >>
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> <http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/>
> > _______________________________________________
> > opensipstack-devel mailing list
> > ope...@li...
> <mailto:ope...@li...>
> > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> <https://lists.sourceforge.net/lists/listinfo/opensipstack-devel>
> >
> >
> >
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> <mailto:ope...@li...>
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
>
>
|
