opensipstack-devel Mailing List for OpenSIPStack (Page 20)
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: Gustavo C. <cur...@ho...> - 2008-06-26 13:27:38
|
Hi Joegen
I found something really weird. If I change the order of headers in SIPMessage::Cleanup() the memory leak varies.
For example, if I clean m_AllowList and m_ViaList first of all the memory leak decrease:
void SIPMessage::Cleanup(){ GlobalLock();
if( m_AllowList != NULL ){ delete m_AllowList; m_AllowList = NULL; } /// special headers if( m_ViaList != NULL ){ delete m_ViaList; m_ViaList = NULL; }
.....
I will continue searching. ¿Is there a way to configure PMEMORY_CHECK for release?
Thanks for your help.
Gustavo Curetti
From: cur...@ho...To: jo...@op...; joe...@gm...; ope...@li...Subject: RE: [OpenSIPStack] FW: Memory Leak in Proxy and Full ModeDate: Mon, 23 Jun 2008 21:42:45 +0200
Hi Joegen I think this is a memory leak because after all messages are sent the memory never go down.The code added in B2BUserAgent::Registrar::ProcessUpperRegKeepAlive() waits 5 seconds and sends the first Invite, then waits 5 seconds , sends the second Invite, waits 5 seconds more and finally sends 4998 Invites with a 40 ms delay between each one. void B2BUserAgent::Registrar::ProcessUpperRegKeepAlive(){ DWORD delay = 5000; DWORD numberOfPackets = 0; while( !m_UpperRegSync.Wait( delay ) ) { if(numberOfPackets < 5000) { OString testRequest = "INVITE sip:5435155555@192.168.0.5:5060 SIP/2.0\r\nContact: <sip:4284623@192.168.0.10:5060>\r\nCSeq: 101 INVITE\r\nFrom: <sip:4284623@192.168.0.10>;tag=5A3745C-2418\r\nTo: <sip:55555555@192.168.0.206>\r\nVia: SIP/2.0/UDP 192.168.0.206:5060;branch=z9hG4bK63028de3a6b7743a\r\nVia: SIP/2.0/UDP 192.168.0.10:5060\r\nRecord-Route: <sip:192.168.0.206:5060;lr>\r\nAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO\r\nUser-Agent: Cisco-SIPGateway/IOS-12.x\r\nCall-Id: " + OString(numberOfPackets) + "@192.168.0.10\r\nMax-Forwards: 6\r\nExpires: 180\r\nContent-Length: 235\r\ndate: Thu, 22 May 2008 21:52:32 GMT\r\nsupported: timer\r\nmin-se: 1800\r\ncisco-guid: 926237238-662704605-3106705574-3236916195\r\nremote-party-id: <sip:4284623@192.168.0.10>;party=calling;screen=no;privacy=off\r\ntimestamp: 1211493152\r\nallow-events: telephone-event\r\ncontent-type: application/sdp\r\n\r\nv=0\r\no=CiscoSystemsSIP-GW-UserAgent 7402 717 IN IP4 192.168.0.10\r\ns=SIP Call\r\nc=IN IP4 192.168.0.10\r\nt=0 0\r\nm=audio 19298 RTP/AVP 0 19\r\nc=IN IP4 192.168.0.10\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:19 CN/8000\r\na=ptime:20"; testRequest = ParserTools::LineFeedSanityCheck( testRequest ); SIPMessage * msg = new SIPMessage( testRequest ); OString addrStr = "192.168.0.147"; OString portStr = "10000"; SIPHeader rcvAddr( "RCVADDR", addrStr ); SIPHeader rcvPort( "RCVPORT", portStr ); SIPHeader rcvTran( "RCVTRAN", "udp" ); msg->AddInternalHeader( rcvAddr ); msg->AddInternalHeader( rcvPort ); msg->AddInternalHeader( rcvTran ); msg->SetInterfaceAddress( "192.168.0.202" ); msg->SetInterfacePort( 5070 ); OStringStream traceStream; traceStream << "<<< " << msg->GetStartLine() << " " << " SRC: " << addrStr << ":" << portStr << ":UDP" << " enc=" << msg->IsEncrypted() << " bytes=1103"; OStringStream strPacket; strPacket << *msg; COMPOUND_LOG_CONTEXT( LogInfo(), msg->GetCallId(), traceStream.str(), LogDebugHigh(), strPacket ); SIPTransport::NotifyRead( traceStream.str() ); if( msg->IsInvite() ) { SIPMessage * trying = new SIPMessage(); msg->CreateResponse( *trying, SIPMessage::Code100_Trying ); Via via; msg->GetViaAt(0, via ); if( via.IsBehindNAT() ) { SIPURI srcURI; srcURI.SetHost(addrStr); srcURI.SetPort(portStr); trying->SetSendAddress(srcURI); } if( msg->IsEncrypted() ) trying->SetEncryption( TRUE ); GetTransportManager()->ProcessOutbound( trying ); } GetTransportManager()->OnTransportEvent( new SIPTransportEvent( msg, SIPTransportEvent::UDPPacketArrival ) ); if (numberOfPackets > 1) delay = 40; numberOfPackets++; } }} The SIP timers B and H are set to 20 ms. #define SIP_TIMER_B 20 #define SIP_TIMER_H 20 After all messages are sent, I wait for a long time but the memory used doesn't decrease. I tried different settings: Case 1 5 sec -> 1 Invite -> 5 sec -> 1 Invite -> 5 sec -> 4998 Invite (40 ms) -> 5 min1)Mem Usage 8332k 8940k 9080k 9400k2)Mem Usage 8364k 8952k 8976k 9416k3)Mem Usage 8300k 8888k 8908k 9368k Case 2 5 sec -> 1 Invite -> 5 sec -> 1 Invite -> 5 sec -> 9998 Invite (40 ms) -> 5 min1)Mem Usage 8308k 8900k 9000k 9696k2)Mem Usage 8320k 8908k 8928k 9760k The leak is bigger when the amount of messages are higher.Case 3 5 sec -> 1 Invite -> 5 sec -> 1 Invite -> 5 sec -> 4998 Invite (30 ms) -> 5 min1)Mem Usage 8252k 8832k 8852k 9532k 2)Mem Usage 8256k 8844k 8872k 9536k Case 4 5 sec -> 1 Invite -> 5 sec -> 1 Invite -> 5 sec -> 4998 Invite (20 ms) -> 5 min1)Mem Usage 8276k 8864k 8884k 9728k 2)Mem Usage 8240k 8828k 8848k 9728k The leak is bigger when the delay is shorter. Case 5 5 sec -> 1 Invite -> 5 sec -> 1 Invite -> 5 sec -> 4998 Invite (80 ms) -> 5 min1)Mem Usage 8344k 8932k 8952k 9332k2)Mem Usage 8376k 8968k 8992k 9276k The only type of error in the log is : 102:42:36.691 ERR: [CID=0x0000] UDP Socket Read Error (Socket not connected) in case 1 appears 5219 times. I don't know if this error is linked with the leak. The log is attached. This behavior doesn't seem to be because of transactions waiting for timers. Maybe is because some type of conflict with shared resources or mutexs, but I really don't know. Any idea? If you need more info, please let me know. One more thing, I suggest to increase MAX_SIP_MESSAGE_LENGTH because i had problems with Invites with a lot of headers (record-routes, vias, etc) and long bodies. #define MAX_SIP_MESSAGE_LENGTH 2048 ----> #define MAX_SIP_MESSAGE_LENGTH 4000 Thanks for your help. Gustavo Curetti
> Date: Sat, 21 Jun 2008 10:17:22 +0800> To: cur...@gm...> From: joe...@gm...> CC: joe...@gm...; ope...@li...> Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode> > Hi Gustavo,> > This time, I am not sure if what you are seeing in perfmon is actually a > leak or simply transactions waiting for timers to fire so it could > transition from Completed to Terminated state. I tried to fire the same > in my perfmon and the private mem leveled at around 80 in the graph. > Same place where yours leveled to a straight line. Can you share more > info why you think this is a leak?> > Joegen> > > Gustavo Curetti wrote:> > Hi Joegen,> > > > Another case of memory leak is attached. (no debugging mode).> > I send 5000 messages with 40 ms delay between each message.> > A jpg of the perfmon is attached too. (Private Bytes)> > > > Thanks for your help> >> > Gustavo Curetti> >> >> > ------------------------------------------------------------------------> >> > > Date: Fri, 20 Jun 2008 09:33:12 +0800> > > To: cur...@gm...; ope...@li...> > > From: joe...@gm...> > > CC: joe...@gm...> > > Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode> > >> > > Right! Patch is in CVS.> > >> > > Joegen> > >> > > Gustavo Curetti wrote:> > > > Hi Joegen,> > > >> > > > Thanks for your help. The other header which is missing in the > > SIPMessage::CleanUp() is the m_SessionExpires ("session-expires"). I > > will continue with my tests and let you know.> > > >> > > > Gustavo> > > >> > > >> > > >> > >> > >> > > > > -------------------------------------------------------------------------> > > Check out the new SourceForge.net Marketplace.> > > It's the best place to buy or sell services for> > > just about anything Open Source.> > > http://sourceforge.net/services/buy/index.php> > > _______________________________________________> > > opensipstack-devel mailing list> > > ope...@li...> > > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel> >> >> > ------------------------------------------------------------------------> > ¿Aburrido? Ingresá ya y divertite como nunca en MSN Juegos. MSN Juegos > > <http://juegos.ar.msn.com/>> > ------------------------------------------------------------------------> >> > Internal Virus Database is out-of-date.> > Checked by AVG. > > Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: 5/23/2008 3:36 PM> > > > > > -------------------------------------------------------------------------> Check out the new SourceForge.net Marketplace.> It's the best place to buy or sell services for> just about anything Open Source.> http://sourceforge.net/services/buy/index.php> _______________________________________________> opensipstack-devel mailing list> ope...@li...> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
Descargá GRATIS el poder del nuevo Internet Explorer 7. Internet Explorer 7
_________________________________________________________________
Ingresá ya a MSN en Concierto y disfrutá los recitales en vivo de tus artistas favoritos.
http://msninconcert.msn.com/music/archive/es-la/archive.aspx
|
|
From: <jo...@op...> - 2008-06-26 07:26:20
|
I am going to assume that you sub-classed the CallSession UACore for
your gateway. If this NOT what you did, then you need to give more
info. If this is what you did, all you need to do is to implement the
two blank methods in CallSessionManager.
BOOL CallSessionManager::OnRequireSDPAnswer(
const SIPMessage & offer,
SIPMessage & answer,
CallSession & session
)
{
/// Media UA should implement this method
return FALSE;
}
BOOL CallSessionManager::OnRequireSDPOffer(
SIPMessage & _offer,
CallSession & session
)
{
/// Media UA should implement this method
return FALSE;
}
Lastly, as you can see, the default implementation of the CallSession
does not have RTP.
Joegen
haripriya alapati wrote:
>
> Hi,
>
> I have already DSP and NETWORK modules. Only thing is I have to include the SIP module to my project.
> For Sip parser I am using opensipstack source code. But I am not getting how to separate the sip parser from the rtp and media modules in the opensipsatck code.
> Can anyone please help me regarding this.
>
> Thanks in advance.
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
>
>
|
|
From: haripriya a. <har...@re...> - 2008-06-26 06:07:27
|
Hi, I have already DSP and NETWORK modules. Only thing is I have to include the SIP module to my project. For Sip parser I am using opensipstack source code. But I am not getting how to separate the sip parser from the rtp and media modules in the opensipsatck code. Can anyone please help me regarding this. Thanks in advance. |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-25 02:02:14
|
I would be happy to accept the sample application as third party contribution to ATLSIP as long as the contributors are willing to support it in the mailing list. I've been thinking along the line of C#, VB.NET and Delphi.
Joegen
> {quote:title=optotronic wrote:}{quote}
> Robert,
>
> Yes, I'll take a peek at your code. Maybe we can publish a summary if we find anything that may help other Delphi users of OpenSipStack/ATLSIP.
>
> You could send it via private message on the OpenSourceSIP forum. I was going to private message you my email address, but you're on as Guest.
>
> Finest regards,
> Bill
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-24 19:36:13
|
Robert, Yes, I'll take a peek at your code. Maybe we can publish a summary if we find anything that may help other Delphi users of OpenSipStack/ATLSIP. You could send it via private message on the OpenSourceSIP forum. I was going to private message you my email address, but you're on as Guest. Finest regards, Bill |
|
From: Robert V. <ro...@dc...> - 2008-06-24 12:50:35
|
Bill,
Is there any chance I could perhaps mail you my code, so you could tell me
if I am doing anything horribly wrong? It's just a form with buttons for
Initilize, Register, Call, Answer and Hangup (Plus a couple of events,
allthough I am still getting exceptions when I comment them out)
Regards,
Robert
----- Original Message -----
From: "OpenSIPStack Forum" <ope...@op...>
To: <ope...@li...>
Sent: Saturday, June 21, 2008 12:05 AM
Subject: Re: [OpenSIPStack] Unhandled exception
> Robert,
>
> I am also trying to use ATLSIP.dll from Delphi. For me so far, I only
> seem to get exceptions during shutdown. I haven't been able to track the
> problem down yet.
>
> I'm not a .NET programmer, but I've been assuming that OSSPhone is using
> ATLSIP.dll through AxATLSIPLib.dll, as Joegen suggests. ASTLSIP.dll is
> native code, but OSSPhone is .NET.
>
> If there was a non-.NET version of OSSPhone using ATLSIP.DLL, debugging
> would be easier. There is an MFC version of OSSPhone, but it appears to
> use OpenSipStack directly.
>
> One thing to remember is that OpenSipStack uses a lot of threads. Your
> code needs to be aware of this when implementing ATLSIP event handlers,
> since they will be executed (I believe) from a thread other than the main
> VCL thread. Thus accessing VCL controls directly won't work properly.
> You should also protect non-local variables using multithreading
> mechanisms (critical sections, mutexes, Windows events, etc.)
>
> Finest regards,
> Bill Root
>
> {quote}I am using the ATLSIP.dll generated by the ATLSIP project to write
> a
> softphone (in Delphi). The phone works fine, except that it throws
> unhandled exceptions at seemingly random times. I don't get these problems
> when running OSSPhone. I noticed that OSSPhone uses
> AxInterop.ATLSIPLib.1.0.dll and not ATLSIP.dll. Is there a difference
> between the dll's?
>
>
> Regards,
>
> Robert{quote}
>
> -------------------------------------------------------------------------
> Check out the new SourceForge.net Marketplace.
> It's the best place to buy or sell services for
> just about anything Open Source.
> http://sourceforge.net/services/buy/index.php
> _______________________________________________
> opensipstack-devel mailing list
> ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-23 19:38:34
|
Hello Joegen, it works now, many thanks. A little Trim() makes sometimes a big difference... I need to spend a little bit more time reading the source code to get a better understanding. Many thanks again for the great help. Regards, Andre |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-23 18:36:19
|
Don't give up just yet. I think your server is re-encoding the Via in the response and adding an extra space after SIP/2.0/UDP. I have applied a patch that would handle this behavior. Try the latet from CVS and let me know how it goes.
Joegen
> {quote:title=cam100 wrote:}{quote}
>
> Hello Joegen,
>
>
> I'm close to give up on that... I have been debugging a lot of things so far - but there is no true result. The only thing I have found is the following:
>
> The via.GetUri() is called I see a strange behavior when we are parsing the via: headers. I added some debugs in order to find out what it causes:
>
>
> 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI Part 1:
> 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI Part 2, after GetAddress() sip: 85.xx.x.200
> 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI: sip: 85.xx.x.200:5060
>
> As you can see, we have a space between sip: and the IP Address. What is your opinion ? Can that be the root cause ? I tried to find out where the sip: is added but were unable to. Can you please give me a hint ? Does it make sense to send you a complete SIP trace off list ? Many thanks for your help in advance.
>
>
> Regards,
>
>
> Andre
>
>
>
>
>
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-23 16:12:14
|
Hello Joegen, I'm close to give up on that... I have been debugging a lot of things so far - but there is no true result. The only thing I have found is the following: The via.GetUri() is called I see a strange behavior when we are parsing the via: headers. I added some debugs in order to find out what it causes: 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI Part 1: 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI Part 2, after GetAddress() sip: 85.xx.x.200 337287:45:59.687 PWL: [CID=0x0000] show uri in via.GetURI: sip: 85.xx.x.200:5060 As you can see, we have a space between sip: and the IP Address. What is your opinion ? Can that be the root cause ? I tried to find out where the sip: is added but were unable to. Can you please give me a hint ? Does it make sense to send you a complete SIP trace off list ? Many thanks for your help in advance. Regards, Andre |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-21 08:43:32
|
Robert,
I am also trying to use ATLSIP.dll from Delphi. For me so far, I only seem to get exceptions during shutdown. I haven't been able to track the problem down yet.
I'm not a .NET programmer, but I've been assuming that OSSPhone is using ATLSIP.dll through AxATLSIPLib.dll, as Joegen suggests. ASTLSIP.dll is native code, but OSSPhone is .NET.
If there was a non-.NET version of OSSPhone using ATLSIP.DLL, debugging would be easier. There is an MFC version of OSSPhone, but it appears to use OpenSipStack directly.
One thing to remember is that OpenSipStack uses a lot of threads. Your code needs to be aware of this when implementing ATLSIP event handlers, since they will be executed (I believe) from a thread other than the main VCL thread. Thus accessing VCL controls directly won't work properly. You should also protect non-local variables using multithreading mechanisms (critical sections, mutexes, Windows events, etc.)
Finest regards,
Bill Root
{quote}I am using the ATLSIP.dll generated by the ATLSIP project to write a
softphone (in Delphi). The phone works fine, except that it throws
unhandled exceptions at seemingly random times. I don't get these problems
when running OSSPhone. I noticed that OSSPhone uses
AxInterop.ATLSIPLib.1.0.dll and not ATLSIP.dll. Is there a difference
between the dll's?
Regards,
Robert{quote}
|
|
From: <jo...@op...> - 2008-06-21 03:57:44
|
Hi Gustavo,
This time, I am not sure if what you are seeing in perfmon is actually a
leak or simply transactions waiting for timers to fire so it could
transition from Completed to Terminated state. I tried to fire the same
in my perfmon and the private mem leveled at around 80 in the graph.
Same place where yours leveled to a straight line. Can you share more
info why you think this is a leak?
Joegen
Gustavo Curetti wrote:
> Hi Joegen,
>
> Another case of memory leak is attached. (no debugging mode).
> I send 5000 messages with 40 ms delay between each message.
> A jpg of the perfmon is attached too. (Private Bytes)
>
> Thanks for your help
>
> Gustavo Curetti
>
>
> ------------------------------------------------------------------------
>
> > Date: Fri, 20 Jun 2008 09:33:12 +0800
> > To: cur...@gm...; ope...@li...
> > From: joe...@gm...
> > CC: joe...@gm...
> > Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode
> >
> > Right! Patch is in CVS.
> >
> > Joegen
> >
> > Gustavo Curetti wrote:
> > > Hi Joegen,
> > >
> > > Thanks for your help. The other header which is missing in the
> SIPMessage::CleanUp() is the m_SessionExpires ("session-expires"). I
> will continue with my tests and let you know.
> > >
> > > Gustavo
> > >
> > >
> > >
> >
> >
> >
> -------------------------------------------------------------------------
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://sourceforge.net/services/buy/index.php
> > _______________________________________________
> > opensipstack-devel mailing list
> > ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel
>
>
> ------------------------------------------------------------------------
> ¿Aburrido? Ingresá ya y divertite como nunca en MSN Juegos. MSN Juegos
> <http://juegos.ar.msn.com/>
> ------------------------------------------------------------------------
>
> Internal Virus Database is out-of-date.
> Checked by AVG.
> Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: 5/23/2008 3:36 PM
>
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 05:16:58
|
Thanks for the help! |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 05:08:44
|
It should be something like below:
INVITE sip:1518421590@204.13.7.33:5066 SIP/2.0 <----------------- CONTACT you sent in your REGISTER request (Binding)
From: <sip:121...@di...>;tag=920ef16ccc3cdd119562d496dbc76295
To: sip:151...@di... <------------------------ or To-URI you sent in REGISTER (Address of Record)
> {quote:title=illizit wrote:}{quote}
>
> Hmm. ok.
>
>
> Thanks for the help! Sorry to keep bothering however, what exactly should the provider be sending?
>
>
> Here is my SIP Register packet to the provider:
>
>
> 204.13.X.XX:5066 -> 64.34.181.47:5060
> REGISTER sip:did.voip.les.net SIP/2.0..
> From: <sip:151...@di...>;tag=920ef16ccc3cdd119562d496dbc76295..
> To: sip:151...@di.....Via: SIP/2.0/UDP 204.13.7.33:5066;iid=9578;branch=z9hG4bKa6d1f36fcc3cdd119562d496dbc76295;uas-addr=64.34.181.47;rport..CSeq: 2 REGISTER..
> Call-ID:[1c1...@di...]..
> Contact: <sip:1518421590@204.13.7.33:5066;transport=udp>..
> User-Agent: ..Expires: 3600..Max-Forwards: 70..Authorization: Digest username="1518421590", realm="did.voip.les.net", nonce="3b131f7f", uri="sip:did.voip.les.net", response="e62e92397699
> 10e84475b05d72ac35e6", opaque="", algorithm=MD5..Allow: INVITE, BYE, ACK, R
> EFER, MESSAGE, INFO, NOTIFY, OPTIONS, PRACK..Content-Length: 0....
> #
>
>
>
>
>
> According to my register packet, what should the provider be sending me?
>
>
> Thanks
>
>
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 04:37:03
|
Hmm. ok. Thanks for the help! Sorry to keep bothering however, what exactly should the provider be sending? Here is my SIP Register packet to the provider: 204.13.X.XX:5066 -> 64.34.181.47:5060 REGISTER sip:did.voip.les.net SIP/2.0.. From: <sip:151...@di...>;tag=920ef16ccc3cdd119562d496dbc76295.. To: sip:151...@di.....Via: SIP/2.0/UDP 204.13.7.33:5066;iid=9578;branch=z9hG4bKa6d1f36fcc3cdd119562d496dbc76295;uas-addr=64.34.181.47;rport..CSeq: 2 REGISTER.. Call-ID:[1c1...@di...].. Contact: <sip:1518421590@204.13.7.33:5066;transport=udp>.. User-Agent: ..Expires: 3600..Max-Forwards: 70..Authorization: Digest username="1518421590", realm="did.voip.les.net", nonce="3b131f7f", uri="sip:did.voip.les.net", response="e62e92397699 10e84475b05d72ac35e6", opaque="", algorithm=MD5..Allow: INVITE, BYE, ACK, R EFER, MESSAGE, INFO, NOTIFY, OPTIONS, PRACK..Content-Length: 0.... # According to my register packet, what should the provider be sending me? Thanks |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 04:03:03
|
> {quote:title=illizit wrote:}{quote}
> Is there a specific reason why it works like this?
>
RFC 3261
10.3 Processing REGISTER Requests
5. The registrar extracts the address-of-record from the To header
field of the request. If the address-of-record is not valid
for the domain in the Request-URI, the registrar MUST send a
404 (Not Found) response and skip the remaining steps. The URI
MUST then be converted to a canonical form. To do that, all
URI parameters MUST be removed (including the user-param), and
any escaped characters MUST be converted to their unescaped
form. The result serves as an index into the list of bindings
I simply mean your provider is not sending the correct AOR it got from the REGISTER request. And that correct AOR processing is vital for OSBC SIP Trunking operation.
> If not, do you know which part of the code this sip trunking is in so I can modify it? According to this website, the from tag in a sip packet should say where the call originated from and the to tag should be the uri of where it is going.
>
>
See:
B2BUAConnection * SBCSIPTrunkEndPoint::OnCreateB2BUA(
const SIPMessage & request,
const OString & sessionId,
B2BUACall * /*call*/
)
Feel free to send in patches.
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 03:43:23
|
Is there a specific reason why it works like this? If not, do you know which part of the code this sip trunking is in so I can modify it? According to this website, the from tag in a sip packet should say where the call originated from and the to tag should be the uri of where it is going. [http://www.tech-invite.com/Ti-sip-dialog.html#inv] |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 02:57:50
|
Let us say your REGISTER to your provider looks like this
REGISTER sip:11...@pr... SIP/2.0
To: sip:11...@yo...;tag=12345
From: sip:11...@yo...
Contact: sip:1111@10.0.0.1:5066
then your provider should send the INVITE as follows
INVITE sip:1111@10.0.0.1:5066 SIP/2.0
To: sip:11...@yo...;tag=6789
From: sip:com...@yo...
This is simply how it works now in OSBC SIP Trunking. OpenSBC will take the domain from the To-URI and match it to the trunk you specified in the XML config.
> {quote:title=illizit wrote:}{quote}
>
> All three providers (including gafachi) use this standard. Are you telling me it's not compatible?
>
>
> The TO field, I thought, was supposed to be used for the number that was dialed.
>
>
> For instance, if I call from my cell phone 55555 to the number 88888, then TO should be: TO:[88...@op...] and FROM should be: FROM:[55...@yo...]
|
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 02:03:04
|
All three providers (including gafachi) use this standard. Are you telling me it's not compatible? The TO field, I thought, was supposed to be used for the number that was dialed. For instance, if I call from my cell phone 55555 to the number 88888, then TO should be: TO:[88...@op...] and FROM should be: FROM:[55...@yo...] |
|
From: Joegen E. B. <joe...@gm...> - 2008-06-20 01:33:21
|
Right! Patch is in CVS.
Joegen
Gustavo Curetti wrote:
> Hi Joegen,
>
> Thanks for your help. The other header which is missing in the SIPMessage::CleanUp() is the m_SessionExpires ("session-expires"). I will continue with my tests and let you know.
>
> Gustavo
>
>
>
|
|
From: Joegen E. B. <joe...@gm...> - 2008-06-20 01:25:30
|
Hi Robert, To be honest, I created OSSPhone reference implementation in .NET C++ CLI by getting a book from the local book store. There is no way for me to answer your question authoritatively because I might be as lost as you are in this. My guess is AxInterop.ATLSIPLib.1.0.dll is a proxy DLL that exposes the native COM DLL (ATLSIP) to the .NET framework. I've got absolutely zero knowledge of Delphi so I wont even try giving my opinion. Joegen Robert Vos wrote: > Hi, > > > > I am using the ATLSIP.dll generated by the ATLSIP project to write a > softphone (in Delphi). The phone works fine, except that it throws > unhandled exceptions at seemingly random times. I don't get these problems > when running OSSPhone. I noticed that OSSPhone uses > AxInterop.ATLSIPLib.1.0.dll and not ATLSIP.dll. Is there a difference > between the dll's? > > > > Regards, > > Robert > > > ------------------------------------------------------------------------- > Check out the new SourceForge.net Marketplace. > It's the best place to buy or sell services for > just about anything Open Source. > http://sourceforge.net/services/buy/index.php > _______________________________________________ > opensipstack-devel mailing list > ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel > > > |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-20 01:11:46
|
It won't work for this INVITE. SIPTrunks are identified through their domains. In your previous post you indicated that the domain is sip-domain="did.les.net". This should be the same domain that your provider should use in the TO-URI for inbound calls. Instead they sent sip:78621XXXX@204.13.XX.XX:5066 which is obviously the contact address. Joegen > {quote:title=illizit wrote:}{quote} > > Hello. > > > I finally got my trunks to register. This issue I currently have is when a incoming call is received opensbc replies back with Internal Server Error 500. > > > Here is the invite: > > > > U 64.34.181.47:5060 -> 204.13.XX.XX:5066 > INVITE sip:78621XXX@204.13.XX.XX:5066 SIP/2.0 > Via: SIP/2.0/UDP 64.34.181.47:5060;branch=z9hG4bK68d77e9c;rport > From: "NOT FOUND" <sip:13052XXXXX@64.34.181.47>;tag=as1941af79 > To: <sip:78621XXXX@204.13.XX.XX:5066> > Contact: <sip:130529XXX@64.34.181.47> > Call-ID: 046e8d7b24d7315c5074495a46fb29ba@64.34.181.47 > CSeq: 102 INVITE > User-Agent: LES.NET.VoIP > Max-Forwards: 70 > Date: Thu, 19 Jun 2008 07:30:16 GMT > Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY > Content-Type: application/sdp > Content-Length: 317 > > > > > > > > > Then opensbc responds back with: > > > > U 204.13.XX.XX:5066 -> 64.34.181.47:5060 > SIP/2.0 500 Internal Server Error > From: "NOT FOUND" <sip:1305XXXXXX@64.34.181.47>;tag=as1941af79 > To: <sip:7862XXXXX@204.13.XX.XX:5066>;tag=c298d0d21d3cdd119638a704fbd83836 > Via: SIP/2.0/UDP 64.34.181.47:5060;branch=z9hG4bK68d77e9c;rport=5060;received=64.34.181.47 > CSeq: 102 INVITE > Call-ID: 046e8d7b24d7315c5074495a46fb29ba@64.34.181.47 > Content-Length: 0 > > > > > > In my trunk configuration I have inbound route=sip:XX...@si... (which is a registered UA on the same server) > > > The URI the provider sends is the exact URI in my configuration. I have restarted multiple times to no avail :( > > > Any help is appreciated! > > > Thanks > > |
|
From: Gustavo C. <cur...@ho...> - 2008-06-19 13:41:31
|
Hi Joegen,
Thanks for your help. The other header which is missing in the SIPMessage::CleanUp() is the m_SessionExpires ("session-expires"). I will continue with my tests and let you know.
Gustavo
> Date: Thu, 19 Jun 2008 08:38:42 +0800> From: joe...@gm...> To: cur...@gm...> CC: jo...@op...; ope...@li...; jb...@so...> Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode> > Right! I've found m_MinSE is not getting deleted in > SIPMessage::CleanUp(). Patched this in CVS.> > Joegen> > Gustavo Curetti wrote:> > Hi Joegen> > > > The modification doesn't solve the memory issues. I continue searching > > for the memory leak. > > > > A new case is attached and this one appear too when debugging with > > Microsot Visual.> > > > Originally, i sent the attached Invite every 250 ms and I set the > > timer B and H in 20 ms:> > > > #define SIP_TIMER_B 20> > > > #define SIP_TIMER_H 20> > > > Then I change the code > > of B2BUserAgent::Registrar::ProcessUpperRegKeepAlive() > > for making easier to replicate the leak:> > > > > > void B2BUserAgent::Registrar::ProcessUpperRegKeepAlive()> > {> > while( !m_UpperRegSync.Wait( 250 ) )> > {> > OString testRequest => > "INVITE sip:5435155555@192.168.0.5:5060 SIP/2.0\r\nContact: > > <sip:4284623@192.168.0.10:5060>\r\nCSeq: 101 INVITE\r\nFrom: > > <sip:4284623@192.168.0.10>;tag=5A3745C-2418\r\nTo: > > <sip:55555555@192.168.0.206>\r\nVia: SIP/2.0/UDP > > 192.168.0.206:5060;branch=z9hG4bK63028de3a6b7743a\r\nVia: SIP/2.0/UDP > > 192.168.0.10:5060\r\nRecord-Route: > > <sip:192.168.0.206:5060;lr>\r\nAllow: INVITE, OPTIONS, BYE, CANCEL, > > ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO\r\nUser-Agent: > > Cisco-SIPGateway/IOS-12.x\r\nCall-Id: > > 3738EB25-278011DD-B92F90A6-C0EF6BE3@192.168.0.10\r\nMax-Forwards > > <mailto:3738EB25-278011DD-B92F90A6-C0EF6BE3@192.168.0.10%5Cr%5CnMax-Forwards>: > > 6\r\nExpires: 180\r\nContent-Length: 235\r\ndate: Thu, 22 May 2008 > > 21:52:32 GMT\r\nsupported: timer\r\nmin-se: 1800\r\ncisco-guid: > > 926237238-662704605-3106705574-3236916195\r\nremote-party-id: > > <sip:4284623@192.168.0.10>;party=calling;screen=no;privacy=off\r\ntimestamp: > > 1211493152\r\nallow-events: telephone-event\r\ncontent-type: > > application/sdp\r\n\r\nv=0\r\no=CiscoSystemsSIP-GW-UserAgent 7402 717 > > IN IP4 192.168.0.10\r\ns=SIP Call\r\nc=IN IP4 192.168.0.10\r\nt=0 > > 0\r\nm=audio 19298 RTP/AVP 0 19\r\nc=IN IP4 192.168.0.10\r\na=rtpmap:0 > > PCMU/8000\r\na=rtpmap:19 CN/8000\r\na=ptime:20";> > testRequest = ParserTools::LineFeedSanityCheck( testRequest );> > SIPMessage * msg = new SIPMessage( testRequest );> > > > OString addrStr = "192.168.0.147";> > OString portStr = "10000";> > SIPHeader rcvAddr( "RCVADDR", addrStr );> > SIPHeader rcvPort( "RCVPORT", portStr );> > SIPHeader rcvTran( "RCVTRAN", "udp" );> > > > msg->AddInternalHeader( rcvAddr );> > msg->AddInternalHeader( rcvPort );> > msg->AddInternalHeader( rcvTran );> > msg->SetInterfaceAddress( "192.168.0.202" );> > msg->SetInterfacePort( 5070 );> > > > OStringStream traceStream;> > > > traceStream << "<<< "> > << msg->GetStartLine() << " "> > << " SRC: " << addrStr << ":" << portStr << ":UDP"> > << " enc=" << msg->IsEncrypted()> > << " bytes=1103";> > > > OStringStream strPacket;> > strPacket << *msg;> > COMPOUND_LOG_CONTEXT( LogInfo(), msg->GetCallId(), > > traceStream.str(), LogDebugHigh(), strPacket );> > > > SIPTransport::NotifyRead( traceStream.str() );> > > > if( msg->IsInvite() )> > {> > SIPMessage * trying = new SIPMessage();> > msg->CreateResponse( *trying, SIPMessage::Code100_Trying );> > Via via;> > msg->GetViaAt(0, via );> > if( via.IsBehindNAT() )> > {> > SIPURI srcURI;> > srcURI.SetHost(addrStr);> > srcURI.SetPort(portStr);> > trying->SetSendAddress(srcURI);> > }> > if( msg->IsEncrypted() )> > trying->SetEncryption( TRUE );> > GetTransportManager()->ProcessOutbound( trying );> > }> > > > GetTransportManager()->OnTransportEvent(> > new SIPTransportEvent(> > msg,> > SIPTransportEvent::UDPPacketArrival> > ) );> >> > /*///process the keep alives here> > for( PINDEX i = 0; i < GetRegistrationDB().GetSize(); i++ )> > {> > SIPMessage reg;> > if( GetRegistrationDB().GetRegistration( i, reg ) )> > {> > if( reg.HasInternalHeader( "upper-reg" ) )> > {> > /// this is an upper reg, send a keep-alive> > /// Check the last via if its from a private IP> > Via via;> > if( reg.GetViaAt( reg.GetViaSize() - 1, via ) )> > {> > if( via.IsBehindNAT() )> > {> > SIPURI target;> > target.SetHost( via.GetReceiveAddress().AsSTLString() );> > target.SetPort( via.GetRPort() );> > SIPMessage keepAlive;> > RequestLine requestLine;> > requestLine.SetMethod( "KEEP-ALIVE" );> > requestLine.SetRequestURI( target );> > keepAlive.SetStartLine( requestLine );> > GetUserAgent().TransportWrite( keepAlive );> > }> > }> > }> > }> > }*/> > }> > }> >> > > > The OpenSBC is in "Proxy Only Mode" and the configuration is in > > "OpenSBC.reg" (attached).> > > > I compile the OpenSBC in Microsoft Visual C++ 2005 obtaining the exe > > attached.> > > > Any idea?> > > > Thanks for your help.> > > > Gustavo> >> >> >> > ------------------------------------------------------------------------> >> > > Date: Thu, 5 Jun 2008 14:18:35 +0800> > > To: cur...@gm...> > > Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode> > > From: joe...@gm...> > >> > > Hi Gustavo,> > >> > > Yes, i'm able to replicate it. For some reason, the code I #ifdefed in> > > AppendVia() below is causing it. Let me know if it solves your issues.> > > I've tried looking at what its doing but nothing is evident as to > > why it> > > would leak. If you find something, let me know> > >> > > Joegen> > >> > > BOOL SIPMessage::AppendVia(> > > const Via & header> > > )> > > {> > > GlobalLock();> > >> > > ParseViaList();> > >> > > if( m_ViaList == NULL )> > > {> > > m_ViaList = new Via::Collection();> > > m_ViaList->Append( new Via( header ) );> > > }else> > > {> > >> > > #if 0 // For some reason, this sanity check is leaking mem> > > /// sanity check> > > if( m_ViaList->GetSize() > 0 )> > > {> > > Via & topVia = (*m_ViaList)[0];> > >> > > SIPURI topViaURI = topVia.GetURI();> > >> > > SIPURI newURI = header.GetURI();> > >> > > if( SIPTransport::IsTheSameAddress( topViaURI, newURI, TRUE ) )> > > return FALSE;> > > }> > > #endif> > >> > > ///we append it on top> > > Via::Collection oldViaList = *m_ViaList;> > > oldViaList.MakeUnique();> > > delete m_ViaList;> > >> > > m_ViaList = new Via::Collection();> > > m_ViaList->Append( new Via( header ) );> > >> > > for( PINDEX i = 0; i < oldViaList.GetSize(); i++ )> > > m_ViaList->Append( new Via( oldViaList[i] ) );> > >> > > m_ViaList->MakeUnique();> > > }> > >> > >> > > return TRUE;> > > }> > >> > >> > > Gustavo Curetti wrote:> > > >> > > > Hi Joegen> > > >> > > > The destructor is called. The problem seem to be the headers like > > Via,> > > > RecordRoute, Contact, Allow, Supported (List headers).> > > >> > > > The leak is very easy to reproduce. I change the code of> > > > B2BUserAgent::Registrar::ProcessUpperRegKeepAlive:> > > >> > > >> > > > void B2BUserAgent::Registrar::ProcessUpperRegKeepAlive()> > > > {> > > > while( !m_UpperRegSync.Wait( 10 ) )> > > > {> > > >> > > > SIPMessage * msg = new SIPMessage();> > > >> > > > msg->AppendVia(Via("SIP/2.0/UDP 192.168.0.10:5060"));> > > > msg->AppendVia(Via("SIP/2.0/UDP> > > > > > 192.168.0.206:5060;branch=z9hG4bK440fdc3e04de9d10;rport=5060;received=192.168.0.206"));> > > > msg->AppendRecordRoute(RouteURI("<sip:192.168.0.206:5060;lr>"));> > > > msg->AppendContact(ContactURI("<sip:5435155555@192.168.0.5>"));> > > > msg->AppendAllow(Allow("INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,> > > > SUBSCRIBE, NOTIFY"));> > > > msg->AppendSupported(Supported("replaces"));> > > >> > > > delete msg;> > > > }> > > > }> > > >> > > >> > > > I compile the OpenSBC in Microsoft Visual C++ 2005 obtaining the exe> > > > attached.> > > > I execute "OpenSBC Debug" in Windows 2003 or Windows 2000 and the > > leak> > > > is there.> > > >> > > > I put traces and SIPMessage::~SIPMessage(), SIPMessage::Cleanup() are> > > > called.> > > >> > > > Any idea?> > > >> > > > Thanks for your help.> > > >> > > > Gustavo> > > >> > > > > > ------------------------------------------------------------------------> > > >> > > > > Date: Mon, 2 Jun 2008 10:19:08 +0800> > > > > To: cur...@gm...; > > ope...@li...> > > > > From: joe...@gm...> > > > > Subject: Re: [OpenSIPStack] FW: Memory Leak in Proxy and Full Mode> > > > >> > > > > Try putting a trace before and after the "delete" statement to > > be sure> > > > > that its getting called. From what i see, assuming that SIPMessage> > > > > destructor performs proper cleanup, that a leak here can only be > > caused> > > > > by an exception occurring in the SIPMessage constructor;> > > > >> > > > > Gustavo Curetti wrote:> > > > > > Hi Joegen:> > > > > >> > > > > > The memory leak is hard to find. I send the 200 OK repeatedly but> > > > the memory leak doesn't appear if i'm debugging with Microsot Visual> > > > 2005, but the leak appears if i'm running the OpenSBC like a service.> > > > > >> > > > > > If I comment:> > > > > >> > > > > >> > > > > > void SIPStack::EnqueueTransportWriteEvent(> > > > > > const SIPMessage & message,> > > > > > SIPTransportEvent::Type eventType> > > > > > )> > > > > > {> > > > > > if( m_IsTerminating )> > > > > > return;> > > > > >> > > > > > /*SIPMessage * msg = new SIPMessage(message);> > > > > >> > > > > > msg->SetInternalHeader( "TRN-ID", > > msg->GetTransactionId().AsString());> > > > > > m_TransportManager->EnqueueEvent( new SIPTransportEvent( msg,> > > > eventType ) );*/> > > > > > }> > > > > >> > > > > > there is not leak. But if I modify the code like this:> > > > > >> > > > > >> > > > > > void SIPStack::EnqueueTransportWriteEvent(> > >> > > > > > const SIPMessage & message,> > > > > > SIPTransportEvent::Type eventType> > > > > > )> > > > > > {> > > > > > if( m_IsTerminating )> > > > > > return;> > > > > >> > > > > > SIPMessage * msg = new SIPMessage(message);> > > > > >> > > > > > /*msg->SetInternalHeader( "TRN-ID",> > > > msg->GetTransactionId().AsString());> > > > > > m_TransportManager->EnqueueEvent( new SIPTransportEvent( msg,> > > > eventType ) );*/> > > > > > delete msg;> > > > > > }> > > > > >> > > > > > the leak shows up. I don't understand why this happens if I'm> > > > deleting the msg.> > > > > > What i said in the last mail about CSeq is not seem to be the > > reason.> > > > > > Any idea? Thanks for your help.> > > > > > Gustavo> > > > > >> > > > > >> > > > > > From: cur...@ho...Subject: RE: [OpenSIPStack]> > > > Memory Leak in Proxy and Full ModeDate: Fri, 30 May 2008 17:04:37 > > +0200> > > > > >> > > > > >> > > > > > Hi Joegen: I found that the memory leak is when you create a> > > > SIPMessage from other SIPMessage or from a OString and then you > > delete> > > > de message. In the case of the 200 Ok the message is created in:> > > > > > ProxySessionManager::OnOrphanedMessage()SIPUserAgent::TransportWrite()SIPStack::EnqueueTransportWriteEvent(){SIPMessage > >> > > > * msg = new SIPMessage(message); The memory leak is because the CSeq> > > > header. If i comment : SIPMessage::SIPMessage(const SIPMessage &> > > > msg)SIPMessage & SIPMessage::operator=(const SIPMessage & msg)void> > > > SIPMessage::AssignContents(SIPMessage & msg){ /*if( m_CSeq != NULL )> > > > msg.m_CSeq = static_cast<CSeq*>(m_CSeq->Clone());*/} There is no more> > > > memory leak. I try to replace: SIPMessage * msg = new> > > > SIPMessage(message); ----> SIPMessage * msg = new> > > > SIPMessage(message.AsString()); but the memory leak still exist > > unless> > > > i comment: void SIPMessage::Finalize(){ /*if( m_CSeq == NULL ) {> > > > m_CSeq = new CSeq( h ); }*/} That's what i found so far. Gustavo> > > > > >> > > > > >> > > > > >> Date: Fri, 30 May 2008 11:26:11 +0800> To:> > > > cur...@gm...; ope...@li...>> > > > Subject: Re: [OpenSIPStack] Memory Leak in Proxy and Full Mode> From:> > > > joe...@gm...> > Hi Gustavo,> > Take a look at void> > > > ProxySession::OnFinalResponse( SIPMessage & message > ) method. Can> > > > you verify if the object created in:> > manager.CreateTuple(> > > > m_OriginalInvite, m_RoutedInvite, 10 );> > Actually expires after 10> > > > seconds?> > Putting a breakpoint at> > > > ProxySessionTupleManager::Tuple::~Tuple() should > be enough to> > > > confirm it.> > Also by any chance, did you accidentally think that> > > > this tuple is the > mem leak because it was created after the> > > > transaction?> > Joegen> > > Gustavo Curetti wrote:> > Hi Joegen> > > > > >> > > > I found a memory leak when the OpenSBC is configured in Proxy or Full> > > > mode. When i send a 200 Ok for example in B2B mode there is no memory> > > > leak, but when i send a 200 ok in Proxy or Full mode, some memory is> > > > taken and never released. I attach the logs. The OpenSBC> > > > (192.168.0.202:5070) is running under Windows.> > > > Thanks for your> > > > help> > > > Gustavo> >> > > > _________________________________________________________________> >> > > > Ingresá ya a MSN Deportes y enterate de las últimas novedades del> > > > mundo deportivo.> > http://msn.foxsports.com/fslasc/> >> > > > > > ------------------------------------------------------------------------>> > > > >> >> > > > > > -------------------------------------------------------------------------> > >> > > > > This SF.net email is sponsored by: Microsoft> > Defy all > > challenges.> > > > Microsoft(R) Visual Studio 2008.> >> > > > 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. > >> > > > Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date:> > > > 5/23/2008 3:36 PM> > > >> > > > > >>> > > > > >> > > > > > Ingresá ya a MSN en Concierto y disfrutá los recitales en vivo de> > > > tus artistas favoritos. MSN en Concierto> > > > > > _________________________________________________________________> > > > > > Descargá ya gratis y viví la experiencia Windows Live.> > > > > > http://www.descubrewindowslive.com/latam/index.html> > > > > >> > > > > > -------------------------------------------------------------------------> > > > > > This SF.net email is sponsored by: Microsoft> > > > > > Defy all challenges. Microsoft(R) Visual Studio 2008.> > > > > > 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 2008.> > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/> > > > > _______________________________________________> > > > > opensipstack-devel mailing list> > > > > ope...@li...> > > > > https://lists.sourceforge.net/lists/listinfo/opensipstack-devel> > > >> > > >> > > > > > ------------------------------------------------------------------------> > > > Descargá ya gratis y viví la experiencia Windows Live. Descubre> > > > Windows Live <http://www.descubrewindowslive.com/latam/index.html>> > > > > > ------------------------------------------------------------------------> > > >> > > > Internal Virus Database is out-of-date.> > > > Checked by AVG.> > > > Version: 7.5.524 / Virus Database: 269.24.1/1463 - Release Date: > > 5/23/2008 3:36 PM> > > >> > >> > >> >> >> > ------------------------------------------------------------------------> > Ingresá ya a MSN Deportes y enterate de las últimas novedades del > > mundo deportivo. MSN Deportes <http://msn.foxsports.com/fslasc/>> >
_________________________________________________________________
Ingresá ya a MSN Deportes y enterate de las últimas novedades del mundo deportivo.
http://msn.foxsports.com/fslasc/
|
|
From: Robert V. <ro...@dc...> - 2008-06-19 09:55:50
|
Hi, I am using the ATLSIP.dll generated by the ATLSIP project to write a softphone (in Delphi). The phone works fine, except that it throws unhandled exceptions at seemingly random times. I don't get these problems when running OSSPhone. I noticed that OSSPhone uses AxInterop.ATLSIPLib.1.0.dll and not ATLSIP.dll. Is there a difference between the dll's? Regards, Robert |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-19 07:35:45
|
Hello. I finally got my trunks to register. This issue I currently have is when a incoming call is received opensbc replies back with Internal Server Error 500. Here is the invite: U 64.34.181.47:5060 -> 204.13.XX.XX:5066 INVITE sip:78621XXX@204.13.XX.XX:5066 SIP/2.0 Via: SIP/2.0/UDP 64.34.181.47:5060;branch=z9hG4bK68d77e9c;rport From: "NOT FOUND" <sip:13052XXXXX@64.34.181.47>;tag=as1941af79 To: <sip:78621XXXX@204.13.XX.XX:5066> Contact: <sip:130529XXX@64.34.181.47> Call-ID: 046e8d7b24d7315c5074495a46fb29ba@64.34.181.47 CSeq: 102 INVITE User-Agent: LES.NET.VoIP Max-Forwards: 70 Date: Thu, 19 Jun 2008 07:30:16 GMT Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Content-Type: application/sdp Content-Length: 317 Then opensbc responds back with: U 204.13.XX.XX:5066 -> 64.34.181.47:5060 SIP/2.0 500 Internal Server Error From: "NOT FOUND" <sip:1305XXXXXX@64.34.181.47>;tag=as1941af79 To: <sip:7862XXXXX@204.13.XX.XX:5066>;tag=c298d0d21d3cdd119638a704fbd83836 Via: SIP/2.0/UDP 64.34.181.47:5060;branch=z9hG4bK68d77e9c;rport=5060;received=64.34.181.47 CSeq: 102 INVITE Call-ID: 046e8d7b24d7315c5074495a46fb29ba@64.34.181.47 Content-Length: 0 In my trunk configuration I have inbound route=sip:XX...@si... (which is a registered UA on the same server) The URI the provider sends is the exact URI in my configuration. I have restarted multiple times to no avail :( Any help is appreciated! Thanks |
|
From: OpenSIPStack F. <ope...@op...> - 2008-06-19 04:44:06
|
Running it as a process fixed the problem. Strange... |
18 messages has been excluded from this view by a project administrator.
