Author |
|
Guests Guest User
Joined: October 01 2003 Posts: -184
|
Posted: January 31 2005 at 2:34pm | IP Logged
|
|
|
Dear Randal,
I have a technical question for you.
We tried to test the SDK by running the sample applications that come with
the SDK. but the problem we encountered is :
when we use pc to phone(ipphone) call, they work fine. But when we tried the
pc to pc call, the callee could not hear anything, only the caller can hear
the callee. We adjust the RTP port value used in teh source code, but still
it does not work.
We will appreciate it very much if you could help a little.
regards,
will
|
Back to Top |
|
|
Guests Guest User
Joined: October 01 2003 Posts: -184
|
Posted: January 31 2005 at 2:38pm | IP Logged
|
|
|
hi,Randal ,
There are more info for your reference to help sloveing the problem.
1.we used the local network for testing.
2. the sample application run behind firwall.
3.Does your sample app has any confilits with msn messenger or netmeeting?
thanks,
will
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: January 31 2005 at 2:41pm | IP Logged
|
|
|
Will,
What you describe sounds like your firewall is performing port translation.
If the calls are connecting, then the SIP portion of the call is ok.
However, the SIP protocol embeds IP address and port information in the SIP
protocol packets that are exchanged by each call endpoint during call setup.
This embedded IP address and port information is for the exchange of call
media (your voice in this example).
If there is a network element (firewall or router) in between the peer to peer call
endpoints that performs port translation, then this is the probable cause. The VOIP media
engine and sample applications will work for all cases of NAT (network address translation)
but will not function peer to peer if port translation is being performed.
Generally speaking, no SIP enabled device will be able to handle port translation
in a peer to peer mode. That is where SIP proxies and media proxies enter the
deployment picture. Routers and firewalls introduce special problems that makes
the network very hostile to peer to peer applications like VOIP.
I am not sure what you meant by ipphone?
(when we use pc to phone(ipphone) call, they work fine. )
Pleas elaborate.
Very Important:
The example applications are designed for your private network and to allow developers
to experience call setup, typical voice latencies, voice quality and feature checkout.
They are also meant to give some form of code example to a developer so they can integrate the
VOIP Media Engine into their own application. They are not meant to be deployed in
disparate network subsegments behind NAT/port translating firewalls or routers.
Depending on what you want to do, you generally need to make your VOIP services visible
to the global internet. There are many ways to do this. Also, if your users are behind firewalls
or routers that perform port translation, then you must require customers to connect to your service's
SIP proxy that also supports media proxying. If the server side of the equation is deployed properly,
your customers can have their VOIP phones behind their own firewalls/routers in whatever configuration
they want. To successfully deploy VOIP globally, one must not think of peer to peer but think in terms of
client-server using SIP proxy and RTP media proxying.
If you need to get up to speed on deploying SIP proxies and media proxies, we suggest
you visit the excellent iptel web site located at: http://www.iptel.org/ser/
Also, goto our sister web site at: http://lanscapecorp.dnsalias.com/ipCookbook/
The IP Telephony Cookbook will also explain what special issues routers and firewalls
introduce. See section 4.7. Firewalls and NAT.
For the immediate moment and to make your tests work using the example applications,
make sure your firewall/router is not performing port translation for all RTP ports
you are trying to use. Note also: No SIP device can properly work peer to peer if there is
a symmetrical NAT router or firewall in between them. Using a symmetrical NAT router or firewall
requires that you configure your VOIP system using SIP and RTP proxies.
If you want, please send this additional information:
1)your current network configuration you are using to test.
2)the type of router/firewall you are using.
3)what is ipphone?
4)send us a SIP log file from the media engine example. (See the VOIP Media Engine's
online help for the START_SIP_TELEPHONY_PARAMS structure). Set the LogSipMessages
member to nonzero value and set the pSipLogFileName to the name of the log file).
5)The more specific information you can give, the better.
Best Regards,
Randal Ziegler
|
Back to Top |
|
|
Guests Guest User
Joined: October 01 2003 Posts: -184
|
Posted: January 31 2005 at 2:46pm | IP Logged
|
|
|
Dear Randal ,
Thanks to your info.
The senario is:
When we used the sample appliction to call an ip phone(which is a hardware phone connected to the local network and has its own ip address like a computer ), everything is fine. But when we tried to make peer to peer call,( this means we had two sample applications(multiline) running on two computers and we used one application to call another application running on
another computer), it is always the callee that can hear the caller, the caller cannot hear the callee, it seems the audio mediam packages are being transmitted only in one way. This is still the case after we have got rid of all of the firewalls. We scanned the RTP ports on one computer , one is 8000, another is 8002, that means one of them is for receiving and another
is for sending, but they are too close. Then we changed the code to set the StartupParams.MinLocalRtpPort = 8000;StartupParams.MaxLocalRtpPort = 20000;
but this does not work, it seems the RTP ports are always set to 8000 and 8002 when the application is running.
Now we are adding the EnableSipDomain, EnableProxyServer and EnableRegisterServer functionality to get the application to run with those servers involved, and to see what will happen.
But we encountered the following problem: it is not quite clear in the documents that what is the sequence of calling those apis, especially when associated with the StartSipTelephony and SipTelephonyEnable apis.
so We added the EnableSipDomain, EnableProxyServer and EnableRegisterServer after the SipTelephonyEnable api has been called. Then it gives the SipBadParameter erros, in the documents it says this is becaue the pointer parameter is null, but we traced the pointer, it is not null.
And we noticed in the code that the StartSipTelephony, SipTelephonyEnable apis are called for every telephoneline, that means it is a multi-multi
realtionship in terms of UML. So does this mean the EnableSipDomain, EnableProxyServer and EnableRegisterServer should also be called for every
telephoneline?
Another issue is we set the logfile parameter in the struct to TRUE and also set the logfile name, but the logfile is always empty, it seems the application does not write anything in it.
I hope I have described the senario clearly for you to offer advice.
thanks,
Will
|
Back to Top |
|
|
lsadmin Administrator
Joined: October 01 2003 Location: United States Posts: 19
|
Posted: January 31 2005 at 2:49pm | IP Logged
|
|
|
Hello Will,
I just arrived back in the office and will get the answers to your questions today or immediately early in the morning. I need to verify something. Thank you for your patience.
Randal
|
Back to Top |
|
|
lsadmin Administrator
Joined: October 01 2003 Location: United States Posts: 19
|
Posted: January 31 2005 at 2:56pm | IP Logged
|
|
|
Will,
We apologize for the delay in this response. The information you submitted was exactly what we needed to track down the media issue. However finding the cause took a bit of time. Thank you for being patient.
Issue 1: Full duplex audio
The reason you are experiencing one way audio is because the "phone name" the software examples use was specified to be "LanScape Phone". This phone name is similar to a phone number or extension.
The phone name MUST NOT CONTAIN ANY SPACES! This is our mistake. I have requested that a software change be included in the next release that will remove this situation.
So to get your full duplex audio, change the name to "LanScapePhone" or to whatever you like (use no spaces). To do this, perform the following steps:
Open source code module PhoneBase.cpp
goto line 714. the line reads
StartupParams.pPhoneName = "LanScape Phone";
change the line to:
StartupParams.pPhoneName = "LanScapePhone";
Rebuild all the example applications. You should now have full duplex audio.
Also, use whatever RTP and SIP ports you want as port selection had nothing to do with this anomaly.
Issue 2: SIP proxy and registrar servers
The example software applications can use a SIP proxy and registrar server if you modify the PhoneBase.cpp module to use some of the APIs you mentioned. The
key API procedure you want to use are:
EnableSipDomain()
EnableSipProxyServer()
EnableSipRegisterServer()
in that order.
Usually, the last step in bringing up the telephony engine is to call the SipTelephonyEnable() API procedure. Please see line 874 of the PhoneBase.cpp
module.
You can call the three procs mentioned above after the call to SipTelephonyEnable()on line 874.
I have logged a documentation change ticket so we will include this information in our next release.
Issue 3: Multi-Multi relationship
You wrote:
So does this mean the EnableSipDomain, EnableProxyServer and EnableRegisterServer should also be called for every telephoneline?
Answer: No.
EnableSipDomain(), EnableSipProxyServer() and the EnableSipRegisterServer() APIs are only called once during the start up of your media engine as stated above.
Note:
The code that exists around line 760 of the PhoneBase.cpp module is attempting to figure out how many phone lines an installed VOIP Media Engine will support. These software apps are generic and were coded to work with 1 to 64 line media engines.
Your app on the other hand will know how many lines it can support and you will call the StartSipTelephony() API only once.
Also, the SipTelephonyEnable() API is only called once. It basically enables your telephony engine to transact SIP and RTP data. Like a
transceiver enable.
Issue 4: Log file
The software examples will create a SIP protocol log using the name "SipMessageLog.log". The name can be anything. The only thing you must do to is set the LogSipMessages member of the Startup Parameters to a non zero value. See line 751 of module PhoneBase.cpp. It eally does work. Example: Run your sample application. The log file should be created. Run a phone call and then exit the example application.
Now check the log file to see the raw SIP protocol information that was exchanged.
Last item:
We need to move your customer support related questions to our web forum. We recently mounted this forum so it is still empty. I will send you an email shortly describing how we will do this.
Best regards,
Randal Ziegler
|
Back to Top |
|
|
Guests Guest User
Joined: October 01 2003 Posts: -184
|
Posted: January 31 2005 at 3:03pm | IP Logged
|
|
|
Hi, Randal,
Thank you so much for your reply.
The problems seems have been solved after we got proxy server and registration server involved. We did not change the Phone name, and it still works fine. I am a little bit confused.
But there comes another question. When we test it in the same network domain with routers involved, we scaned the RTP port it was using, the port is always 8000 something, but when we test across different network domain with routers involved, the RTP port being used is always 15060, so we had to set the maxinum RTP port range to 20000 to make it run fine.
It seems the router is translating the RTP port. But why this only happens when testing across networks.
If possible, could you pls give advice again. We all like this SDK, and we plan to do more with it.
The idea of forum is excelent, that will gather alot of people there to share ideas.
regards,
will
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: January 31 2005 at 3:10pm | IP Logged
|
|
|
Hello Will,
you>>
The problems seems have been solved after we got proxy server and registration server involved. We did not change the Phone name, and it still works fine. I am a little bit confused.
Its OK to be confused. :-) The "phone name" issue may only affect the LanScape VOIP Media Engine receiving side of a phone call. Having spaces in the phone name/number may not affect how other SIP proxies or endpoints parse the SIP protocol packet. It is totally
possible (and probable) that the proxy may mave "adjusted" the SIP protocol SDP data as it propogated through the proxy. The SIP call logs will have exact details as to what is going on.
you>>
But there comes another question. When we test it in the same network domain with routers involved, we scaned the RTP port it was using, the port is always 8000 something, but when we test across different network domain with routers involved, the RTP port being used is always 15060, so we had to set the maxinum RTP port range to 20000 to make it run fine.
Hmm. Not sure. Need more details. The more accurate/descriptive you can be, the easier we will be able to visualize what you are doing. Remember: network address translation (NAT) and port translation (i.e. port address translation - PAT) in firewalls/routers are the primary issues that are plauging VOIP. NAT and PAT basically "break" the SIP protocol. There are however ways around this hostile network environment (network boundary controllers, sip proxy + RTP medi proxy, etc).
you>>
It seems the router is translating the RTP port. But why this only happens when testing across networks.
That's what routers do... if I understand you orrectly. We need additional data.
you>>
If possible, could you pls give advice again. We all like this SDK, and we plan to do more with it.
The VOIP Media Engine really does quite alot. Thank you for that feedback.
For as much as the media engine was designed to do, it can not overcome improper network deployment. It is imperative that proper SIP proxy and RTP media proxying be deployed to obtain the desired results.
For an example, FreeWorld dialup (http://www.freeworlddialup.com/) uses a Jasomi front end
boundary controller to resolve NAT/PAT SIP issues. The Jasomi box is in front of one or more iptel SIPExpress Routers + Asterisk PBXs.
Our ability to give you advice is directly dependant on your specific description of what you are trying to do.
Be very specific and send SIP logs if you can. Doing so is the quickest way to reduce issues. Vocalscape is now a LanScape customer. We will do as much as we can to assist you.
you>>
The idea of forum is excelent, that will gather alot of people there to share ideas.
Yeh, it will work better.
Best Regards,
Randal Ziegler
|
Back to Top |
|
|
|
|