Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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
> >
>
>