| Author |
|
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 07 2008 at 6:29am | IP Logged
|
|
|
When there is a SipIncomingAuthentication event, if the Operation member is AUTHENTICATE_VERIFY_CREDENTIALS, we can use VerifyChallengeResponse API for authentication. The VerifyChallengeResponse function has four parameters:
SIPHANDLE hStateMachine,
CHALLENGE_HANDLE hChallenge,
char *pPassword,
char *pRealm
We can understand the first two parameters. My questions are:
1. How does VerifyChallengeResponse function know the inputed password is the right password?
2. In the struct CHALLENGE_AUTHENTICATION, we don't have "password", so how to provide the password to the *pPassword parameter?
3. How to provide the pRealm to the *pRealm parameter? Is it the same as ChallengeRealm in the CHALLENGE_AUTHENTICATION struct?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 07 2008 at 9:13am | IP Logged
|
|
|
Hi overseasg,
Thanks for your post.
We will explain the complete “round trip” authentication in an effort to make it clear. The authentication scenario we will describe applies to all incoming SIP requests that the media engine receives. Some of what we will discuss you already understand, but we will go through the whole explanation so others can understand it too. Authentication is simple one you grasp the basic concept – it just looks harder that it really is.
Incoming SIP Authentication Summary:
The media engine can challenge received SIP requests on behalf of the VOIP app. To enable this capability, the app needs to enable incoming authentication challenges in the media engine. This is done by calling the SetChallengeAuthenticationState() API procedure any time after the media engine is started.
Once the app calls the SetChallengeAuthenticationState() API procedure, the app will receive the SipIncomingAuthentication immediate event via the main media engine callback handler. At the time of this post, the callback handler has the following function prototype:
Code:
void __stdcall SipCallbackProc(
SIPHANDLE hStateMachine,
SIP_NOTIFY_TYPE NotificationType,
int PhoneLine,
TELEPHONY_RETURN_VALUE TelephonyEvent,
void *pUserDefinedData,
void *pEventData
);
|
|
|
When the SipIncomingAuthentication immediate event is sent to the app, the NotificationType parameter passed to the main callback will be set to IMMEDIATE_NOTIFICATION and the TelephonyEvent parameter will be set to SipIncomingAuthentication.
When processing the SipIncomingAuthentication immediate event, the pEventData parameter passed to the main callback handler actually is a pointer to a CHALLENGE_AUTHENTICATION structure that contains information for the SIP challenge during the specific challenge phase. In C/C++, simply recast the pEventData parameter to (CHALLENGE_AUTHENTICATION *) to access the challenge data.
There are two phases to an incoming SIP request challenge:
Phase 1:
Normally an incoming SIP request that contains no authentication credentials in the SIP message is received and will be sent back to the originating SIP device as an authentication challenge. During this phase, the app will receive the SipIncomingAuthentication immediate event. The “Operation” structure member of the CHALLENGE_AUTHENTICATION structure passed to the main event callback will be set to AUTHENTICATE_INCOMING_MESSAGE.
The app can determine if it wants to have the media engine challenge the received SIP request by inspecting the “MesageType” structure member of the CHALLENGE_AUTHENTICATION structure. If the app wants to have the media engie respond with an authentication challenge, the app must set appropriate values for the following CHALLENGE_AUTHENTICATION structure members: ChallengeMode, ChallengeType, Algorithm, ChallengeRealm and allow the main event callback handler to return.
Phase 2:
The originating SIP device resends the SIP request with authentication credentials for the realm as specified in phase 1. This SIP message is received by the media engine. At this phase, the application again receives the SipIncomingAuthentication immediate event and has access to another instance of the CHALLENGE_AUTHENTICATION structure via the main event callback parameter pEventData.
During this phase, the “Operation” CHALLENGE_AUTHENTICATION structure member will be set to AUTHENTICATE_VERIFY_CREDENTIALS.
To verify that the originating SIP device sent proper authentication credentials for the challenge realm, the app must grab the “authentication user name” from the “ChallengeUserName” CHALLENGE_AUTHENTICATION structure member. The app takes this “authentication user name” and looks up the preconfigured password for the user name.
Note: If your VOIP app is designed to have the media engine challenge SIP requests, somewhere in you app you must be able to configure authentication user names and passwords for incoming SIP requests. How you support this user name/password database is completely up to you. All you need to support is the ability to map user names to authentication passwors for the realm or realms you want to support in your VOIP app.
At this point, the app has everything it needs to have the media engine verify the authentication credentials in the received SIP message. It does this by calling the VerifyChallengeResponse() API procedure.
Code:
TELEPHONY_RETURN_VALUE VerifyChallengeResponse(
SIPHANDLE hStateMachine,
CHALLENGE_HANDLE hChallenge,
char *pPassword,
char *pRealm
);
|
|
|
The hStateMachine and hChallenge parameters of the above API procedure can be set using the hStateMachine and hChallenge CHALLENGE_AUTHENTICATION structure members.
The pPassword parameter should point to a NULL terminates ASCII string that contains the password for the user. Remember – this password comes from a username/password “database” lookup your app performs all on its own.
The pRealm parameter should point to a NULL terminated string that is the challenge realm. You can use the “ChallengeRealm“ value in the CHALLENGE_AUTHENTICATION structure if required.
If the VerifyChallengeResponse() API procedure returns SipSuccess, then your app MUST set the “AuthorizationGranted” CHALLENGE_AUTHENTICATION structure member to a non zero value (TRUE) and return from the main callback handler.
You have now authenticated the incoming SIP request and the media engine will continue processing the incoming authenticated SIP as normal.
Support
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 08 2008 at 3:13am | IP Logged
|
|
|
Thank you for the support.
I still have two questions:
1. What is “appropriate value” of ChallengeRealm member in the CHALLENGE_AUTHENTICATION struct? Could you give an example?
2. How to grab the “authentication user name” from the “ChallengeUserName” CHALLENGE_AUTHENTICATION structure member? I think there should be only one username for one telephone line, right?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 08 2008 at 8:00am | IP Logged
|
|
|
Hi overseasg,
Item 1:
You can use any string value for your SIP realm. It is up to you. Normally the SIP authentication realm is the same as the SIP domain of your VOIP application that is challenging the SIP requests.
If your SIP application is not accessed directly by SIP clients (UAs) using a domain name (i.e. MyGreatSipServer.com) or its IP address and is accessed via some other means (like indirectly using a SIP proxy or similar SIP server), then you should be able to specify whatever you want for your VOIP app’s authentication Realm. Whatever you specify, make sure that SIP clients can be configured with the proper authentication information for your voip app (i.e. authentication user name, authentication password and authentication realm).
Item 2:
There will be only one authentication user name in the received SIP request that contains authentication information as the result of a media engine SIP authentication challenge. If you look at the SIP log for the request challenge, you will se what we mean. Look for the SIP authentication related headers in the SIP messages.
During phase 2 from above, when your app receives the SipIncomingAuthentication immediate event and when the “Operation” CHALLENGE_AUTHENTICATION structure member is set to AUTHENTICATE_VERIFY_CREDENTIALS, simply type cast the main callback handler pEventData parameter to a (CHALLENGE_AUTHENTICATION *) pointer.
Using the CHALLENGE_AUTHENTICATION pointer, simply access the ChallengeUserName structure member. This value will contain the authentication user name as configured in the SIP device that is trying to communicate with your media engine based VOIP app.
Repost if you need additional help…
Support
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 11 2008 at 3:32am | IP Logged
|
|
|
Dear Support,
I am still not able to register my far end device (a VoIP Phone) to the LanScape. The far end device is at 10.0.0.101 and the LanScape Engine is running at 10.0.0.166. I try to capture the SIP messages.
Event Track
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipRegisterReceived
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipRegisterReceived
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipModifySipMessage
IMMEDIATE_NOTIFICATION, SipIncomingAuthentication
IMMEDIATE_NOTIFICATION, SipRegisterReceived
IMMEDIATE_NOTIFICATION, SipModifySipMessage
Sip Message Track:
REGISTER sip:10.0.0.166 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.101:5060;rport;branch=z9hG4bK015a1dd2e6
From: "1003" <sip:1003@10.0.0.166>;tag=71caafa6
To: "1003" <sip:1003@10.0.0.166>
Call-ID: 6954556c1fb45b7a79e1b6d851ab5d6b@10.0.0.101
Contact: <sip:1003@10.0.0.101:5060>
CSeq: 2 REGISTER
Max-Forwards: 70
Expires: 60
Allow: INVITE,CANCEL,ACK,BYE,NOTIFY,REFER,OPTIONS,INFO,MESSAGE
User-Agent: Nologo
Content-Length: 0
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 10.0.0.101:5060;rport;received=10.0.0.101;branch=z9hG4bK015a 1dd2e6
From: "1003" <sip:1003@10.0.0.166>;tag=71caafa6
To: "1003" <sip:1003@10.0.0.166>;tag=9f5f0000
Call-Id: 6954556c1fb45b7a79e1b6d851ab5d6b@10.0.0.101
CSeq: 2 REGISTER
Proxy-Authenticate: Digest realm="asiatalk@asiatel.com.sg", algorithm=md5, nonce="26b1e844fb1b4704a46c8bf39e9cf836", opaque="e79f3850d5a74c1d8e1bde5ba4f19fea"
User-Agent: LanScape VOIP Media Engine/5.12.7.22 (www.LanScapeCorp.com)
Content-Length: 0
REGISTER sip:10.0.0.166 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.101:5060;rport;branch=z9hG4bK982c694eb0
From: "1003" <sip:1003@10.0.0.166>;tag=71caafa6
To: "1003" <sip:1003@10.0.0.166>
Call-ID: 6954556c1fb45b7a79e1b6d851ab5d6b@10.0.0.101
Contact: <sip:1003@10.0.0.101:5060>
CSeq: 3 REGISTER
Proxy-Authorization: Digest username="1003",realm="asiatalk@asiatel.com.sg",nonce="26b1e 844fb1b4704a46c8bf39e9cf836",response="d9f8e3ce7810c792b2a55 5b22371563d",uri="sip:10.0.0.166",opaque="e79f3850d5a74c1d8e 1bde5ba4f19fea",algorithm=md5
Expires: 60
User-Agent: Nologo
Content-Length: 0
SIP/2.0 400 Invalid Request
Via: SIP/2.0/UDP 10.0.0.101:5060;received=10.0.0.101;rport=5060;branch=z9hG4b K982c694eb0
From: "1003" <sip:1003@10.0.0.166>;tag=71caafa6
To: "1003" <sip:1003@10.0.0.166>;tag=20bb0400
Call-Id: 6954556c1fb45b7a79e1b6d851ab5d6b@10.0.0.101
CSeq: 3 REGISTER
User-Agent: LanScape VOIP Media Engine/5.12.7.22 (www.LanScapeCorp.com)
Content-Length: 0
In my Application, I can see the SipIncomingAuthentication event is triggered twice. One time is AUTHENTICATE_INCOMING_MESSAGE and message type is MESSAGE_REGISTER. The second time is AUTHENTICATE_VERIFY_CREDENTIALS and VerifyChallengeResponse method returns SipSuccess. Attach the code of my application
void CPhoneBase::IncomingAuthentication(CHALLENGE_AUTHENTICATION *pChallengeAuth)
{
ACCOUNT *lpAccount = lpFirstAccount;
BOOL HasAccount = FALSE;
switch(pChallengeAuth->Operation)
{
case AUTHENTICATE_INCOMING_MESSAGE:
switch(pChallengeAuth->MesageType)
{
case MESSAGE_UNDEFINED:
break;
case MESSAGE_REGISTER:
pChallengeAuth->ChallengeMode = CHALLENGE_MODE_PROXY_AUTHENTICATE;
pChallengeAuth->ChallengeType = CHALLENGE_TYPE_DIGEST;
pChallengeAuth->Algorithm = CHALLENGE_ALGORITHM_MD5;
strcpy(pChallengeAuth->ChallengeRealm, "asiatalk@asiatel.com.sg");
break;
case MESSAGE_INVITE:
break;
case MESSAGE_BYE:
break;
case MESSAGE_SUBSCRIBE:
break;
case MESSAGE_NOTIFY:
break;
default:
break;
}
break;
case AUTHENTICATE_VERIFY_CREDENTIALS:
for (int i=0; i<DEFAULT_MAX_PHONE_LINE; i++)
{
// Get password for verification
if (strcmp(lpAccount->nLoginName, pChallengeAuth->ChallengeUserName) == 0)
{
HasAccount = TRUE;
break;
}
lpAccount++;
}
if (!HasAccount)
{
pChallengeAuth->AuthorizationGranted = FALSE;
break;
}
if (VerifyChallengeResponse(pChallengeAuth->hStateMachine, pChallengeAuth->hChallenge,
lpAccount->nLoginPass, pChallengeAuth->ChallengeRealm) == SipSuccess)
{
pChallengeAuth->AuthorizationGranted = TRUE;
}
else
{
pChallengeAuth->AuthorizationGranted = FALSE;
}
break;
case AUTHENTICATE_BAD_CREDENTIALS_RECEIVED:
break;
default:
break;
}
}
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 11 2008 at 4:10am | IP Logged
|
|
|
Here is another copy of event data log
capture by my defined function. It also shows the media engine accepted the authentication.
Operation: AuthenticateIncomingMessage; MessageType: Register;
Operation: VerifyCredentials; Username: 1003; Realm: asiatalk@asiatel.com.sg; VerifyResult: TRUE;
Operation: AuthenticateIncomingMessage; MessageType: Register;
Operation: VerifyCredentials; Username: 1003; Realm: asiatalk@asiatel.com.sg; VerifyResult: TRUE;
Operation: AuthenticateIncomingMessage; MessageType: Register;
Operation: VerifyCredentials; Username: 1003; Realm: asiatalk@asiatel.com.sg; VerifyResult: TRUE;
Operation: AuthenticateIncomingMessage; MessageType: Register;
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 11 2008 at 4:33am | IP Logged
|
|
|
Ok, I think I found the problem...
I also need to handle the SipRegisterReceived event.
Now the phone is registered successfully...
Thanks for your help
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 11 2008 at 11:56am | IP Logged
|
|
|
OK... great!
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 12 2008 at 2:31am | IP Logged
|
|
|
For Outgoing Authentication when application is challenged by another telephony application (eg. a Sip Proxy), we need to use AddAuthorizationCredentials to add the credentials. My questions is:
I have 8 lines (line0 to line7). I only want to register line 1, 3, 5, 7 to the Sip Proxy. How shall I configure the AddAuthorizationCredentials function?
I try to call the AddAuthorizationCredentials, but when I monitor the media engine, there is no sip REGISTER message sent to the Sip proxy after the media engine starts. I have enabled the Sip Domain, Sip Registar & Sip Proxy function.
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 12 2008 at 3:38am | IP Logged
|
|
|
Dear Support,
Another thing I don't understand is:
I enable the Sip Proxy in my Applicaiton, the proxy IP is 10.0.0.200. When I get a call from an IP Phone (IP address 10.0.0.101), in the SipIncomingCallAssignPhoneLine event, I assign line0 to this incoming call. In the EventLog, I can see everything is fine (See below). But when I monitor the sip packages, I see something is wrong. First, I receive the INVITE from my IP Phone (10.0.0.101) directly (not from Sip Proxy). By right, the LanScape Engine should reply 100 Tring & 180 Ringing to the IP Phone (10.0.0.101). But actually, LanScape Engine replies 100 Tring & 180 Ringing to the Sip Proxy (10.0.0.200). It makes the phone resend the INVITE again and again and finally timeout. I can see in the SIP package, it marked the receiver is 10.0.0.101, but in the TCP/IP layer, the actual receiver is 10.0.0.200 which is Sip proxy. If I don't enable the proxy, the issue will not happen. How I can do to correct the error?
Event Log
PHONE_LINE_NOTIFICATION, Phone Line 0: SipIncomingCallStart
IMMEDIATE_NOTIFICATION, Phone Line 0, SipIncomingCallInitialized
PHONE_LINE_NOTIFICATION, Phone Line 0: SipSendTrying
IMMEDIATE_NOTIFICATION, Phone Line 0, SipModifySipMessage
PHONE_LINE_NOTIFICATION, Phone Line 0: SipSendRinging
IMMEDIATE_NOTIFICATION, Phone Line 0, SipModifySipMessage
PHONE_LINE_NOTIFICATION, Phone Line 0: SipStartIncomingRing
PHONE_LINE_NOTIFICATION, Phone Line 0: SipOkToAnswerCall
Sip Package:
INVITE sip:991162376@10.0.0.166 SIP/2.0
Via: SIP/2.0/UDP 10.0.0.101:5060;rport;branch=z9hG4bK119c39fa1a
From: "1003" <sip:1003@10.0.0.166>;tag=7a109199
To: <sip:991162376@10.0.0.166>
Call-ID: 25dd432b6164cf782171013c02081b4b@10.0.0.101
Contact: <sip:1003@10.0.0.101:5060>
CSeq: 801 INVITE
Max-Forwards: 70
Allow: INVITE,CANCEL,ACK,BYE,NOTIFY,REFER,OPTIONS,INFO,MESSAGE
Supported: replaces
Content-Type: application/sdp
User-Agent: Nologo
Content-Length: 241
v=0
o=- 46279 0 IN IP4 10.0.0.101
s=SIP CALL
c=IN IP4 10.0.0.101
t=0 0
m=audio 60001 RTP/AVP 8 0 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.0.101:5060;received=10.0.0.101;rport=5060;branch=z9hG4b K119c39fa1a
From: "1003" <sip:1003@10.0.0.166>;tag=7a109199
To: <sip:991162376@10.0.0.166>
Call-ID: 25dd432b6164cf782171013c02081b4b@10.0.0.101
CSeq: 801 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.7.22 (www.LanScapeCorp.com)
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.0.101:5060;received=10.0.0.101;rport=5060;branch=z9hG4b K119c39fa1a
From: "1003" <sip:1003@10.0.0.166>;tag=7a109199
To: <sip:991162376@10.0.0.166>;tag=1175ffb
Call-ID: 25dd432b6164cf782171013c02081b4b@10.0.0.101
CSeq: 801 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.7.22 (www.LanScapeCorp.com)
Content-Length: 0
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 12 2008 at 5:57am | IP Logged
|
|
|
As long as the Sip Proxy function in Media Engine has some issues, I try to disable Sip Proxy function, but turn on the Sip Domain and Sip Registar support. I create a two line telephony instance, and assign following parameters to EnableSipRegisterServer function
EnableSipRegisterServer
(pPhoneBase->hSipEngine,
CSPTR(PhoneBaseSettings.PhoneName), // 1003,805
TRUE, // RegisterPhoneLines
FALSE, // Disallow to use Sip Proxy
CSPTR(PhoneBaseSettings.RegistrationServerAddress), //10.0.0.200
PhoneBaseSettings.RegistrationServerPort, // 5060
PhoneBaseSettings.RegistrationIntervalSeconds, // 3600
PhoneBaseSettings.RegistrationIntervalSeconds, // 3600 Expired Time
PhoneBaseSettings.RegistrationTimeoutMs, // Timeout 4000
FALSE); //Disable Auto detect
It fails and return SipRegisterError. What may cause this error?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 12 2008 at 11:26am | IP Logged
|
|
|
Hi overseasg,
You >>>
I have 8 lines (line0 to line7). I only want to register line 1, 3, 5, 7 to the Sip Proxy. How shall I configure the AddAuthorizationCredentials function?
<<< Support
We will try to take you through the entire process. We will have to make a few assumptions regarding what you actually want to do.
Because you only want to register lines 1,3,5 and 7, we assume you only want to be able to receive calls on those lines from your VOIP domain and that each line will have its own individual authentication credentials. This is OK.
To do this properly, specify “dummy” default phone and display names for all phone lines using the pPhoneName and pPhoneDisplayName members of the START_SIP_TELEPHONY_PARAMS structure and then call the StartSipTelephony() API procedure. We will assume you will set the “dummy” default phone name to “DummyLine”.
Once the media engine startes without errors, do the following:
1)
Call the EnableSipDomain() API procedure in your code to specify the VOIP domain.
2)
Call the EnableSipProxyServer () API procedure in your code to specify the SIP proxy location.
3)
For phone line 1,3,5 and 7, call the SetPhoneName() and SetPhoneDisplayName() API procedures to set the real user names and display names for the lines. Setting the phone name for each line using the SetPhoneName() proc will allow incoming calls to be vectored to the specific lines by the media engine automatically.
4)
Before attempting to register the user names (extensions) for “dummy” lines (lines 0,2,4,6) and lines 1,3,5 and 7, add the appropriate authentication credentials for the user names. Do this by calling the AddAuthorizationCredentials() API procedure five times. The first time you will call the proc using line 1’s user name, password and realm. The second time you will call the proc using line 3’s user name, password and realm and so on….
The last time you call the AddAuthorizationCredentials() API procedure, call it once using the authentication user name and password for the “dummy” lines (lines 0,2,4,6).
The reason we have to specify authentication credentials for “dummy” lines is because of the way registration currently works. If we want to allow the media engine to automatically vector incoming calls to specific registered phone lines, then we need to register all the unique names for all the phone lines (see the next step below). Because we are still registering a single “dummy” name for lines 0,2,4, and 6, we will need single authentication credentials for those lines so the “dummy” lines can be registered properly. There is an alternative to registering all the user names for all the lines, but we had to guess a somewhat regarding the functionality you really need.
5)
Optionally call the SetOutgoingLineOnly() API proc for all dummy lines 0,2,4,6 if you do not want them answering calls.
6)
Call the SipTelephonyEnable() API procedure before attempting registration cycles.
7)
Register the user names for the “dummy lines” and for phone lines 1,3,5 and 7 by calling the EnableSipRegisterServer() API procedure.
You must pass the following comma separated list of names for the pNamesToRegister parameter:
Code:
pNamesToRegister = “dummy”,”line1”, “dummy“, ”line3”, “dummy“, ”line5”, “dummy”,”line7”;
|
|
|
…and set the RegisterPhoneLines parameter to a non-zero value.
Note:
As soon as your VOIP app calls the EnableSipRegisterServer() API procedure, registration cycles will start. Check your SIP logs or use the real time SIP event logging to a remote SipLogD server to monitor the SIP as it occurs. See the Software Developer’s Reference for additional info.
All of the above can be simplified a bit if you want to have your VOIP app code manually assign incoming phone lines for incoming calls. In this case, your VOIP app can simply register whatever names it wants with the RegisterPhoneLines parameter set to FALSE when calling the EnableSipRegisterServer() API procedure.
Your all then needs to handle the SipIncomingCallAssignPhoneLine immediate event to inspect the received SIP INVITE request and then specify a phone line that the call should be vectored to. If your VOIP app determines that the call should not be handled by any phone line, it should terminate the call during the processing of the SipIncomingCallAssignPhoneLine immediate event. See the TerminateIncomingCall and SipResponseCode members of the ASSIGN_INCOMING_PHONE_LINE structure in the Software Developer’s Reference.
You may have to repost to additionally clarify what you want to do.
From your post on 12 August 2008 at 3:38am
If the media engine is configured to use a proxy, don’t use it to also handle calls from outside of the proxy’s domain (directly from other user agents). This is by design. The media engine is meant to be used in a SIP domain using a proxy or standalone – but not both at the same time. We may change this behavior in a future revision.
From your post on 12 August 2008 at 5:57am
You can disable SIP proxy, enable domain and then perform a successful REGISTER operation. It works OK here. You may have to check the events that are being sent to your VOIP app to get additional information. See the START_SIP_TELEPHONY_PARAMS startup structure for the following parameter values:
EnableEventLogServers
pEventLogServerList
pEventLogServerPortList
It is a good idea to have the media engine send all the events your app is receiving to a remote event log server (The command line EventLogD.exe server that comes with the product). This way you will be able to see all generated events your application receives in real time. The events will probably give us more information why the registration is failing.
Note:
We want to continue to help you and your group but we think your 2 months of free support is over. Please contact us via the support email address with your company name, your order number and the date that you purchased the media engine. If the purchase date is more than 2 months ago, then we will have to get your group into a support agreement so that we are not hindered from this end.
Thanks,
Support
|
| Back to Top |
|
| |
overseasg
Intermediate
Joined: May 29 2008
Location: Singapore
Posts: 11
|
| Posted: August 12 2008 at 10:30pm | IP Logged
|
|
|
Dear Support,
Sorry that I don't know you do have the time limitation of the forum support.
Actually I want to allow phone line 0, 2, 4, 6 to be able to receive the call from IP Phone device in LAN and at the same time, line 1, 3, 5, 7 to call out through a sip proxy with sip register function. But before I can send the INVITE to proxy, I should regiter line 1, 3, 5, 7. I also try to register with dummy line. But the server reject the REGISTER from dummy line and it cause the EnableSipRegisterServer fail with SipRegisterError returned. Maybe you can solve this issue in the next release.
By the way, do you have any timeline to release the version which can support the sip proxy function for individual line?
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: August 14 2008 at 8:23am | IP Logged
|
|
|
Hi overseasg,
Thanks for waiting for this response.
Yes… unfortunately we have to limit the max amount of free support offered. Otherwise all of our time would be spent being involved in free support issues. Needless to say, we would not be in business long. :)
This does not mean that we do not want you continue posting to the support forum with bugs, improvement requests or enhancements or basic questions. It simply means that we have to reserve the right to select how, when and if we continue to give free support.
[About your issue:
We gave additional thought about you wanting to allow direct communication with independent UAs that communicate directly with the media engine while at the same time the media engine is configured to use SIP proxy support.
You may want to take a look at the SipIncomingCallAssignPhoneLine and SipModifySipMessage “immediate events” that the media engine sends to your application.
You can use these events to alter the destination of where media engine SIP responses are sent to. In other words:
1)
When your VOIP app receives a INVITE SIP request, your app would handle the SipIncomingCallAssignPhoneLine “immediate event” for the received SIP INVITE message. Your app could look at the raw received SIP message to see if it has come from your SIP proxy or directly from some other user agent.
Your VOIP app can determine if the SIP message came from your proxy by using the pReceivedIpAddress and ReceivedPort values in the ASSIGN_INCOMING_PHONE_LINE structure that gets passed to your app when your app handles the SipIncomingCallAssignPhoneLine event. Alternately, your app could simply look at the SIP message to see if it came from your proxy using the “User-Agent:” or “Server:” SIP headers in the received SIP INVITE.
If your app determines that the SIP message came directly from some other UA, your app could minimally parse the call ID from the received SIP request and “record” that fact for later use.
2)
Your app will also need to handle the SipModifySipMessage immediate event for all ready-to-be transmitted SIP messages. Your app will want to inspect the call IDs of all SIP messages that are ready to be transmitted by the media engine. If your app determines that the call ID for a transmitted SIP message is the same as that for a previously received INVITE request, your app can simply specify a new destination IP address and port in the SIP_MESSAGE_IMMEDIATE_DATA data structure that gets passed to your app. See the NewDestination and NewDestinationPort members of the SIP_MESSAGE_IMMEDIATE_DATA data structure in the Software Developer’s Reference for more info.
The mechanism outlined above will allow you the functionality you seek. Also, if the un-registered UAs use route headers, your VOIP app could send the ready to be transmitted SIP request to the proper route destinations as appropriate.
Support Agreement:
As an alternative, we would like to get your group into a support agreement with us. This way, when you make a request for new or modified functionality in the product, we can address your needs immediately. It’s a great advantage to have at your disposal. Surely something to think about.
Additional thoughts:
We need you and other customers like you. This product continues to evolve due to your input and all other customer input. It is the installed customer base that is helping us make the VOIP Media Engine a better product every day. Customers apply the VOIP Media Engine in application situation we never dreamed of. Its amazing.
Support
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: How to authenticate SIP requests
