Re: [OpenSIPStack] Questions Regarding RTP communication in openSBC

[Joegen E. B. <joe...@gm...>]

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