Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC
Brought to you by:
joegenbaclor
Menu
▾
▴
Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC
|
From: Ashish K. <ash...@gm...> - 2007-09-27 06:09:31
|
Hi Joegen,
Please reply.
-Ashish
On 9/26/07, Ashish Khare <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 another port.
> Please reply.
>
> regards,
> Ashish
>
>
> On 9/26/07, Joegen E. Baclor <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
> > 172.25.24.90:7000
> > > A
> > >
> > >
> > > RTP Proxy
> > >
> > > B
> > > 172.25.24.155:9000
> > > 172.25.24.90:6000
> > >
> > >
> > > A is calling B through Proxy.
> > > In INVITE , A sends SDP 172.25.24.189: and port 8000.
> > > SBC modifies the Invite and sends to B with SDP 172.25.24.90:6000.
> > > B see;s the Incoming SDP as 172.25.24.90:6000.
> > > Now in 183/200 OK, B replies with its own SDP as 172.25.24.155:9000
> > > SBC modifies it and sends to A as 172.25.24.90:7000 .
> > > A see's the incoming SDP as 172.25.24.90:7000.
> > > Initial RTP from B comes to RTP proxy at 172.25.24.90:6000 which RTP
> > proxy
> > > sends to A(172.25.24.189:8000) using socket on 172.25.24.90:6000.
> > > When A replies with RTP, RTP proxy recieves RTP on 172.25.24.90:7000and
> > > sends to B(172.25.24.155:9000) using socket 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.
> > >
> > > 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...> wrote:
> > >
> > >> Thanks Joegen,
> > >> Your inputs will certainly help us.
> > >>
> > >> -Ashish
> > >>
> > >>
> > >> On 9/5/07, Joegen E. Baclor <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... > 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...> 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...
> > >>>>>>>> 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...
> > >>>>>>> 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...
> > >>>>>> 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...
> > >>>>> 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...
> > >>>> 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...
> > >>> 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...
> > > 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...
> > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
> >
>
>
|
