| Author |
|
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 20 2009 at 4:57pm | IP Logged
|
|
|
As you may know, we were able to get dual-sip support working (to some degree) with our product.
note: this is not using a full VoIP implementation. This is using additional software to split the calls up while a single LONG VoIP call stays active for voice transport. (We've described this in previous posts, not certain if we need to discuss any further detail here).
One of the things I just noticed was an improper REGISTER SIP message.
I wish I had the SIP log, but unfortunately the logging mechanism hung, but I was able to grab a screen shot of the offending message.
Scenario
1. During a signon process into this "hybrid-VoIP" environment we initialize a Registration request.
2. Once we Register, we begin the sign on process with these other applications, one which initiates an INVITE to us.
3. We have a timeout thread waiting for this INVITE to come in,
3.a If it does not we have a SIP Proxy Fail over state.
3.b In this case, we send the Registration request with (Expires: 0) {unregister}
3.c Then try a different server and re-process steps 1-3 using the new server.
4. If everything is successful, we start taking calls.
As you can tell this Dual-Sip proxy support only works on start up, however we've run some tests and have found that because the actual RTP data is handled through a different server that a Sip fail over during the LONG Sip call has no ill effects (at this time). {We are retesting everything now with LSME 6.0.0.16 just to be certain.}
The Discrepancy
In the SIP Logger app, there's a "title" to the SIP messages which come through, indicating the direction of the message the level #, timestamp and IP:Port, plus other information.
This all reports correctly, however one of the sip messages did not appear to report the IP:port correctly.
Simplified SIP Headers
Code:
>>>> .... To: 10.103.200.30:5060
REGISTER sip:10.103.200.30 SIP/2.0
From: <sip:3865@10.103.200.30>...
To: <sip:3865@10.103.200.30>
Expires: 60
<<<< .... From: 10.103.200.30:5060
SIP/2.0 200 OK <-- ok for REG request
From: <sip:3865@10.103.200.30>...
To: <sip:3865@10.103.200.30>...
Expires: 60
.
.
.
INVITE Time Out
.
.
.
>>>> .... To: 10.103.200.30:5060
REGISTER sip:10.103.200.30 SIP/2.0
From: <sip:3865:10.103.200.30>...
To: <sip:3865:10.103.200.30>
Expires: 0
<<<< .... From: 10.103.200.30:5060
SIP/2.0 200 OK
From: <sip:3865@10.103.200.30>...
To: <sip:3865@10.103.200.30>...
Expires: 0
.
Our code now switches to the new SIP Proxy
.
>>>> .... To: 10.103.200.31:5060 <-- correct IP
REGISTER sip:10.103.200.30 SIP/2.0 <-- wrong IP
From: <sip:3865@10.103.200.30>... <-- wrong IP
To: <sip:3865@10.103.200.30> <-- wrong IP
Expires: 60
.
.
.
|
|
|
Though the Register request to the new SIP Proxy didn't report withing the SIP message properly, the registration and INVITE were successful.
Unfortunately due to the SIP Logger hanging I was unable to retrieve the full SIP Log, so this is all from a screen shot. I'll see if I can't duplicate it tomorrow when we do additional tests for Dual-SIP Proxy support.
Additionally, the SIP Logger I'd used was an older version, I'll ensure its up to date for the next tests.
Thanks,
Fitz
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 10:33am | IP Logged
|
|
|
I have a SIP log for you. This version will be complete, including the INVITE.
Interesting thing, though the SIP messages report IP of 10.103.200.30, the INVITE comes from the correct IP address 10.103.200.31. How is this possible if the messages are really going to 10.103.200.30 or is this a mess-up in the REGISTER message format?
Code:
************* Log Opened (Jul 21 08:54:20) *************
>>>> TxTxTxTxTx (#1, [09:51:07.380] 0 Ms, To: 10.103.200.30:5060) >>>>
REGISTER sip:10.103.200.30 SIP/2.0
Via: SIP/2.0/UDP 10.9.1.241:5060;rport;branch=z9hG4bK51658973
From: <sip:3865@10.103.200.30>;tag=5165b8a9
To: <sip:3865@10.103.200.30>
Call-ID: ee952dba-2c91-471f-99df-853a85bee11f-00000b14@10.9.1.241
CSeq: 6649186 REGISTER
Expires: 60
Max-Forwards: 70
Contact: <sip:3865@10.9.1.241:5060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRx (#1, [09:51:07.474] 0 Ms, From: 10.103.200.30:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.9.1.241:5060;rport=5060;branch=z9hG4bK51658973;received=10.9.1.241
From: <sip:3865@10.103.200.30>;tag=5165b8a9
To: <sip:3865@10.103.200.30>;tag=0x3-2n9p0a
Call-ID: ee952dba-2c91-471f-99df-853a85bee11f-00000b14@10.9.1.241
CSeq: 6649186 REGISTER
Contact: <sip:3865@10.9.1.241:5060>;expires=60
Server: Aspect Proxy 2.0.1.8
Expires: 60
Content-Length: 0
{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}
We did not receive an INVITE so we time-out and perform our Proxy Fail-over... Unregister, then Register with new Proxy server
{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}
>>>> TxTxTxTxTx (#2, [09:51:52.185] 44805 Ms, To: 10.103.200.30:5060) >>>>
REGISTER sip:10.103.200.30 SIP/2.0
Via: SIP/2.0/UDP 10.9.1.241:5060;rport;branch=z9hG4bK51666834
From: <sip:3865@10.103.200.30>;tag=5166203a
To: <sip:3865@10.103.200.30>
Call-ID: ee952dba-2c91-471f-99df-853a85bee11f-00000b14@10.9.1.241
CSeq: 6649187 REGISTER
Expires: 0
Max-Forwards: 70
Contact: <sip:3865@10.9.1.241:5060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRx (#2, [09:51:52.253] 44779 Ms, From: 10.103.200.30:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.9.1.241:5060;rport=5060;branch=z9hG4bK51666834;received=10.9.1.241
From: <sip:3865@10.103.200.30>;tag=5166203a
To: <sip:3865@10.103.200.30>;tag=0x4-6ogh9h
Call-ID: ee952dba-2c91-471f-99df-853a85bee11f-00000b14@10.9.1.241
CSeq: 6649187 REGISTER
Server: Aspect Proxy 2.0.1.8
Expires: 0
Content-Length: 0
{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}
Now Register with new Proxy.
NOTE: the TxTxTx line indicates the correct IP address, whereas the SIP message itself still uses the old IP address.
This continues for all Register messages but not for the INVITE we receive from the correct/new IP address
{{{{{{{{{{{{{{{}}}}}}}}}}}}}}}
>>>> TxTxTxTxTx (#3, [09:52:03.209] 11024 Ms, To: 10.103.200.31:5060) >>>>
REGISTER sip:10.103.200.30 SIP/2.0
Via: SIP/2.0/UDP 10.9.1.241:5060;rport;branch=z9hG4bK516663d7
From: <sip:3865@10.103.200.30>;tag=5166933c
To: <sip:3865@10.103.200.30>
Call-ID: 1dd29283-f954-4762-ad80-5a3841e54e7c-00000b14@10.9.1.241
CSeq: 6705234 REGISTER
Expires: 60
Max-Forwards: 70
Contact: <sip:3865@10.9.1.241:5060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRx (#3, [09:52:03.278] 11025 Ms, From: 10.103.200.31:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.9.1.241:5060;rport=5060;branch=z9hG4bK516663d7;received=10.9.1.241
From: <sip:3865@10.103.200.30>;tag=5166933c
To: <sip:3865@10.103.200.30>;tag=0xa28-b6644
Call-ID: 1dd29283-f954-4762-ad80-5a3841e54e7c-00000b14@10.9.1.241
CSeq: 6705234 REGISTER
Contact: <sip:3865@10.9.1.241:5060>;expires=60
Server: Aspect Proxy 2.0.1.8
Expires: 60
Content-Length: 0
<<<< RxRxRxRxRx (#4, [09:52:07.789] 4511 Ms, From: 10.103.200.31:5060) <<<<
INVITE sip:3865@10.9.1.241:5060 SIP/2.0
Via: SIP/2.0/UDP 10.103.200.31;branch=z9hG4bKu5md94a2an1;rport
Record-Route: <sip:pa0siptest01@10.103.200.31;lr>
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241:5060>
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
Contact: <sip:15@10.103.200.31>
Max-Forwards: 70
Allow: INVITE,ACK,BYE,CANCEL,REGISTER,OPTIONS,INFO,NOTIFY,REFER,PRACK
Supported: 100rel
Server: Aspect Proxy 2.0.1.8
TrunkNumber:6
Content-Type: application/sdp
Content-Length: 352
v=0
o=- 84969 84969 IN IP4 10.103.200.21
s=Aspect Software SDP Session
c=IN IP4 10.103.200.21
t=0 0
m=audio 20032 RTP/AVP 8 0 18 101
i=telephone-event 8000
c=IN IP4 10.103.200.21
a=sendrecv
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<<<< RxRxRxRxRx (#5, [09:52:08.283] 494 Ms, From: 10.103.200.31:5060) <<<<
INVITE sip:3865@10.9.1.241:5060 SIP/2.0
Via: SIP/2.0/UDP 10.103.200.31;branch=z9hG4bKu5md94a2an1;rport
Record-Route: <sip:pa0siptest01@10.103.200.31;lr>
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241:5060>
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
Contact: <sip:15@10.103.200.31>
Max-Forwards: 70
Allow: INVITE,ACK,BYE,CANCEL,REGISTER,OPTIONS,INFO,NOTIFY,REFER,PRACK
Supported: 100rel
Server: Aspect Proxy 2.0.1.8
TrunkNumber:6
Content-Type: application/sdp
Content-Length: 352
v=0
o=- 84969 84969 IN IP4 10.103.200.21
s=Aspect Software SDP Session
c=IN IP4 10.103.200.21
t=0 0
m=audio 20032 RTP/AVP 8 0 18 101
i=telephone-event 8000
c=IN IP4 10.103.200.21
a=sendrecv
a=ptime:20
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
>>>> TxTxTxTxTx (#4, [09:52:08.660] 5451 Ms, To: 10.103.200.31:5060) >>>>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.103.200.31:5060;received=10.103.200.31;rport=5060;branch=z9hG4bKu5md94a2an1
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241:5060>
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTx (#5, [09:52:08.663] 3 Ms, To: 10.103.200.31:5060) >>>>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.103.200.31:5060;received=10.103.200.31;rport=5060;branch=z9hG4bKu5md94a2an1
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241:5060>;tag=5166a88a
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTx (#6, [09:52:08.666] 3 Ms, To: 10.103.200.31:5060) >>>>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.103.200.31:5060;received=10.103.200.31;rport=5060;branch=z9hG4bKu5md94a2an1
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241:5060>;tag=51667936
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTx (#7, [09:52:08.848] 182 Ms, To: 10.103.200.31:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.103.200.31:5060;received=10.103.200.31;rport=5060;branch=z9hG4bKu5md94a2an1
Record-Route: <sip:pa0siptest01@10.103.200.31>
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241>;tag=51667936
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 INVITE
Contact: <sip:3865@10.9.1.241:5060>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 192
Content-Type: application/sdp
v=0
o=LanScape 2147483647 2147483647 IN IP4 10.9.1.241
s=LanScape
c=IN IP4 10.9.1.241
t=0 0
m=audio 8000 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20
<<<< RxRxRxRxRx (#6, [09:52:08.920] 637 Ms, From: 10.103.200.31:5060) <<<<
ACK sip:3865@10.9.1.241:5060 SIP/2.0
Via: SIP/2.0/UDP 10.103.200.31;branch=z9hG4bKu5md94a2an2
Record-Route: <sip:pa0siptest01@10.103.200.31;lr>
From: "Aspect" <sip:15@10.103.200.21>;tag=0xa2a-49dm5u
To: <sip:3865@10.9.1.241>;tag=51667936
Call-ID: a2a@10.103.200.31fnuiq
CSeq: 1 ACK
Contact: <sip:15@10.103.200.31>
Max-Forwards: 70
Content-Length: 0
>>>> TxTxTxTxTx (#8, [09:53:03.288] 54440 Ms, To: 10.103.200.31:5060) >>>>
REGISTER sip:10.103.200.30 SIP/2.0
Via: SIP/2.0/UDP 10.9.1.241:5060;rport;branch=z9hG4bK51677deb
From: <sip:3865@10.103.200.30>;tag=516735f3
To: <sip:3865@10.103.200.30>
Call-ID: 1dd29283-f954-4762-ad80-5a3841e54e7c-00000b14@10.9.1.241
CSeq: 6705235 REGISTER
Expires: 60
Max-Forwards: 70
Contact: <sip:3865@10.9.1.241:5060>;user=phone
User-Agent: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
X-kgb: HV1.2.10-LS6.0.0.16-ASP1.2.0.0-CTI4.7.14070.0-VAC4.03-PA1899
x-VOIP-SDK: LanScape VOIP Media Engine/6.0.0.16 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRx (#7, [09:53:03.356] 54436 Ms, From: 10.103.200.31:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.9.1.241:5060;rport=5060;branch=z9hG4bK51677deb;received=10.9.1.241
From: <sip:3865@10.103.200.30>;tag=516735f3
To: <sip:3865@10.103.200.30>;tag=0xa2d-3kuzu7
Call-ID: 1dd29283-f954-4762-ad80-5a3841e54e7c-00000b14@10.9.1.241
CSeq: 6705235 REGISTER
Contact: <sip:3865@10.9.1.241:5060>;expires=60
Server: Aspect Proxy 2.0.1.8
Expires: 60
Content-Length: 0
|
|
|
Hope that proves more helpful than my hand-typed pseudo version above.
Thanks,
Fitz
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 12:03pm | IP Logged
|
|
|
Hi Fitz,
I see exactly what you are talking about. I will look into this immediately.
Great work posting the SIP log. It says everything…
Randal
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 12:10pm | IP Logged
|
|
|
Hi Fitz,
… excuse me, I did not entirely answer your previous question.
It appears in the fail over registration (to IP 10.103.200.31), the media engine is using the original “old” IP address from the first REGISTER request. I am not 100% sure at this time but it looks like a media engine bug. As you put it “this a mess-up in the REGISTER message format”.
Best,
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 1:55pm | IP Logged
|
|
|
Out of curiosity.
Are you saying, the (new) REGISTER request to (31) is actually being sent to (30) even though the >>> Tx line specifies it to be going to (31)?
If so, does this mean the INVITE we receive from (31) is outside of the scope of the REGISTER?
i.e. We are REGISTERED with (30), but our call is active with (31)?
-----
A little background info on this environment.
There are two SIP Proxies. They are both active/online, however the 3rd party application may have one as it's active proxy server. This server is the one it will send the INVITE through to start the VoIP (voice transport).
Both Proxies are capable of handling the REGISTER request and both will respond correctly, just one will not send the INVITE unless we are registered with the "active" one.
This would indicate to me, that the REGISTER to the second proxy (31) is indeed being received by the "active" proxy server (31) and not (30) even though the SIP message states so.
Am I wrong?
Fitz
P.S. The other scenario is that one sip proxy or the other is down hard (i.e. turned off/offline completely). But, we're not focusing on that just yet.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 2:13pm | IP Logged
|
|
|
Hi Fitz,
I think I located the issue…
I performed testing here using two of our LanScape Centrex SIP proxies that are deployed similarly to how your redundant Aspect SIP Proxies are deployed.
I saw the same exact results here. The VOIP media engine is using the configured VOIP domain name to fill out the REGISTER requests that are sent to your proxies. This is considered normal media engine behavior and not a bug.
Your agent station app code must be setting the VOIP domain name the media engine uses to be the IP address of your first proxy (10.103.200.30). I suspect your app code calls the EnableSipDomain() API procedure something like this:
Code:
.
.
.
status = EnableSipDomain(
hSipEngine,
"10.103.200.30"
);
.
.
.
|
|
|
If you want to make the fail over REGISTER request not use the IP address of the first SIP proxy (10.103.200.30), call the EnableSipDomain() API procedure again just before you try to re-register to the fail over proxy. Something like:
Code:
.
.
.
status = EnableSipDomain(
hSipEngine,
"10.103.200.31"
);
.
.
.
|
|
|
That way the secondary SIP messages to the second SIP proxy will look “more normal” and not so confusing. As you noted, this is simply a cosmetic thing and has not affected your VOIP functionality.
From your last post:
Your SIP REGISTER message flows are being transmitted to the proper IP:port of your proxies based on your SIP log. When you see a log line like:
Code:
>>>> TxTxTxTxTx (#8, [09:53:03.288] 54440 Ms, To: 10.103.200.31:5060) >>>>
.
.
.
|
|
|
You can be assured that the SIP message was sent to x.x.x.31:5060.
You are absolutely correct in your final SIP message flow analysis when you said:
“This would indicate to me, that the REGISTER to the second proxy (31) is indeed being received by the "active" proxy server (31) and not (30) even though the SIP message states so.”
Please repost if I have missed something.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 21 2009 at 2:54pm | IP Logged
|
|
|
Thanks for the reply and clarification.
When we were working on supporting the Dual Sip proxy support. I realized this could become complicated. So I implemented it in the simplest yet most efficient way I could think of at the time.
The proxy information is stored in a private struct array. The struct contains the Host, Port and the LastUsed timestamp (time_t).
The index is private and ONLY a locked function "SwitchProxyServer()" handles altering it. The only method in which to obtain the Host and Port are through function calls which request the "active" Host or Port. This ensures we do not have a mix-match proxy host/port for any of the required elements for LS.
With this method we ensure that we cannot accidentally grab the wrong information for:
* EnableSipDomain()
* EnableSipProxyServer()
* SendSipKeepAlive()
* EnableSipRegisterServer()
(The above functions are the 4 where the proxy information is passed.)
In the event of an INVITE timeout:
1. We unregister from the proxy,
2. Wait for verification (200 OK for the Unregister request)
3. Call the SwitchProxyServer() code, which attempts to alternate the index pending validation
4. Re-initialize LSME.
Once #3 is has been called, only access to the new proxy information is available.
Unless I have truly missed something, that should ensure that LS essentially should not know of the old sip proxy.
Is it possible I have not implemented the LS restart correctly?
Thanks,
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 21 2009 at 3:05pm | IP Logged
|
|
|
Hi Fitz,
Sometimes it’s hard to put into words what is technically going on (due to language ambiguities and assumptions). I followed the content of your last post exactly and I believe you are doing everything properly. As a matter of fact, your approach seems right on.
Regarding fail over REGISTER cycles:
1)
Have you verified that your agent station code is calling the EnableSipDomain() proc setting the new IP of x.x.x.31?
2)
Did the EnableSipDomain() proc return SipSuccess?
We must be missing something simple.
Randal
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 22 2009 at 10:57am | IP Logged
|
|
|
Thanks for the suggestion. We only logged errors on each step, so there wasn't really a way I could check to see if indeed that code was called.
Logging has been modified to report success as well as failure for each of the steps. It would appear that LS is not being restarted correctly or something is missing to properly implement a restart.
Background
Early on with our integration of LSME, we stripped out everything we didn't want/desire to simplify everything. This included restart code. When we came across the dual sip proxy, we needed the restart capability.
I'm going to dive back into the sample code for restart code, but maybe you can give a quick overview on how to properly reset/restart LSME?
Functionality Does Not Appear Affected... but
Though so far it does not appear to affect the functionality of the Dual Sip Proxy support, it is not desirable (at least by my standards). And I'd rather corral any possible trickle-down effects this may cause.
Thanks,
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 22 2009 at 11:00am | IP Logged
|
|
|
To address your question, no it does not appear as though EnableSipDomain() is being called after the fail-over.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: July 22 2009 at 1:21pm | IP Logged
|
|
|
Hi Fitz,
Ok... I understand. Maybe you can repost further info when you get your app code updated. I know what you mean regarding “functionality not being affected”. I would make the change too.
I will be in and out of support mode today, tomorrow and Friday so I will respond to posts as soon as possible.
Thank you,
Randal
p.s. Any further info regarding the support PO that has been issued by Glenn?
|
| Back to Top |
|
| |
mfitzgerald
Vetran
Joined: June 14 2006
Location: United States
Posts: 142
|
| Posted: July 22 2009 at 1:58pm | IP Logged
|
|
|
Quote:
| p.s. Any further info regarding the support PO that has been issued by Glenn? |
|
|
<<< Fitz
The only thing I know, is that it is still in the works. I'll ping Glenn on it and let you know if there's some change.
Native Dual Sip Proxy Support in LSME
I also understand it would be preferred (by myself and I'm certain a few others) if LSME naively handled Dual Sip Proxy instead of us having to build this "hack" which will undoubtedly have certain limitations/exceptions.
Though we seem to be able to handle a sip failure even during a sign on "session" (i.e. LSME Registered and VoIP call active). When there is a problem, we can't/don't sign out properly due to the a failure of the proxy LS has registered with not responding as LS expects it so. Thankfully we are able to continue taking calls until the sign out, so this does not affect business. But, our application must be restarted to clear everything correctly before we can allow a new sign on "session."
The thing we will be testing today is a hard fail (i.e. not that Aspect has assigned a different proxy as active, but rather the proxy failure results in no communication with the proxy--network failure/power failure/etc).
Question
What I wonder is, how will LS handle the situation when the keep-alive messages do not occur with the REGISTERed proxy.
Further Updates regarding this issue
Unless this affects us functionally (and that does not appear to be the case). I'll have to focus on other more pressing matters and revisit this as time permits.
Thanks,
Fitz
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Incorrect IP in SIP REG
