Thread: [OpenSIPStack] Questions Regarding RTP communication in openSBC
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
|
From: Ashish K. <ash...@gm...> - 2007-09-05 05:02:57
|
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? 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. Thanks. -Ashish |
|
From: Joegen E. B. <joe...@gm...> - 2007-09-05 05:32:19
|
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 > > > |
|
From: Ashish K. <ash...@gm...> - 2007-09-05 05:44:05
|
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 ? 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 > |
|
From: Joegen E. B. <joe...@gm...> - 2007-09-05 05:47:16
|
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 > > > |
|
From: Ashish K. <ash...@gm...> - 2007-09-05 05:57:30
|
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. -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 > |
|
From: Joegen E. B. <joe...@gm...> - 2007-09-05 06:31:36
|
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 > > > |
|
From: Ashish K. <ash...@gm...> - 2007-09-05 06:49:38
|
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 > |
|
From: Ashish K. <ash...@gm...> - 2007-09-26 13:10:24
|
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 > > > > |
|
From: Joegen E. B. <joe...@gm...> - 2007-09-26 14:49:08
|
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
>
>
>
|
|
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
>
|
|
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
> >
>
>
|
|
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
>
>
>
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X