logan wrote:
> Hello,
>
> First of all, thanks for taking a look.
> > Now stun succeeds but it says it failed to register. I'm trying to
> > register from behind NAT in vmware. It says register failed, could not
> > connect
> > in the event tab. My phone registers fine. I checked it with ethereal,
> > crosstalk doesnt even send a single packet. If I turn on my phone,
> it does.
> > I tried automatic contact type and NAT mapped, with the same result.
> I once had this problem in my college lab, but at that time other
> softphones were also not able to register. So, I felt that the network
> admins have blocked the ports or something like that. Could it be
> because of a firewall? Below is stripped version of how I try to
> register, do I seem to be doing something awefully wrong?
No ports are blocked, its standard vmware NAT. Windows firewall is off
on both the host windows XP and vmware windows XP. My client can connect
so sipxtapi can do it. Or perhaps you use a version of sipxtapi that is
too old? Currently I use revision ~9000 and upgrade about once in 3 weeks.
>
> > If you don't recompile, the dll will keep using CRT 7.1, while exe will
> > try to use CRT 8.0.
> Thank you, I will try this out.
>
> Regards,
> Hitesh
>
> if (sipxInitialize (&m_hInst,
> CCrossTalkSettings::GetInstance ().GetSIPPort (),
> CCrossTalkSettings::GetInstance ().GetSIPPort (),
> -1,
> CCrossTalkSettings::GetInstance ().GetRTPPort ()) ==
> SIPX_RESULT_NETWORK_FAILURE)
> {
> CUIManager::GetInstance ().SetStatusbarMessage (_T("Unable to connect"));
> return FALSE;
> }
>
>
> // set dns srv timeout to something reasonable
> sipxConfigSetDnsSrvTimeouts (CCrossTalkSettings::GetInstance
> ().GetDnsSrvTimeout (),
> CCrossTalkSettings::GetInstance ().GetDnsSrvRetries ());
>
>
> sipxConfigSetUserAgentName(m_hInst, _T("CrossTalk"));
>
> sipxConfigEnableStun (m_hInst, CCrossTalkSettings::GetInstance
> ().GetStunServer (),
> CCrossTalkSettings::GetInstance ().GetStunPort (), 28);
>
> sipxConfigEnableTurn (m_hInst, CCrossTalkSettings::GetInstance
> ().GetTurnServer (),
> CCrossTalkSettings::GetInstance ().GetTurnPort (), NULL, NULL, 28);
>
>
> sipxConfigEnableIce (m_hInst);
>
> sipxConfigSetOutboundProxy (m_hInst, CCrossTalkSettings::GetInstance
> ().GetProxy ());
>
> sipxConfigEnableRport (m_hInst, CCrossTalkSettings::GetInstance
> ().GetRport ());
>
> sipxEventListenerAdd(m_hInst, EventCallbackProc, NULL);
>
>
> sipxConfigSetRegisterExpiration (m_hInst, 300);
>
> if (CCrossTalkSettings::GetInstance ().GetStun ())
> {
> CUIManager::GetInstance ().SetStatusbarMessage (_T("Waiting for stun
> success"));
> //Wait for stun success
> m_eventStun.Lock ();
>
> if (!m_bStunSuccess)
> {
> return FALSE;
> }
> }
>
> sipxLineAdd (m_hInst, CCrossTalkSettings::GetInstance ().GetAddress
> (), &m_hLine, contactId);
>
>
> sipxLineAddCredential(m_hLine, CCrossTalkSettings::GetInstance
> ().GetUsername (),
> CCrossTalkSettings::GetInstance ().GetPassword (),
> CCrossTalkSettings::GetInstance ().GetRealm ());
>
> sipxLineRegister (m_hLine, true);
>
>
Are you executing this in another thread? Because some of the functions
take longer to complete. There you also access a singleton, if this is
in another thread then application might not be thread safe. I have
noticed crosstalk doesn't freeze during initialization like sipxezphone.
When waiting for STUN result, be careful you need to wait for all
results, not just the first success, as PC can have multiple interfaces
which lead to different networks and they can be in different NATs. You
should get a result for each IP address. I will compare the code with
mine later, as I have to do something else right now, but I see you
followed the bad habbit in sipxezphone to call sipxtapi functions
without checking results. I have a special class that is for calling
sipxtapi functions and does checking of all results and logs errors and
sipxtapi error codes. This is important if you use a library that is not
100% stable. This class has 100kb of code (cpp + h file) but if there is
a problem I can quickly find it.
Jaroslav Libak
_______________________________________________
sipxtapi-dev mailing list
[email protected]
List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
