| < Previous by Date | Date Index | Next by Date > |
| < Previous in Thread | Thread Index | Next in Thread > |
Ah, so the requests are arriving at the wrong place? Do you have logs of the REGISTER transactions? It may be that the registration step isn't working quite right.
Best regards,Byron CampenThe problem we are seeing is that, the callbacks,onnewsession is not called for the appropriate UA's
We have registered 3 UA's 89001,89002 and 89004. When we send a INVITE to 89001 and 89002, we see the onnewsession of 89004 is getting called .
Thanks,
V.Lakshmi NarayananOn Mon, Apr 27, 2009 at 10:56 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
Ah, ok. So you aren't sharing the TCP transport. What kind of error are you seeing? Is there anything in the logging?
Best regards,Byron CampenNO, in the addtransport, once we get an exception, we would generate a new port and then use it. We have seen that all UA's are getting registered properly.
Thanks,
V.Lakshmi NarayananOn Mon, Apr 27, 2009 at 10:39 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
So, you end up calling SipStack::addTransport() with the same args multiple times? That'll work the first time you call it, but subsequent calls will not, since that IP+port combination is already in use.
Best regards,Byron CampenJus to add more info on what we are doing, we have a CUserAgent and in it is initilaized with the following
{
if ( pAvSwitch->m_naProxy.uri ().scheme () == resip::Symbols::Sips )
{
m_pSecurity = new Security ( Data ( "../etc/" ) );
m_pSipStack = new SipStack ( m_pSecurity );
m_pStackThread = new StackThread ( *m_pSipStack );
m_nTlsPort = addTransport ( TLS, DEFAULT_TLS_PORT );
//pAvSwitch->m_naProxy.param ( p_transport ) = "tls";
InfoLog ( << LOGTAG(strFn,NOINFO) << "TLS enabled" );
}
else
{
m_pSecurity = NULL;
m_pSipStack = new SipStack ();
m_pStackThread = new StackThread ( *m_pSipStack );
InfoLog ( << LOGTAG(strFn,NOINFO) << "TLS is not enabled" );
}
m_nTcpPort = addTransport ( TCP, DEFAULT_TCP_PORT );
m_nUdpPort = addTransport ( UDP, DEFAULT_UDP_PORT );
if ( m_nTcpPort != 0 && m_nUdpPort != 0 )
{
m_bSipTransportAdded = true;
}
}
if ( m_bSipTransportAdded )
{
m_pDUM = new DialogUsageManager ( *( m_pSipStack ) );
m_pDUMThread = new DumThread ( *m_pDUM, m_mutexDUMProc );
m_pDUM->setInviteSessionHandler ( this );
m_pDUM->setClientRegistrationHandler ( this );
m_pDUM->addOutOfDialogHandler ( OPTIONS, this );
m_pDUM->addClientSubscriptionHandler ( "refer", this );
m_pDUM->setRedirectHandler ( this );
auto_ptr< AppDialogSetFactory > dsfUAClient ( new CICAppDialogSetFactory );
m_pDUM->setAppDialogSetFactory ( dsfUAClient );
// wire up the REFER Message modification
SharedPtr< DumFeature > featDUM( new CAddCallInfo ( this, *m_pDUM, m_pDUM->dumOutgoingTarget () ) );
m_pDUM->addOutgoingFeature ( featDUM );
auto_ptr< ClientAuthManager > uacAuth ( new ClientAuthManager );
m_pDUM->setClientAuthManager ( uacAuth );
SharedPtr< MasterProfile > uacMasterProfile ( new MasterProfile );
uacMasterProfile->setUserAgent ( Data ( VERSION ) + Data ( "-" ) + Uri ( strUri.data () ).user () );
// setup NOTIFY/REFER support
uacMasterProfile->addSupportedMethod ( UPDATE );
uacMasterProfile->addSupportedMethod ( NOTIFY ); // add NOTIFY support for REFER
uacMasterProfile->addSupportedMimeType ( NOTIFY, Mime ( "message", "sipfrag" ) );
// set the proxy/registrar
uacMasterProfile->setOutboundProxy ( pAvSwitch->m_naProxy.uri () );
// set registration expiration time
uacMasterProfile->setDefaultRegistrationTime ( pAvSwitch->m_nRegTime );
uacMasterProfile->setRinstanceEnabled ( false );
// set AOR
uacMasterProfile->setDefaultFrom ( m_naAor );
uacMasterProfile->setDigestCredential ( pAvSwitch->m_naRealm.uri ().host (),
Data ( strLogin.data () ),
Data ( strPassword.data () ) );
m_pDUM->setMasterProfile ( uacMasterProfile );
m_ruleList.push_back ( MessageFilterRule ( resip::MessageFilterRule::SchemeList (),
resip::MessageFilterRule::Any,
resip::MessageFilterRule::MethodList (),
resip::MessageFilterRule::EventList () ) );
m_pDUM->setMessageFilterRuleList ( m_ruleList );
m_pCallManager = CCallManager::GetCallManager ();
m_pUserManager = CUserManager::GetUserManager ();
m_pStackThread->run ();
m_pDUMThread->run ();
}
We would be creating n number of instances of CUseragent .
Thanks,
V.Lakshmi NarayananOn Mon, Apr 27, 2009 at 9:43 PM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
Huh, I was always under the impression that there were some static objects that would cause problems here, but I guess I was mistaken. So, I guess we're back to the "How did you get multiple UAs with multiple distinct stack/DUM pairs to share a TCP transport?"
Best regards,Byron Campen2 threads can't call the same dum instance without application level locking but there is nothing that has ever stopped multiple dum instances from running in separate threads. This hasn't changed since the initial release. Granted I'm pretty rusty but I can't see any reason why this wouldn't be possible. I'm pretty sure lots of folks have created applications with multiple dum instances.
On Mon, Apr 27, 2009 at 9:03 AM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:???I know I've been off the radar for a bit, but are you saying that DUM has been made threadsafe? And that this change is in 1.4.1, a release that I cut?
Best regards,Byron CampenWhy wouldn't it be safe to have multiple dum instances per process? I'm not sure it is advised but I don't think there is anything that stops this.
On Mon, Apr 27, 2009 at 8:32 AM, Byron Campen <bcampen@xxxxxxxxxxxx> wrote:
Well, it isn't safe to have more than one DUM instance per process, so you're going to need to change that. This will also restrict you to having one stack (since you can't attach more than one stack to DUM). I am curious how you were managing to have multiple DUMs, with multiple stacks, share a TCP transport at all; this should not work for any type of transport.
Best regards,Byron CampenHi Bryon,
Can you help us on this?
Thanks,
V.Lakshmi Narayanan
On Wed, Apr 22, 2009 at 11:09 PM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Now I am getting a weird problem with TLS/SSL.My application is having 5 UAs & each UA has its own DUM & SipStack.Each UAs are using different UDP port but same TCP & TLS port.When I enabled TLS the INVITE sent to different UAs are being delivered to one particular UA's onNewSession virtual function.e.g. UA1's onNewSession is being called for INVITE on any of the 5 UAs.And this selection of particular UA too is random. Not for a particular guy each time I restart my application.If TLS is not being used, everything works fine.Corresponding UA's onNewSession function is being called for respective INVITEs & not always for a particular UA's onNewSession.Is this recommended to have different DUM & SipStack for each UA or do they share these?What could be the problem here?Thanks,~ RajeevFrom: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott GodinHi Srivastava,
Sent: Sunday, April 19, 2009 12:29 AM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1
Thanks for this. It has already been fixed in SVN revision 8296 and 8348.Regards,Scott
On Sat, Apr 18, 2009 at 10:18 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Scott, Thanks for your inputs. SSL is working fine now after generating new certificated with correct hosname information.However, There is one problem I found in resip\stack\ssl\TlsConnection.cxx TlsConnection::read function.<snip>int bytesRead = SSL_read(mSsl,buf,count);
StackLog(<< "SSL_read returned " << bytesRead << " bytes [" << Data(Data::Borrow, buf, bytesRead) << "]");if (bytesRead > 0 && SSL_pending(mSsl))
{
int restBytes = SSL_pending(mSsl);
char* buffer = getWriteBufferForExtraBytes(restBytes);
StackLog(<< "reading remaining buffered bytes");
restBytes = SSL_read(mSsl, buffer, SSL_pending(mSsl));
StackLog(<< "SSL_read returned " << restBytes << " bytes [" << Data(Data::Borrow, buffer, restBytes) << "]");if (restBytes>0)
{
bytesRead += restBytes;
}
else
{
bytesRead = restBytes;
}
}</snip>My Client application was returning -1 for SSL_read(mSsl,buf,count) function call with error code 2.After that it was crashing at following line :-StackLog(<< "SSL_read returned " << bytesRead << " bytes [" << Data(Data::Borrow, buf, bytesRead) << "]");when it was trying to write << Data(Data::Borrow, buf, bytesRead) .The correct location for this log message should be inside if (bytesRead > 0 && SSL_pending(mSsl)) block.The correct code should be :<snip>int bytesRead = SSL_read(mSsl,buf,count);
if (bytesRead > 0 && SSL_pending(mSsl))
{StackLog(<< "SSL_read returned " << bytesRead << " bytes [" << Data(Data::Borrow, buf, bytesRead) << "]");
int restBytes = SSL_pending(mSsl);
char* buffer = getWriteBufferForExtraBytes(restBytes);
StackLog(<< "reading remaining buffered bytes");
restBytes = SSL_read(mSsl, buffer, SSL_pending(mSsl));
StackLog(<< "SSL_read returned " << restBytes << " bytes [" << Data(Data::Borrow, buffer, restBytes) << "]");if (restBytes>0)
{
bytesRead += restBytes;
}
else
{
bytesRead = restBytes;
}
}</snip>Thanks,~ RajeevSent: Thursday, April 09, 2009 6:57 PM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1The problem is that the post TLS handshake hostname validation check is failing. When a TLS client connects to a server - it must check that the certificate presented by the server to the client identifies the server that it is trying to contact. In SIP this means the hostname in the request URI of the SIP request you are sending must match either the certificate subject common name, or one of the SubjectAltNames (DNS or URI entries). The following line in the logs indicate this error:<<RESIP:TRANSPORT-ERROR>> Certificate name mismatch: trying to connect to <148.147.174.64> remote cert domain(s) are <Converged Communication Server 2.1>
There are two problems in your setup. You are using an IP address to contact the server. When using TLS you should always use hostnames or SRV records to connect to the TLS server. Your certificate does not contain a valid hostname in the Subject CommonName field.Hope this helps.Scott
On Thu, Apr 9, 2009 at 6:51 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Hello Scott,Yes, my reSIProcate Application is TLS Client.I am not sure what changes need to be done while generating Certificate to pass this host validation check.Is this (the problem I am facing) because of wrong certificate or do I need to change my code to work with new version of reSIProcate?As I am not very much knowledgeable in SSL stuff, I am attaching the reSIProcate logs along with the certificates I am using for further help on this.Thanks,~ RajeevFrom: slgodin@xxxxxxxxx [mailto:slgodin@xxxxxxxxx] On Behalf Of Scott Godin
Sent: Tuesday, April 07, 2009 8:36 PM
To: Srivastava, Rajeev Kumar (Rajeev)
Cc: resiprocate-users@xxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SSL not working with reSIProcate 1.4.1
Is resiprocate the TLS client or server in these traces? Are there any relevant errors in the resiprocate log files?Assuming your resiprocate application is the TLS client, it is tearing down the TLS connection after the handshake. Usually this is because the post handshake host validation check failed. The code surrounding hostname validation has changed since release 1.1. The resip logs should contain some useful information if this is the case.Scott
On Tue, Apr 7, 2009 at 5:58 AM, Srivastava, Rajeev Kumar (Rajeev) <srivastava@xxxxxxxxx> wrote:
Hi,I recently upgraded resiprocate library to 1.4.1 form 1.1 for one of my projects(Windows only).After that TLS is not getting enabled.<code snip>Security* pSecurity = new Security ( "..\etc" );
SipStack* pSipStack = new SipStack ( pSecurity );
StackThread* pStackThread = new StackThread ( *pSipStack );
pSipStack->addTransport ( TLS,
nTlsPort,
V4,
StunDisabled,
Data::Empty,
Data::from ( strDomain ) );pSipStack->addTransport ( TCP, nTcpPort);pSipStack->addTransport ( TCP, nUdpPort);pStackThread->run ();</snip>This same piece of code is working fine with the same certificate with reSIProcate 1.1.But it is not working with reSIProcate 1.4.1I am attaching WireShark logs for reference.Is there any change in SSL implementation and do I need to use it in a different manner now?Do let me know if you need any more information for helping out.Thanks,~ Rajeev
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
--
luxbaba
_______________________________________________
resiprocate-users mailing list
resiprocate-users@xxxxxxxxxxxxxxx
List Archive: http://list.resiprocate.org/archive/resiprocate-users/
--
Jason
Sent from San Francisco, California, United States
--
Jason
Sent from San Francisco, California, United States
--
luxbaba
--
luxbaba
--
luxbaba
Attachment:
TLSSIP.log
Description: Binary data