Return to LanScape's home page Go back a page...       Active TopicsActive Topics   Display List of Forum MembersMember List   Knowledge Base SearchSearch   HelpHelp  RegisterRegister  LoginLogin

LanScape VOIP Media Engine™ - Technical Support
 LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Subject Topic: Forced Sip Header Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 18 2006 at 7:38pm | IP Logged Quote mfitzgerald
I’ve read the thread regarding custom headers as outlined here:

Are Custom SIP headers supported?

I understand it is not necessarily completely supported. However I have been trying to work on a situation to force a REFER SIP Header. I have been able to format the following SIP Header, which does receive a reply, however it is not the desired 202 response I want.

Note: the phone number has been converted to 999555….

Code:

REFER sip:9995552474@10.2.2.75 SIP/2.0
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK0c2b446c
From: <sip:4307@172.26.253.176>;tag=c2b1953
To: <sip: 9995552474@10.2.2.75>
Call-Id: 3B5AF11800001F30@somewhere.com
CSeq: 2 REFER
Refer-To: sip:3307@172.26.253.176:5061
Max-Forwards: 70
Contact: <sip:4307@172.26.253.176>
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 0



This is as close as I seem to be able to get to the proper REFER header. The examples I have seen use <sips: not <sip: however I’ve been informed by our VOIP PBX that they don’t support sips anyway. I have however noticed for some reason even though I have set the Refered-By header line, it seems before it is sent out that LanScape strips that line completely from the header.

Why would LanScape strip that custom line from the SIP Header?

I need some sort of solution to this problem.

Thanks
Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 19 2006 at 10:39am | IP Logged Quote mfitzgerald
The proper line would be:

Referred-By: 4307@172.26.253.176
Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: October 23 2006 at 8:50am | IP Logged Quote support
Hi Fitz,

The internals of the media engine is probably filtering out the “Referred-By:” header you are specifying probably because it thinks it’s an illegal header for the SIP context or it could be a bug.

Adding, deleting or modifying SIP header is allowed if you add/modify/delete custom headers but not all standard header combinations may be allowed.

A custom header is any header that begins with an “x-“ as per the SIP RFC.

To see if this is true, specify the

“Referred-By:”

header as a custom header like this:

“x-Referred-By:”

and see if it then gets included in your modified transmitted SIP message. If it does, then the media engine is filtering out the standard “Referred-By:” header and we will have to look into it.

Are you trying to “synthesize” attended call transfer? If you are and there is a scenario that will work for you, let us know and we will assist as much as we can.


Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 23 2006 at 9:14am | IP Logged Quote mfitzgerald
Yes, I am attempting to synthesize an unattended call transfer. I have formatted the first (REFER) header correctly after a lot of trial and error.

I have been informed by our PBX provider the Referred-by line is optional, unless you are using Cisco products. At this time that is not an issue, in the near future it may be. Hopefully by that time the new Engine with true/full support for REFER/NOTIFY transfers will be available.

I believe I have a solution for the current situation that will work.
Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 23 2006 at 6:30pm | IP Logged Quote mfitzgerald
The steps required for an unattended REFER/NOTIFY transfer that I am concerned about are:

Code:

SoftPhone(LS)         ;  PBX
REFER ------------- +
     + ----------     202
     + ----------     NOTIFY
200     -------------- +
BYE     -------------- +
     + ----------     200
--PBX works w/ 3rd party--
     + ----------     NOTIFY
200     -------------- +


I have formatted the REFER to work, and I catch the incoming 202 without issue. I receive the Notify as well. Using the incoming data from the incoming NOTIFY I am able to construct the TO and FROM tag data, Via header, and the Event, Subscription-State and Content-Type.

I have asked the PBX provider if those last fields are required as it appears LS is filtering them out.

I have included the log.

Here is the attempted 200 SIP Header.

Code:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22d-3
From: <sips:9995552474@10.2.2.75>;tag=t1161643906-co559
To: <sips:4307@172.26.253.176>;tag=115aebee
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 2 NOTIFY
Event: refer
Subscription-State: active
Content-Type: message/sipfrag
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Contact: <sip:9995552474@10.2.2.75:5060>
Content-Length: 0


I am going to assume there is no way to keep LS from filtering out these headers. If this is the case and these header fields are required it would appear as though I am stuck.

You may want a little explanation as to how I’m able to generate SIP Headers as desired. It’s dirty but so far it works. I have a state flag that keeps track of where I am in the transfer. To send SIP Headers I have set the on and off hold as a toggled function. Simply call the function and LS sends a SIP Header. Modify the header before it goes out to the desired header and hopefully if you’ve done it correctly, good things will happen.

Required data elements such as tag data and Via and Call-ID have been grabbed from earlier SIP messages (i.e. REGISTER and INVITE). Both To and From fields MUST have a unique tag= data (at least with the PBX we use). If the PBX sends a SIP Header you are responding to, you must use the same tag data. If you are sending, the tag data can apparently be used from a previous SIP Header. The Via field follows similarly.

The incoming SIP Headers from the PBX are intercepted and modified to what LS expects from a successful on/off hold request. Any additional SIP Headers sent or received are set to “\r\n\r\n”. It’s nasty, but you won’t give LS or the PBX any location on which to throw unexpected/undesired SIP Headers.

If you require more details please, let me know. I am will need to know if this is going to work by Wednesday.

Code:

************* Log Opened (Oct 23 17:51:30) *************

<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (23359 Ms, From: 10.2.2.75:5060) <<<<
INVITE sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22f-1
To: <sip:4307@172.26.253.176:5060>
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
Date: Mon, 23 Oct 2006 22:51:46 GMT
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43660 INVITE
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO559-CPO00978
Content-Type: application/sdp
Content-Length: 279

v=0
o=- 4278766365 4278766365 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.79
t=0 0
m=audio 9676 RTP/AVP 8 0 4 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv


>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (23547 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453d 4782-22f-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
To: <sip:4307@172.26.253.176:5060>;ocld=sip:2142701805@10. 2.2.75>
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43660 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (15 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453d 4782-22f-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
To: <sip:4307@172.26.253.176:5060>;ocld=sip:2142701805@10. 2.2.75>;tag=115aebee
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43660 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (516 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453d 4782-22f-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
To: <sip:4307@172.26.253.176>;tag=115aebee;ocld=sip:214270 1805@10.2.2.75>
Call-Id: 453d4782000003d100000013724ff612@ens.com
CSeq: 43660 INVITE
Contact: <sip:4307@172.26.253.176:5060>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 179
Content-Type: application/sdp

v=0
o=LanScape 3370632707 3370632707 IN IP4 172.26.253.176
s=LanScape
c=IN IP4 172.26.253.176
t=0 0
m=audio 8184 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendrecv
a=ptime:20


<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (719 Ms, From: 10.2.2.75:5060) <<<<
ACK sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22f-2
To: <sip:4307@172.26.253.176:5060>;tag=115aebee;ocld=sip:2 142701805@10.2.2.75>
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43660 ACK
Max-Forwards: 70
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO559-CPO00978
Content-Length: 0



>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (5859 Ms, To: 10.2.2.75:5060) >>>>
INVITE sip:9995552474@10.2.2.75 SIP/2.0
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK115abcdb
From: <sip:4307@172.26.253.176>;tag=115aebee
To: <sip:9995552474@10.2.2.75>;tag=t1161643906-co559
Contact: <sip:4307@172.26.253.176:5060>
Call-Id: 453d4782000003d100000013724ff612@ens.com
CSeq: 43661 INVITE
Max-Forwards: 70
Content-Length: 170
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Type: application/sdp

v=0
o=LanScape 291159218 291159218 IN IP4 172.26.253.176
s=LanScape
c=IN IP4 0.0.0.0
t=0 0
m=audio 8184 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendonly
a=ptime:20



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (5844 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK115abcdb
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
From: <sip:4307@172.26.253.176:5060>;tag=115aebee;ocld=sip:2 142701805@10.2.2.75>
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43661 INVITE
Contact: <sip:4307@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Content-Type: application/sdp
Content-Length: 151

v=0
o=- 4278766365 4278766365 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.79
t=0 0
m=audio 9676 RTP/AVP 18
a=rtpmap:18 G729/8000
a=sendrecv


>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (2063 Ms, To: 10.2.2.75:5060) >>>>
REFER sip:9995552474@10.2.2.75 SIP/2.0
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK115abcdb
From: <sip:4307@172.26.253.176>;tag=115aebee
To: <sip:9995552474@10.2.2.75>;tag=t1161643906-co559
Call-Id: 453d4782000003d100000013724ff612@ens.com
CSeq: 2 REFER
Refer-To: sip:3307@172.26.253.176:5061
Max-Forwards: 70
Contact: <sip:4307@172.26.253.176>
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Referrred-By: 4307@172.26.253.176
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (4078 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK115abcdb
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
From: <sip:4307@172.26.253.176:5060>;tag=115aebee;ocld=sip:2 142701805@10.2.2.75>
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43661 INVITE
Contact: <sip:4307@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Content-Type: application/sdp
Content-Length: 163

v=0
o=- 4278766365 4278766366 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.79
t=0 0
m=audio 9676 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv


<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (156 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK115abcdb
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
From: <sip:4307@172.26.253.176>;tag=115aebee
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 2 REFER
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (110 Ms, From: 10.2.2.75:5060) <<<<
NOTIFY sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22d-3
To: <sip:4307@172.26.253.176:5060>;tag=115aebee;ocld=sip:2 142701805@10.2.2.75>
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43670 NOTIFY
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
Subscription-State: active
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Event: refer
Content-Type: message/sipfrag
Content-Length: 18

SIP/2.0 100 Trying

>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (2625 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22d-3
From: <sips:9995552474@10.2.2.75>;tag=t1161643906-co559
To: <sips:4307@172.26.253.176>;tag=115aebee
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 2 NOTIFY
Contact: <sip:9995552474@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (2359 Ms, From: 10.2.2.75:5060) <<<<
NOTIFY sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453d4782-22d-4
To: <sip:4307@172.26.253.176:5060>;tag=115aebee;ocld=sip:2 142701805@10.2.2.75>
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161643906-co559
Call-ID: 453d4782000003d100000013724ff612@ens.com
CSeq: 43680 NOTIFY
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
Subscription-State: active
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO557-CPO00978
Event: refer
Content-Type: message/sipfrag
Content-Length: 14




************* Log Closed (Oct 23 17:52:13) *************


Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: October 24 2006 at 1:38pm | IP Logged Quote support
Hi Fitz,

We see what you are trying to do. Its pretty “gutsy” for you to attempt this on your own and we respect that. We appreciate you taking the time to craft a well formulated problem description. Thanks.

If we understand you, it would appear that a good “general” solution for you would be for us to add an “undocumented” API procedure to the media engine that would allow you to send ANY application formulated SIP message to any IP:port destination (the Entice PBX) without the media engine trying to associate it with a particular SIP dialog. This approach may have other possible benefits too. Application formulated SIP messages would be outside the control of the media engine and be transmitted/received symmetrically using the same SIP IP address and UDP port that is used by the media engine

If we allowed the media engine to transmit any UDP packet data on behalf of the application, it would also remove the requirement to play games with call hold generation. In this case, the media engine would not inspect the UDP packet data your app wants to transmit. It would simply send it to the destination you specify. Handling received SIP messages would be handled as you are doing now – with the processing of the SipModifySipMessage immediate event.

Item 1:
Is the tag problem in the “200 OK” SIP message the only problem you currently see? In other words: If you can solve the tag problem in the “200 OK” SIP message you are trying to transmit, will your current solution be acceptable for your deployment and allow you to proceed?

Item 2:
If you were given the ability to transmit application formulated SIP messages to any IP:port, would this help you?

Item 3:
If we perform the development and testing to get you a custom media engine that will get you the solution you require, we will have to do it under a short term contract situation. Please send and email to our CTO for further details. We must have a minimum 5 day commitment from you. One of our developers will be reserved for this work. I have checked and you have the “green light” to request this from us anytime. I think you have the contact info for our CTO so send him an email for further details.

Repost as needed,


Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 24 2006 at 2:47pm | IP Logged Quote mfitzgerald
Awesome reply.

That would be a great feature in the LanScape Engine. To make SIP Headers from scratch as needed and send as needed. That would solve some issues between implementations of different RFC types. This appears to be part of the problem here.

I have been using two documents to format the SIP Headers from scratch. The first indicated the transfer as I outlined above, with the BYE from the SoftPhone and 200 returned from the PBX.

Based on that I assumed the second NOTIFY I received from the PBX was a retry after a bad/poorly formatted 200 reply from me.

The second document did not include a BYE message at all and (after the work between the PBX and the 3rd party phone) the PBX would send the second NOTIFY w/o having received a BYE from the SoftPhone.

Thus it is my assumption that the second NOTIFY is actually the ending SIP message from the PBX.

I am awaiting confirmation from the PBX provider at this time regarding this issue.

Working with the assumptions I have put together above it appears as though everything is formatted correctly and I get ALL the expected SIP Headers from the PBX (though I do have that odd 200 after the REFER – that question has also been posted to the PBX provider)

So it would appear now the issues are on the PBX side of things.

Hopefully the issues regarding the LanScape filtering the SIP Headers may not cause any further issues, with the exception as previously stated the requirements for CISCO systems.



Code:

************* Log Opened (Oct 24 14:00:48) *************

<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (10328 Ms, From: 10.2.2.75:5060) <<<<
INVITE sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-164-1
To: <sip:4307@172.26.253.176:5060>
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
Date: Tue, 24 Oct 2006 19:01:19 GMT
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64620 INVITE
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO356-CPO00047
Content-Type: application/sdp
Content-Length: 279

v=0
o=- 4294662461 4294662461 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.73
t=0 0
m=audio 6392 RTP/AVP 8 0 4 18 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000
a=rtpmap:18 G729/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv


>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (10360 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453e 62ff-164-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
To: <sip:4307@172.26.253.176:5060>;ocld=sip:2142701805@10. 2.2.75
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64620 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (0 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453e 62ff-164-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
To: <sip:4307@172.26.253.176:5060>;ocld=sip:2142701805@10. 2.2.75;tag=15ae4699
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64620 INVITE
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 0




>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (515 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;received=10.2.2.75;branch=z9hG4bK1a02024b453e 62ff-164-1
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
To: <sip:4307@172.26.253.176>;tag=15ae4699;ocld=sip:214270 1805@10.2.2.75
Call-Id: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64620 INVITE
Contact: <sip:4307@172.26.253.176:5060>
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Length: 179
Content-Type: application/sdp

v=0
o=LanScape 3370705279 3370705279 IN IP4 172.26.253.176
s=LanScape
c=IN IP4 172.26.253.176
t=0 0
m=audio 8338 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendrecv
a=ptime:20


<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (563 Ms, From: 10.2.2.75:5060) <<<<
ACK sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-164-2
To: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64620 ACK
Max-Forwards: 70
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO356-CPO00047
Content-Length: 0



>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (5141 Ms, To: 10.2.2.75:5060) >>>>
INVITE sip:9995552474@10.2.2.75 SIP/2.0
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK15ae14b7
From: <sip:4307@172.26.253.176>;tag=15ae4699
To: <sip:9995552474@10.2.2.75>;tag=t1161716479-co356
Contact: <sip:4307@172.26.253.176:5060>
Call-Id: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64621 INVITE
Max-Forwards: 70
Content-Length: 170
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Content-Type: application/sdp

v=0
o=LanScape 363730062 363730062 IN IP4 172.26.253.176
s=LanScape
c=IN IP4 0.0.0.0
t=0 0
m=audio 8338 RTP/AVP 18
a=rtpmap:18 G729/8000/1
a=sendonly
a=ptime:20



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (5140 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK15ae14b7
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
From: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64621 INVITE
Contact: <sip:4307@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Content-Type: application/sdp
Content-Length: 151

v=0
o=- 4294662461 4294662461 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.73
t=0 0
m=audio 6392 RTP/AVP 18
a=rtpmap:18 G729/8000
a=sendrecv


>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (2063 Ms, To: 10.2.2.75:5060) >>>>
REFER sip:9995552474@10.2.2.75 SIP/2.0
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK15ae14b7
From: <sip:4307@172.26.253.176>;tag=15ae4699
To: <sip:9995552474@10.2.2.75>;tag=t1161716479-co356
Call-Id: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 2 REFER
Refer-To: sip:3307@10.2.2.75:5062
Max-Forwards: 70
Contact: <sip:4307@172.26.253.176>
User-Agent: LanScape VOIP Media Engine/5.12.3.7 (www.LanScapeCorp.com)
Referrred-By: 4307@172.26.253.176
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (4063 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK15ae14b7
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
From: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64621 INVITE
Contact: <sip:4307@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Content-Type: application/sdp
Content-Length: 163

v=0
o=- 4294662461 4294662462 IN IP4 10.2.2.75
s=ENS Session
c=IN IP4 10.2.2.73
t=0 0
m=audio 6392 RTP/AVP 18
a=rtpmap:18 G729/8000
a=ptime:20
a=sendrecv


<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (62 Ms, From: 10.2.2.75:5060) <<<<
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP 172.26.253.176:5060;rport;branch=z9hG4bK15ae14b7
To: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
From: <sip:4307@172.26.253.176>;tag=15ae4699
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 2 REFER
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (47 Ms, From: 10.2.2.75:5060) <<<<
NOTIFY sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-162-3
To: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64630 NOTIFY
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
Subscription-State: active
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Event: refer
Content-Type: message/sipfrag
Content-Length: 18

SIP/2.0 100 Trying

>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (2421 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-162-3
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
To: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64630 NOTIFY
Contact: <sip:9995552474@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Content-Length: 0



<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRx (2313 Ms, From: 10.2.2.75:5060) <<<<
NOTIFY sip:4307@172.26.253.176:5060 SIP/2.0
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-162-4
To: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64640 NOTIFY
Max-Forwards: 70
Contact: <sip:9995552474@10.2.2.75:5060>
Subscription-State: active
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Event: refer
Content-Type: message/sipfrag
Content-Length: 14

SIP/2.0 200 OK

>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (2329 Ms, To: 10.2.2.75:5060) >>>>
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.2.2.75:5060;branch=z9hG4bK1a02024b453e62ff-162-4
From: <sip:9995552474@10.2.2.75:5060>;tag=t1161716479-co356
To: <sip:4307@172.26.253.176:5060>;tag=15ae4699;ocld=sip:2 142701805@10.2.2.75
Call-ID: 453e62ff0000002e00000013724ff612@ens.com
CSeq: 64640 NOTIFY
Contact: <sip:9995552474@10.2.2.75:5060>
User-Agent: Entice_2.2__Build_95-INST1-RMRG0-RG4-EP1502-CO354-CPO00047
Content-Length: 0


************* Log Closed (Oct 24 14:08:06) *************


Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: October 24 2006 at 3:11pm | IP Logged Quote support
Fitz,

Ok, Good work. Just let us know if you need us to be in the loop or not.

Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: October 24 2006 at 3:19pm | IP Logged Quote mfitzgerald
Oops

The Refer-To Line had the wrong port.
Code:

Refer-To: sip:3307@10.2.2.75

Didn’t fix the problem though.

I have forwarded your proposal of 5 days to those who have the say.

Thanks.
Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: November 10 2006 at 10:31am | IP Logged Quote mfitzgerald
EUREKA!!!

Got it. Actually I had it two weeks ago. The problems were a combination of different things.

The refer-to line had re-formatting issues after submitted to the LS MediaEngine. As you can see the 202 response was received.
The PBX had some resource group permissions that would caused the transfer to fail in certain cases. There were some misunderstandings regarding the flow for the unattended transfer our PBX uses as well. Upon further review of the RFC document pertaining to the REFER-NOTIFY transfer and testing with a pre-existing Soft Phone reviewing the log files the proper flow and format was set.


The end solution was to first put the phone on hold, and capture the incoming 200 message from the PBX, only the lines necessary to fool LanScape (LS) into thinking all subsequent on/off-holds were successful. This involved recording everything that did not have specific identifying fields, such as the via field (due to the branch ID field), to and from (due to the tag ID field), and the CSeq.

I ended up using the ID fields from the on-off hold toggles from LS to format the ID fields in the outgoing SIP Message, with necessary alterations regarding the nature of the SIP Message. These ID fields were used to validate the response SIP Messages.

I had noticed on performing a normal on-off hold request, the flow was as follows:

Code:

LS         &nbs p;     PBX
INVITE (hold) --->
     <------ 200 OK
ACK ------->


However during the transfer even the initial on-hold request (completely un-modified headers) LS never sent out the ACK. This explains the resend of the 200 message from the PBX during the transfer. I do not know why LS did not send the expected ACK, I have a suspicion however it does not cause any ill effects for the transfer so given time I may look into that.



Any unexpected SIP Headers (except an outgoing ACK for the initial on-hold) coming or going were converted to “\r\n\r\n” to hopefully keep anything destroying the transfer session. If LS/PBX didn’t know who the header was from, then it couldn’t send a response and cause the transfer to die.

Code:

LS         &nbs p;PBX
REFER ==>
<== 202 Accepted
BYE 1 ==>
<== NOTIFY 1/trying
200 OK/NOTIFY 1 ==>
NOTIFY 1/200 OK <==
200 OK/NOTIFY 2 ==>
<== BYE 2
200 OS/BYE 2 ==>
<== 200 OK/BYE 1


Several additional scenarios had to be taken into account. But it works.

As mentioned previously, this transfer hack will not work with Cisco as some of the SIP Header lines are removed from the SIP Message by LS in attempt to validate the SIP Message.

I only hope LS will have the new Media Engine available by the time we need attended transfers. I looked at that, and the hack would be a nightmare!!!

One issue however. I don’t exactly understand this. But if LS was already on hold, before performing the hack transfer, LS would lock up if the hack transfer was started with taking the phone off hold. The very quick fix was to check the state, and take the phone off hold before performing the hack transfer.

I could go into more detail if anyone is looking for more specifics on this hack.
Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald's Homepage
 
support
Administrator
Administrator


Joined: January 26 2005
Location: United States
Posts: 1666
Posted: November 10 2006 at 11:21am | IP Logged Quote support
Hi Fitz,

You have put forth a tremendous effort. Good work. We are working on the next release for the media engine that will handle these REFER/NOTIFY scenarios and add other needed functionality. It just takes time to get it all done and tested.

Sometimes hacking is good! :)

Support
Back to Top View support's Profile Search for other posts by support Visit support's Homepage
 

If you wish to post a reply to this topic you must first login
If you are not already registered you must first register

  Post ReplyPost New Topic
Printable version Printable version

Forum Jump
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot delete your posts in this forum
You cannot edit your posts in this forum
You cannot create polls in this forum
You cannot vote in polls in this forum





Contact LanScape Hear what the Lawyers have to say How youm may use this site Read your privacy rights