opensipstack-devel Mailing List for OpenSIPStack (Page 42)
Brought to you by:
joegenbaclor
Menu
▾
▴
opensipstack-devel
You can subscribe to this list here.
| 2006 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(12) |
Jul
(4) |
Aug
(3) |
Sep
(24) |
Oct
(45) |
Nov
(41) |
Dec
(67) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(51) |
Feb
(93) |
Mar
(54) |
Apr
(76) |
May
(114) |
Jun
(133) |
Jul
(124) |
Aug
(180) |
Sep
(53) |
Oct
(41) |
Nov
(109) |
Dec
(92) |
| 2008 |
Jan
(52) |
Feb
(40) |
Mar
(29) |
Apr
(40) |
May
(83) |
Jun
(68) |
Jul
(30) |
Aug
(72) |
Sep
(50) |
Oct
(48) |
Nov
(25) |
Dec
(80) |
| 2009 |
Jan
(9) |
Feb
(2) |
Mar
(32) |
Apr
(67) |
May
|
Jun
(7) |
Jul
(7) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(6) |
Dec
(2) |
| 2010 |
Jan
|
Feb
(4) |
Mar
|
Apr
|
May
(10) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(5) |
Dec
|
| 2011 |
Jan
|
Feb
|
Mar
(1) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(5) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Joegen E. B. <joe...@gm...> - 2007-10-01 05:05:06
|
Madarassy, The SIP Trunk code is still incomplete. I am expecting initial work to=20 be in CVS by Tuesday evening. Watch this space Joegen Madarassy L=E1szl=F3 wrote: > Hi, > > I realized, the latest opensbc snapshot supports SIP trunks, but only a= sample sip-trunk.conf.xml available. Can you help me understanding the c= onfig file or sending some more examples? > > =DCdv=F6zlettel, > > Madarassy L=E1szl=F3 > m=E9rn=F6k/Engineer > BME Mobil Innov=E1ci=F3s K=F6zpont/BME Mobile Innovation Centre > H-1111 Budapest, Bertalan Lajos u. 2. III/302. > Telefon: (+36) 1/463-3308 =20 > Fax: (+36) 1/463-3307 =20 > e-mail: lma...@mi... =20 > www.mik.bme.hu =20 > > -----------------------------------------------------------------------= -- > 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 > > > =20 |
|
From: <jo...@op...> - 2007-09-30 07:01:19
|
Hey Bob, It seems that the platform SDK is not properly located by the build process. Make sure that it is installed and properly detected by the configure script. An example healthy build bootstrap is pasted below Searching C:\ Located OPAL at C:\dev\opensipstack\ Located SQLITE at C:\dev\opensipstack\external\CppSQLite\3.1\Common\ Located CPPSQLITE at C:\dev\opensipstack\external\CppSQLite\3.1\Common\ Located Expat XML at C:\dev\opensipstack\external\Expat-2.0.0\ Located DNS Resolver at C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\ Located IPv6 Support at C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\ Located QoS Support at C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\ Located IP Helper Support at C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\PlatformSDK\Include\ Bob Howland wrote: > Here is the error info > > SIPTransport.cxx > .\src\SIPTransport.cxx(682) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPTransport.cxx(682) : error C3861: 'SetENUMServers': > identifier not found > .\src\SIPTransport.cxx(685) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPTransport.cxx(688) : error C2664: > 'SIPTransports::SIPTransport::ENUMLookup' : cannot convert parameter 1 > from 'const char *' to 'const PStringArray &' > Reason: cannot convert from 'const char *' to 'const PStringArray' > No constructor could take the source type, or constructor > overload resolution was ambiguous > SIPTCPTransport.cxx > SIPSrvRecord.cxx > .\src\SIPSrvRecord.cxx(426) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(426) : error C2065: 'SRVRecordList' : > undeclared identifier > .\src\SIPSrvRecord.cxx(426) : error C2065: 'srvUdpRecords' : > undeclared identifier > .\src\SIPSrvRecord.cxx(427) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(427) : error C2065: 'srvTcpRecords' : > undeclared identifier > .\src\SIPSrvRecord.cxx(438) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(438) : error C2061: syntax error : identifier > 'SRVRecordList' > .\src\SIPSrvRecord.cxx(442) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(442) : error C2061: syntax error : identifier > 'SRVRecordList' > .\src\SIPSrvRecord.cxx(443) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(443) : error C3861: 'GetRecords': identifier > not found > .\src\SIPSrvRecord.cxx(446) : error C2541: 'delete' : cannot delete > objects that are not pointers > .\src\SIPSrvRecord.cxx(454) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(454) : error C2061: syntax error : identifier > 'SRVRecordList' > .\src\SIPSrvRecord.cxx(455) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(455) : error C3861: 'GetRecords': identifier > not found > .\src\SIPSrvRecord.cxx(462) : error C2541: 'delete' : cannot delete > objects that are not pointers > .\src\SIPSrvRecord.cxx(470) : error C2653: 'PDNS' : is not a class or > namespace name > .\src\SIPSrvRecord.cxx(470) : error C2065: 'SRVRecord' : undeclared > identifier > .\src\SIPSrvRecord.cxx(470) : error C2065: 'recPtr' : undeclared > identifier > .\src\SIPSrvRecord.cxx(470) : error C2227: left of '->GetFirst' must > point to class/struct/union/generic type > type is ''unknown-type'' > .\src\SIPSrvRecord.cxx(471) : fatal error C1903: unable to recover > from previous error(s); stopping compilation > SIPTransactionStage.cxx > > What am I doing wrong > > > Bob Howland > > Training Engineer > > +1-240-3649184 > > rho...@br... <mailto:rho...@br...> > > > > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.488 / Virus Database: 269.13.33/1036 - Release Date: 9/28/2007 3:40 PM > |
|
From: <na...@yu...> - 2007-09-28 20:45:10
|
Hi, Open SBC came right up following the build instructions. The application is Nat transversal and RTP proxy. Here is the configuration: SIP Server <- ----------------> OSBC <- -------------------------------> Internet<- -------------------> Router <- ----------------------> Sip Client PrivateIP A PrivateIP B and Public IP A Public IP B and PrivateIP C Private IP D I have tried changing every field that made sense to me though the OSBC web interface and so far have only been able to make the Sip Client ring and have one way voice. What setting on the OSBC need to be changed to make this work? What values/syntax need to be used? Thanks, Don |
|
From: <lma...@mi...> - 2007-09-28 08:10:30
|
Hi, I realized, the latest opensbc snapshot supports SIP trunks, but only a = sample sip-trunk.conf.xml available. Can you help me understanding the = config file or sending some more examples? =DCdv=F6zlettel, Madarassy L=E1szl=F3 m=E9rn=F6k/Engineer BME Mobil Innov=E1ci=F3s K=F6zpont/BME Mobile Innovation Centre H-1111 Budapest, Bertalan Lajos u. 2. III/302. Telefon: (+36) 1/463-3308 =20 Fax: (+36) 1/463-3307 =20 e-mail: lma...@mi... =20 www.mik.bme.hu =20 |
|
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
>
>
>
|
|
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: 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: Joegen E. B. <joe...@gm...> - 2007-09-26 15:03:41
|
OpenSIPStack goes with an internal PWLIB and Opal code. These are modified versions of Opal and PWLIB. If you have PWLIB and OPAL in the search path, I suggest you remove them first to avoid conflicts with OpenSIPStack compilation. sub...@wi... wrote: > > Hi, > I am getting the while error while compiling opensipstack. > > > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:106:24: > speex_echo.h: No such file or directory > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:107:30: > speex_preprocess.h: No such file or directory > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In destructor > ` > virtual OpalEchoCanceler::~OpalEchoCanceler()': > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:158: error: ` > speex_echo_state_destroy' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:158: error: > (Each > undeclared identifier is reported only once for each function it > appears > in.) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:163: error: ` > speex_preprocess_state_destroy' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In member > function ` > void OpalEchoCanceler::SetParameters(const > OpalEchoCanceler::Params&)': > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:187: error: ` > speex_echo_state_destroy' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:192: error: ` > speex_preprocess_state_destroy' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In member > function ` > virtual void OpalEchoCanceler::ReceivedPacket(RTP_DataFrame&, int)': > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:233: error: ` > speex_echo_state_init' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:236: error: ` > speex_preprocess_state_init' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:237: error: ` > SPEEX_PREPROCESS_SET_DENOISE' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:237: error: ` > speex_preprocess_ctl' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:241: error: ` > spx_int16_t' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:241: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:246: error: ` > spx_int32_t' undeclared (first use this function) > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:249: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:251: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:257: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:267: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:268: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:277: error: > syntax > error before `)' token > /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:284: error: > syntax > error before `)' token > make[3]: *** [/home/voip/opensipstack/lib/obj_linux_x86_r/echocancel.o] > Error 1 > make[3]: Leaving directory `/home/voip/opensipstack/src' > make[2]: *** > [/home/voip/opensipstack/lib/libopensipstack_linux_x86_r_s.a] Error 2 > make[2]: Leaving directory `/home/voip/opensbc' > make[1]: *** [optnoshared] Error 2 > make[1]: Leaving directory `/home/voip/opensbc' > make: *** [bothnoshared] Error 2 > > > I have opal 2.2.8 and pwlib1.10.7 and gcc34 on a Fedora machine with > kernel version 2.6.5 > Kindly help me in this regard. > > > Regards, > Subha, > > > ------------------------------------------------------------------------- > 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: <sub...@wi...> - 2007-09-26 14:57:57
|
=20 Hi, I am getting the while error while compiling opensipstack. =20 =20 /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:106:24: speex_echo.h: No such file or directory /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:107:30: speex_preprocess.h: No such file or directory /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In destructor ` virtual OpalEchoCanceler::~OpalEchoCanceler()': /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:158: error: ` speex_echo_state_destroy' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:158: error: (Each undeclared identifier is reported only once for each function it appears in.) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:163: error: ` speex_preprocess_state_destroy' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In member function ` void OpalEchoCanceler::SetParameters(const OpalEchoCanceler::Params&)': /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:187: error: ` speex_echo_state_destroy' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:192: error: ` speex_preprocess_state_destroy' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx: In member function ` virtual void OpalEchoCanceler::ReceivedPacket(RTP_DataFrame&, int)': /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:233: error: ` speex_echo_state_init' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:236: error: ` speex_preprocess_state_init' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:237: error: ` SPEEX_PREPROCESS_SET_DENOISE' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:237: error: ` speex_preprocess_ctl' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:241: error: ` spx_int16_t' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:241: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:246: error: ` spx_int32_t' undeclared (first use this function) /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:249: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:251: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:257: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:267: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:268: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:277: error: syntax error before `)' token /home/voip/opensipstack/src/opal/src/codec/echocancel.cxx:284: error: syntax error before `)' token make[3]: *** [/home/voip/opensipstack/lib/obj_linux_x86_r/echocancel.o] Error 1 make[3]: Leaving directory `/home/voip/opensipstack/src' make[2]: *** [/home/voip/opensipstack/lib/libopensipstack_linux_x86_r_s.a] Error 2 make[2]: Leaving directory `/home/voip/opensbc' make[1]: *** [optnoshared] Error 2 make[1]: Leaving directory `/home/voip/opensbc' make: *** [bothnoshared] Error 2 =20 I have opal 2.2.8 and pwlib1.10.7 and gcc34 on a Fedora machine with kernel version 2.6.5 Kindly help me in this regard. =20 =20 Regards, Subha, =20 =20 |
|
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 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-21 11:22:27
|
Hi, OpenSBC indeed failed to process the INVITE because SDP is missing. I=20 have commited a possible fix for this in CVS. Can you test if INVITE is = now getting propagated ? Joegen Madarassy L=E1szl=F3 wrote: > Hi, > > Sorry, link fixed. It containts wireshark captures and opensbc log. > > Thanks > > madar > ----- Original Message ----- From: "Joegen E. Baclor"=20 > <joe...@gm...> > To: "Madarassy L=E1szl=F3" <lma...@mi...>;=20 > <ope...@li...> > Sent: Friday, September 21, 2007 8:52 AM > Subject: Re: [OpenSIPStack] opensbc problems > > > Hi, > > I need to see the log. > > url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip > > > is a 404 > > Madarassy L=E1szl=F3 wrote: >> Hi! >> >> I'm using opensbc with IMS systems and other sip pbx. It works fine,=20 >> but I have some problems now: >> >> 1. Missing 200 OK: >> >> We tried to call an Avaya SES system through OpenSBC, but we have=20 >> some trouble during the call: >> the message flow is the following: >> SBC sends INVITE to AVAYA >> AVAYA respond TRYING >> AVAYA respond RINGING >> AVAYA send 200 OK >> SBC respond ACK to AVAYA >> AVAYA send the INVITE again >> SBC respond TRYING >> now AVAYA is waiting a 200 OK from SBC, but it doesnt't send. >> >> The connection is estabilished, but it hangs up after 30 sec. >> >> I tried it with our IMS directly and it sends the 200 OK after the=20 >> TRYING. >> Is it a bug or a configuration problem? >> >> I uploaded a capture between sbc and avaya (sbc-avaya.cap), a capture = >> between Huawei and avaya (huawei-avaya.cap) and the opensbc log. >> >> url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip >> >> 2. Removed route header >> >> Opensbc removes Route header from the INVITE message, but IMS need it.= >> >> 3. Adding and rewriting headers to a SIP message >> >> I need to add some extra headers (e.g. Supported header) and modify=20 >> some (e.g. User-Agent) in SIP messages. Are you planning to add a=20 >> feature like this? Or can you help me hard-coding to the source some=20 >> header modifications? >> >> Are you planning ipv6 support? >> >> >> >> Best regards, >> >> Laszlo Madarassy Engineer >> BME Mobile Innovation Centre >> H-1111 Budapest, Bertalan Lajos u. 2. III/302. >> Telefon: (+36) 1/463-3308 Fax: (+36) 1/463-3307 e-mail: = >> lma...@mi... www.mik.bme.hu >> ----------------------------------------------------------------------= ---=20 >> >> 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: <lma...@mi...> - 2007-09-21 07:05:11
|
Hi, Sorry, link fixed. It containts wireshark captures and opensbc log. Thanks madar ----- Original Message ----- From: "Joegen E. Baclor" <joe...@gm...> To: "Madarassy László" <lma...@mi...>; <ope...@li...> Sent: Friday, September 21, 2007 8:52 AM Subject: Re: [OpenSIPStack] opensbc problems Hi, I need to see the log. url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip is a 404 Madarassy László wrote: > Hi! > > I'm using opensbc with IMS systems and other sip pbx. It works fine, but I > have some problems now: > > 1. Missing 200 OK: > > We tried to call an Avaya SES system through OpenSBC, but we have some > trouble during the call: > the message flow is the following: > SBC sends INVITE to AVAYA > AVAYA respond TRYING > AVAYA respond RINGING > AVAYA send 200 OK > SBC respond ACK to AVAYA > AVAYA send the INVITE again > SBC respond TRYING > now AVAYA is waiting a 200 OK from SBC, but it doesnt't send. > > The connection is estabilished, but it hangs up after 30 sec. > > I tried it with our IMS directly and it sends the 200 OK after the TRYING. > Is it a bug or a configuration problem? > > I uploaded a capture between sbc and avaya (sbc-avaya.cap), a capture > between Huawei and avaya (huawei-avaya.cap) and the opensbc log. > > url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip > > 2. Removed route header > > Opensbc removes Route header from the INVITE message, but IMS need it. > > 3. Adding and rewriting headers to a SIP message > > I need to add some extra headers (e.g. Supported header) and modify some > (e.g. User-Agent) in SIP messages. Are you planning to add a feature like > this? Or can you help me hard-coding to the source some header > modifications? > > Are you planning ipv6 support? > > > > Best regards, > > Laszlo Madarassy Engineer > BME Mobile Innovation Centre > H-1111 Budapest, Bertalan Lajos u. 2. III/302. > Telefon: (+36) 1/463-3308 Fax: (+36) 1/463-3307 > e-mail: lma...@mi... www.mik.bme.hu > ------------------------------------------------------------------------- > 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-21 06:52:24
|
Hi, I need to see the log.=20 url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip is a 404 Madarassy L=E1szl=F3 wrote: > Hi! > > I'm using opensbc with IMS systems and other sip pbx. It works fine, bu= t I have some problems now: > > 1. Missing 200 OK: > > We tried to call an Avaya SES system through OpenSBC, but we have some = trouble during the call: > the message flow is the following: > SBC sends INVITE to AVAYA > AVAYA respond TRYING > AVAYA respond RINGING > AVAYA send 200 OK > SBC respond ACK to AVAYA > AVAYA send the INVITE again > SBC respond TRYING > now AVAYA is waiting a 200 OK from SBC, but it doesnt't send. > > The connection is estabilished, but it hangs up after 30 sec. > > I tried it with our IMS directly and it sends the 200 OK after the TRYI= NG. > Is it a bug or a configuration problem? > > I uploaded a capture between sbc and avaya (sbc-avaya.cap), a capture b= etween Huawei and avaya (huawei-avaya.cap) and the opensbc log. > > url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip > > 2. Removed route header > > Opensbc removes Route header from the INVITE message, but IMS need it. > > 3. Adding and rewriting headers to a SIP message > > I need to add some extra headers (e.g. Supported header) and modify som= e (e.g. User-Agent) in SIP messages. Are you planning to add a feature li= ke this? Or can you help me hard-coding to the source some header modific= ations? > > Are you planning ipv6 support? > > > > Best regards, > > Laszlo Madarassy=20 > Engineer > BME Mobile Innovation Centre > H-1111 Budapest, Bertalan Lajos u. 2. III/302. > Telefon: (+36) 1/463-3308 =20 > Fax: (+36) 1/463-3307 =20 > e-mail: lma...@mi... =20 > www.mik.bme.hu =20 > > -----------------------------------------------------------------------= -- > 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 > > > =20 |
|
From: <lma...@mi...> - 2007-09-21 06:40:39
|
Hi! I'm using opensbc with IMS systems and other sip pbx. It works fine, but = I have some problems now: 1. Missing 200 OK: We tried to call an Avaya SES system through OpenSBC, but we have some = trouble during the call: the message flow is the following: SBC sends INVITE to AVAYA AVAYA respond TRYING AVAYA respond RINGING AVAYA send 200 OK SBC respond ACK to AVAYA AVAYA send the INVITE again SBC respond TRYING now AVAYA is waiting a 200 OK from SBC, but it doesnt't send. The connection is estabilished, but it hangs up after 30 sec. I tried it with our IMS directly and it sends the 200 OK after the = TRYING. Is it a bug or a configuration problem? I uploaded a capture between sbc and avaya (sbc-avaya.cap), a capture = between Huawei and avaya (huawei-avaya.cap) and the opensbc log. url: http://home.mik.bme.hu/~madarassy/opensbc-bugreport2.zip 2. Removed route header Opensbc removes Route header from the INVITE message, but IMS need it. 3. Adding and rewriting headers to a SIP message I need to add some extra headers (e.g. Supported header) and modify some = (e.g. User-Agent) in SIP messages. Are you planning to add a feature = like this? Or can you help me hard-coding to the source some header = modifications? Are you planning ipv6 support? Best regards, Laszlo Madarassy=20 Engineer BME Mobile Innovation Centre H-1111 Budapest, Bertalan Lajos u. 2. III/302. Telefon: (+36) 1/463-3308 =20 Fax: (+36) 1/463-3307 =20 e-mail: lma...@mi... =20 www.mik.bme.hu =20 |
|
From: <jo...@op...> - 2007-09-19 15:33:51
|
Hi Craig, I have opened a ticket in the bug tracker for this issue. http://bugs.opensourcesip.org/index.php?redir_bug=4 Craig Guy wrote: > Thankyou Joegen, > > I am more than willing to perform any required testing to help out with > this, and I appreciate your interest in the issue. > > Craig > > -----Original Message----- > From: jo...@op... [mailto:joe...@gm...] > Sent: Thursday, 20 September 2007 11:22 PM > To: Craig Guy > Cc: ope...@li... > Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour > > Hi Craig, > > I got the captures. For starters, I must admit that OpenSIPStack does > not support multipart /mixed as of the moment. Buts since there is now > a real need to support mutipart in the parser, I will be willing to take > it on personally. I can't promise a target date as of the moment > because I am full with other milestone tasks as of the moment. I might > be asking you to perform tests every now and then if you are willing to > work this out with me. > > Joegen > > > Craig Guy wrote: > >> Hi Joegen, >> >> Ok, I have placed them at http://nomates.ath.cx/wanside.cap and >> > lanside.cap > >> and have verified their availability from another network. Please let me >> know they are still unavailable. >> >> Craig >> >> -----Original Message----- >> From: ope...@li... >> [mailto:ope...@li...] On Behalf Of >> jo...@op... >> Sent: Thursday, 20 September 2007 10:56 PM >> To: ope...@li... >> Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour >> >> Craig, >> >> Both links are 404. Let me know when you get them handy for me to see. >> >> >> >> Craig Guy wrote: >> >> >>> Hmmm, >>> >>> I did definitely include them - and they are attached to the email in my >>> sent items, must have been stripped by Gmail or something. >>> >>> You can download them from http://manky.ath.cx/lanside.cap and >>> http://manky.ath.cx/wanside.cap >>> >>> Craig >>> >>> >>> -----Original Message----- >>> From: ope...@li... >>> [mailto:ope...@li...] On Behalf Of >>> Joegen E. Baclor >>> Sent: Thursday, 20 September 2007 10:35 PM >>> To: ope...@li... >>> Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour >>> >>> Craig, >>> >>> You forgot to attach the pcap files. >>> >>> Joegen >>> >>> Craig Guy wrote: >>> >>> >>> >>>> Hi, >>>> >>>> >>>> >>>> I am currently doing interop testing with Level3 who are a tier 1 VoIP >>>> provider in the USA. The architecture I am using has a single box >>>> >>>> >> running >> >> >>>> OpenSBC listening on port 5060 and a copy of Callweaver running on port >>>> 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper >>>> registration and is handling both SIP and RTP. >>>> >>>> >>>> >>>> I have found during interop testing that OpenSBC is not preserving the >>>> >>>> >> SDP >> >> >>>> when initiating the second leg of the call to Callweaver, causing >>>> >>>> >>>> >>> Callweaver >>> >>> >>> >>>> to reject the call with '488 - Not Acceptable Here'. >>>> >>>> >>>> >>>> The difference between the Level3 SIP and other SIP that I've seen is >>>> >>>> >> that >> >> >>>> Level3 are including multiple parts in the message body. If I take >>>> >>>> >>>> >>> OpenSBC >>> >>> >>> >>>> out of the equation and have Level3 talk directly to my Callweaver then >>>> there is no problem. >>>> >>>> >>>> >>>> I have included two tcpdumps of a session. The first dump, wanside.cap >>>> >>>> >> is >> >> >>>> the session from Level3 to OpenSBC and the second dump (lanside.cap) is >>>> >>>> >>>> >>> the >>> >>> >>> >>>> session between OpenSBC and Callweaver. I am happy to capture and >>>> >>>> >> provide >> >> >>>> OpenSBC log and debug if required. >>>> >>>> >>>> >>>> I'd be interested to know if this is a bug, or otherwise. >>>> >>>> >>>> >>>> Craig >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> > ------------------------------------------------------------------------- > >>>> 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 >>>> >>>> ------------------------------------------------------------------------ >>>> >>>> No virus found in this incoming message. >>>> Checked by AVG Free Edition. >>>> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: >>>> >>>> >>>> >>> 9/18/2007 11:53 AM >>> >>> >>> >>>> >>>> >>>> >>>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> >>> >>> >>> >>> >> ------------------------------------------------------------------------- >> 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: Craig G. <cra...@gm...> - 2007-09-19 15:31:17
|
Thankyou Joegen, I am more than willing to perform any required testing to help out with this, and I appreciate your interest in the issue. Craig -----Original Message----- From: jo...@op... [mailto:joe...@gm...] Sent: Thursday, 20 September 2007 11:22 PM To: Craig Guy Cc: ope...@li... Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour Hi Craig, I got the captures. For starters, I must admit that OpenSIPStack does not support multipart /mixed as of the moment. Buts since there is now a real need to support mutipart in the parser, I will be willing to take it on personally. I can't promise a target date as of the moment because I am full with other milestone tasks as of the moment. I might be asking you to perform tests every now and then if you are willing to work this out with me. Joegen Craig Guy wrote: > Hi Joegen, > > Ok, I have placed them at http://nomates.ath.cx/wanside.cap and lanside.cap > and have verified their availability from another network. Please let me > know they are still unavailable. > > Craig > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf Of > jo...@op... > Sent: Thursday, 20 September 2007 10:56 PM > To: ope...@li... > Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour > > Craig, > > Both links are 404. Let me know when you get them handy for me to see. > > > > Craig Guy wrote: > >> Hmmm, >> >> I did definitely include them - and they are attached to the email in my >> sent items, must have been stripped by Gmail or something. >> >> You can download them from http://manky.ath.cx/lanside.cap and >> http://manky.ath.cx/wanside.cap >> >> Craig >> >> >> -----Original Message----- >> From: ope...@li... >> [mailto:ope...@li...] On Behalf Of >> Joegen E. Baclor >> Sent: Thursday, 20 September 2007 10:35 PM >> To: ope...@li... >> Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour >> >> Craig, >> >> You forgot to attach the pcap files. >> >> Joegen >> >> Craig Guy wrote: >> >> >>> Hi, >>> >>> >>> >>> I am currently doing interop testing with Level3 who are a tier 1 VoIP >>> provider in the USA. The architecture I am using has a single box >>> > running > >>> OpenSBC listening on port 5060 and a copy of Callweaver running on port >>> 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper >>> registration and is handling both SIP and RTP. >>> >>> >>> >>> I have found during interop testing that OpenSBC is not preserving the >>> > SDP > >>> when initiating the second leg of the call to Callweaver, causing >>> >>> >> Callweaver >> >> >>> to reject the call with '488 - Not Acceptable Here'. >>> >>> >>> >>> The difference between the Level3 SIP and other SIP that I've seen is >>> > that > >>> Level3 are including multiple parts in the message body. If I take >>> >>> >> OpenSBC >> >> >>> out of the equation and have Level3 talk directly to my Callweaver then >>> there is no problem. >>> >>> >>> >>> I have included two tcpdumps of a session. The first dump, wanside.cap >>> > is > >>> the session from Level3 to OpenSBC and the second dump (lanside.cap) is >>> >>> >> the >> >> >>> session between OpenSBC and Callweaver. I am happy to capture and >>> > provide > >>> OpenSBC log and debug if required. >>> >>> >>> >>> I'd be interested to know if this is a bug, or otherwise. >>> >>> >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> ------------------------------------------------------------------------ >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: >>> >>> >> 9/18/2007 11:53 AM >> >> >>> >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> >> >> >> > > > ------------------------------------------------------------------------- > 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: <jo...@op...> - 2007-09-19 15:22:17
|
Hi Craig, I got the captures. For starters, I must admit that OpenSIPStack does not support multipart /mixed as of the moment. Buts since there is now a real need to support mutipart in the parser, I will be willing to take it on personally. I can't promise a target date as of the moment because I am full with other milestone tasks as of the moment. I might be asking you to perform tests every now and then if you are willing to work this out with me. Joegen Craig Guy wrote: > Hi Joegen, > > Ok, I have placed them at http://nomates.ath.cx/wanside.cap and lanside.cap > and have verified their availability from another network. Please let me > know they are still unavailable. > > Craig > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf Of > jo...@op... > Sent: Thursday, 20 September 2007 10:56 PM > To: ope...@li... > Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour > > Craig, > > Both links are 404. Let me know when you get them handy for me to see. > > > > Craig Guy wrote: > >> Hmmm, >> >> I did definitely include them - and they are attached to the email in my >> sent items, must have been stripped by Gmail or something. >> >> You can download them from http://manky.ath.cx/lanside.cap and >> http://manky.ath.cx/wanside.cap >> >> Craig >> >> >> -----Original Message----- >> From: ope...@li... >> [mailto:ope...@li...] On Behalf Of >> Joegen E. Baclor >> Sent: Thursday, 20 September 2007 10:35 PM >> To: ope...@li... >> Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour >> >> Craig, >> >> You forgot to attach the pcap files. >> >> Joegen >> >> Craig Guy wrote: >> >> >>> Hi, >>> >>> >>> >>> I am currently doing interop testing with Level3 who are a tier 1 VoIP >>> provider in the USA. The architecture I am using has a single box >>> > running > >>> OpenSBC listening on port 5060 and a copy of Callweaver running on port >>> 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper >>> registration and is handling both SIP and RTP. >>> >>> >>> >>> I have found during interop testing that OpenSBC is not preserving the >>> > SDP > >>> when initiating the second leg of the call to Callweaver, causing >>> >>> >> Callweaver >> >> >>> to reject the call with '488 - Not Acceptable Here'. >>> >>> >>> >>> The difference between the Level3 SIP and other SIP that I've seen is >>> > that > >>> Level3 are including multiple parts in the message body. If I take >>> >>> >> OpenSBC >> >> >>> out of the equation and have Level3 talk directly to my Callweaver then >>> there is no problem. >>> >>> >>> >>> I have included two tcpdumps of a session. The first dump, wanside.cap >>> > is > >>> the session from Level3 to OpenSBC and the second dump (lanside.cap) is >>> >>> >> the >> >> >>> session between OpenSBC and Callweaver. I am happy to capture and >>> > provide > >>> OpenSBC log and debug if required. >>> >>> >>> >>> I'd be interested to know if this is a bug, or otherwise. >>> >>> >>> >>> Craig >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> ------------------------------------------------------------------------- >>> 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 >>> >>> ------------------------------------------------------------------------ >>> >>> No virus found in this incoming message. >>> Checked by AVG Free Edition. >>> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: >>> >>> >> 9/18/2007 11:53 AM >> >> >>> >>> >>> >> ------------------------------------------------------------------------- >> 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 >> >> >> >> >> > > > ------------------------------------------------------------------------- > 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: Craig G. <cra...@gm...> - 2007-09-19 15:09:49
|
Hi Joegen, Ok, I have placed them at http://nomates.ath.cx/wanside.cap and lanside.cap and have verified their availability from another network. Please let me know they are still unavailable. Craig -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of jo...@op... Sent: Thursday, 20 September 2007 10:56 PM To: ope...@li... Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour Craig, Both links are 404. Let me know when you get them handy for me to see. Craig Guy wrote: > Hmmm, > > I did definitely include them - and they are attached to the email in my > sent items, must have been stripped by Gmail or something. > > You can download them from http://manky.ath.cx/lanside.cap and > http://manky.ath.cx/wanside.cap > > Craig > > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf Of > Joegen E. Baclor > Sent: Thursday, 20 September 2007 10:35 PM > To: ope...@li... > Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour > > Craig, > > You forgot to attach the pcap files. > > Joegen > > Craig Guy wrote: > >> Hi, >> >> >> >> I am currently doing interop testing with Level3 who are a tier 1 VoIP >> provider in the USA. The architecture I am using has a single box running >> OpenSBC listening on port 5060 and a copy of Callweaver running on port >> 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper >> registration and is handling both SIP and RTP. >> >> >> >> I have found during interop testing that OpenSBC is not preserving the SDP >> when initiating the second leg of the call to Callweaver, causing >> > Callweaver > >> to reject the call with '488 - Not Acceptable Here'. >> >> >> >> The difference between the Level3 SIP and other SIP that I've seen is that >> Level3 are including multiple parts in the message body. If I take >> > OpenSBC > >> out of the equation and have Level3 talk directly to my Callweaver then >> there is no problem. >> >> >> >> I have included two tcpdumps of a session. The first dump, wanside.cap is >> the session from Level3 to OpenSBC and the second dump (lanside.cap) is >> > the > >> session between OpenSBC and Callweaver. I am happy to capture and provide >> OpenSBC log and debug if required. >> >> >> >> I'd be interested to know if this is a bug, or otherwise. >> >> >> >> Craig >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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 >> >> ------------------------------------------------------------------------ >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: >> > 9/18/2007 11:53 AM > >> >> > > > ------------------------------------------------------------------------- > 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 > > > > ------------------------------------------------------------------------- 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: <jo...@op...> - 2007-09-19 14:55:44
|
Craig, Both links are 404. Let me know when you get them handy for me to see. Craig Guy wrote: > Hmmm, > > I did definitely include them - and they are attached to the email in my > sent items, must have been stripped by Gmail or something. > > You can download them from http://manky.ath.cx/lanside.cap and > http://manky.ath.cx/wanside.cap > > Craig > > > -----Original Message----- > From: ope...@li... > [mailto:ope...@li...] On Behalf Of > Joegen E. Baclor > Sent: Thursday, 20 September 2007 10:35 PM > To: ope...@li... > Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour > > Craig, > > You forgot to attach the pcap files. > > Joegen > > Craig Guy wrote: > >> Hi, >> >> >> >> I am currently doing interop testing with Level3 who are a tier 1 VoIP >> provider in the USA. The architecture I am using has a single box running >> OpenSBC listening on port 5060 and a copy of Callweaver running on port >> 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper >> registration and is handling both SIP and RTP. >> >> >> >> I have found during interop testing that OpenSBC is not preserving the SDP >> when initiating the second leg of the call to Callweaver, causing >> > Callweaver > >> to reject the call with '488 - Not Acceptable Here'. >> >> >> >> The difference between the Level3 SIP and other SIP that I've seen is that >> Level3 are including multiple parts in the message body. If I take >> > OpenSBC > >> out of the equation and have Level3 talk directly to my Callweaver then >> there is no problem. >> >> >> >> I have included two tcpdumps of a session. The first dump, wanside.cap is >> the session from Level3 to OpenSBC and the second dump (lanside.cap) is >> > the > >> session between OpenSBC and Callweaver. I am happy to capture and provide >> OpenSBC log and debug if required. >> >> >> >> I'd be interested to know if this is a bug, or otherwise. >> >> >> >> Craig >> >> >> >> >> >> >> >> >> >> >> ------------------------------------------------------------------------ >> >> ------------------------------------------------------------------------- >> 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 >> >> ------------------------------------------------------------------------ >> >> No virus found in this incoming message. >> Checked by AVG Free Edition. >> Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: >> > 9/18/2007 11:53 AM > >> >> > > > ------------------------------------------------------------------------- > 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: Craig G. <cra...@gm...> - 2007-09-19 14:43:39
|
Hmmm, I did definitely include them - and they are attached to the email in my sent items, must have been stripped by Gmail or something. You can download them from http://manky.ath.cx/lanside.cap and http://manky.ath.cx/wanside.cap Craig -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf Of Joegen E. Baclor Sent: Thursday, 20 September 2007 10:35 PM To: ope...@li... Subject: Re: [OpenSIPStack] OpenSBC SIP multipart behaviour Craig, You forgot to attach the pcap files. Joegen Craig Guy wrote: > Hi, > > > > I am currently doing interop testing with Level3 who are a tier 1 VoIP > provider in the USA. The architecture I am using has a single box running > OpenSBC listening on port 5060 and a copy of Callweaver running on port > 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper > registration and is handling both SIP and RTP. > > > > I have found during interop testing that OpenSBC is not preserving the SDP > when initiating the second leg of the call to Callweaver, causing Callweaver > to reject the call with '488 - Not Acceptable Here'. > > > > The difference between the Level3 SIP and other SIP that I've seen is that > Level3 are including multiple parts in the message body. If I take OpenSBC > out of the equation and have Level3 talk directly to my Callweaver then > there is no problem. > > > > I have included two tcpdumps of a session. The first dump, wanside.cap is > the session from Level3 to OpenSBC and the second dump (lanside.cap) is the > session between OpenSBC and Callweaver. I am happy to capture and provide > OpenSBC log and debug if required. > > > > I'd be interested to know if this is a bug, or otherwise. > > > > Craig > > > > > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: 9/18/2007 11:53 AM > ------------------------------------------------------------------------- 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-19 14:35:31
|
Craig, You forgot to attach the pcap files. Joegen Craig Guy wrote: > Hi, > > > > I am currently doing interop testing with Level3 who are a tier 1 VoIP > provider in the USA. The architecture I am using has a single box running > OpenSBC listening on port 5060 and a copy of Callweaver running on port > 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper > registration and is handling both SIP and RTP. > > > > I have found during interop testing that OpenSBC is not preserving the SDP > when initiating the second leg of the call to Callweaver, causing Callweaver > to reject the call with '488 - Not Acceptable Here'. > > > > The difference between the Level3 SIP and other SIP that I've seen is that > Level3 are including multiple parts in the message body. If I take OpenSBC > out of the equation and have Level3 talk directly to my Callweaver then > there is no problem. > > > > I have included two tcpdumps of a session. The first dump, wanside.cap is > the session from Level3 to OpenSBC and the second dump (lanside.cap) is the > session between OpenSBC and Callweaver. I am happy to capture and provide > OpenSBC log and debug if required. > > > > I'd be interested to know if this is a bug, or otherwise. > > > > Craig > > > > > > > > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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 > > ------------------------------------------------------------------------ > > No virus found in this incoming message. > Checked by AVG Free Edition. > Version: 7.5.487 / Virus Database: 269.13.22/1015 - Release Date: 9/18/2007 11:53 AM > |
|
From: Craig G. <cra...@gm...> - 2007-09-19 14:25:39
|
Hi, I am currently doing interop testing with Level3 who are a tier 1 VoIP provider in the USA. The architecture I am using has a single box running OpenSBC listening on port 5060 and a copy of Callweaver running on port 10060 behind OpenSBC. OpenSBC is running in B2BUA mode with upper registration and is handling both SIP and RTP. I have found during interop testing that OpenSBC is not preserving the SDP when initiating the second leg of the call to Callweaver, causing Callweaver to reject the call with '488 - Not Acceptable Here'. The difference between the Level3 SIP and other SIP that I've seen is that Level3 are including multiple parts in the message body. If I take OpenSBC out of the equation and have Level3 talk directly to my Callweaver then there is no problem. I have included two tcpdumps of a session. The first dump, wanside.cap is the session from Level3 to OpenSBC and the second dump (lanside.cap) is the session between OpenSBC and Callweaver. I am happy to capture and provide OpenSBC log and debug if required. I'd be interested to know if this is a bug, or otherwise. Craig |
|
From: Ilian J. C. P. <ip...@so...> - 2007-09-12 07:28:57
|
Hello. I have checked in code for USB phone support. The relevant classes are: HidManager - Manages all HIDs (i.e. USB phones) and sends events to the handlers. HidHandler - Handles/listens for events from HidManager. Override this to provide custom actions in response to events. HidDevice - Override this to implement a USB phone interface. This is where the USB phone SDK code should go. The relevant files are: Hid.cxx/h - base code for USB phone support CmHidDevice.cxx/h - the ATCOM USB phone interface implementation. This is currently implemented in the OSSPhoneSvc project under ATLSIP but it should also be trivial to do the same to OSSPhone .NET and OSSPhone MFC. Will do this later. For now, only ATCOM USB phones are supported. To enable this, you will need to request a copy of the SDK from ATCOM (http://www.atcom.cn/). Then put all relevant files (i.e. cm_hid.*) in the opensipstack/external/hid folder and then do a rebuild. Regards, Ilian |
|
From: Joegen E. B. <joe...@gm...> - 2007-09-12 05:00:29
|
Hi, We appreciate any help we could get from the community in making opensipstack and its application a better software. Joegen Rajpal Dangi wrote: > Joegen, > > > Let me settle down in the forum. Just now I have started evaluating this product and would love to contribute either this unfinished doc stuff or something else. > > > Thanks, > > > /RAj > > > > ------------------------------------------------------------------------- > 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 > > > |
18 messages has been excluded from this view by a project administrator.
