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-26 15:53:27
|
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:7000 and
> > 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
>
|
