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: NOTIFY – 481 reply Post ReplyPost New Topic
Author
Message << Prev Topic | Next Topic >>
mfitzgerald
Vetran
Vetran


Joined: June 14 2006
Location: United States
Posts: 142
Posted: September 11 2008 at 10:21am | IP Logged Quote mfitzgerald

I’m testing with an Asterisk PBX. I wanted to test the
480 response issue we are experiencing in a different
environment. (See post Sept. 5, 2008, Topic: 480
Questions)


I saw something interesting. The Asterisk PBX will allow
the registration process to occur, with an added message
response of 100 – Trying. Registration will be
successful.

The odd thing I’m seeing is not necessarily that the PBX
issues a NOTIFY after the successful Register. The odd
thing is that LS replies to this NOTIFY message with a
481 as apposed to a 200 – OK.

NOTE: the CSeq is unique to the issued NOTIFY
message.

Q1
Is LS trying to find a previous message, not finding it
therefore the 481 response?

Q2
If not, why am I seeing a 481?

To be complete I’ve run the same registration with the
same endpoint with a 3rd party VoIP phone.

3rd party VoIP Phone Register Log
Code:
 
========================================================
=============
Time:          09:38:28.10
Type:          SIPOutgoing
Description:     REGISTER
From:          10.9.1.243
To:          172.26.253.222:5060
========================================================
=============

REGISTER sip:172.26.253.222 SIP/2.0
Via: SIP/2.0/UDP 
10.9.1.243:5061;branch=z9hG4bK308B0BF402CA4A46B61D73BCE4
2D9414
From: "lbb IT4307 phn2" 
<sip:4307@172.26.253.222>;tag=F089C5262D3648D49AD0E7BF BE
E443FF
To: "lbb IT4307 phn2" <sip:4307@172.26.253.222>
Contact: <sip:4307@10.9.1.243:5061>
Call-ID: F0E67C51D52A4638813C4FA50CC8002A@10.9.1.243
CSeq: 2810 REGISTER
Expires: 1800
Allow: INVITE,ACK,CANCEL,REFER,BYE,NOTIFY,OPTIONS,INFO
User-Agent: WOSISIP 1.0
Max-Forwards: 70
Content-Length: 0



========================================================
=============
Time:          09:38:28.12
Type:          SIPIncoming
Description:     100 Trying
From:          172.26.253.222:5060
To:          10.9.1.243
========================================================
=============

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 
10.9.1.243:5061;branch=z9hG4bK308B0BF402CA4A46B61D73BCE4
2D9414;received=10.9.1.243
From: "lbb IT4307 phn2" 
<sip:4307@172.26.253.222>;tag=F089C5262D3648D49AD0E7BF BE
E443FF
To: "lbb IT4307 phn2" <sip:4307@172.26.253.222>
Call-ID: F0E67C51D52A4638813C4FA50CC8002A@10.9.1.243
CSeq: 2810 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 
SUBSCRIBE, NOTIFY
Contact: <sip:4307@172.26.253.222>
Content-Length: 0



========================================================
=============
Time:          09:38:28.14
Type:          SIPIncoming
Description:     200 OK
From:          172.26.253.222:5060
To:          10.9.1.243
========================================================
=============

SIP/2.0 200 OK
Via: SIP/2.0/UDP 
10.9.1.243:5061;branch=z9hG4bK308B0BF402CA4A46B61D73BCE4
2D9414;received=10.9.1.243
From: "lbb IT4307 phn2" 
<sip:4307@172.26.253.222>;tag=F089C5262D3648D49AD0E7BF BE
E443FF
To: "lbb IT4307 phn2" 
<sip:4307@172.26.253.222>;tag=as17379e06
Call-ID: F0E67C51D52A4638813C4FA50CC8002A@10.9.1.243
CSeq: 2810 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 
SUBSCRIBE, NOTIFY
Expires: 1800
Contact: <sip:4307@10.9.1.243:5061>;expires=1800
Date: Thu, 11 Sep 2008 14:38:27 GMT
Content-Length: 0



========================================================
=============
Time:          09:38:29.34
Type:          SIPIncoming
Description:     NOTIFY
From:          172.26.253.222:5060
To:          10.9.1.243
========================================================
=============

NOTIFY sip:4307@10.9.1.243:5061 SIP/2.0
Via: SIP/2.0/UDP 
172.26.253.222:5060;branch=z9hG4bK64cbb8b4
From: "Unknown" 
<sip:Unknown@172.26.253.222>;tag=as2349a4ce
To: <sip:4307@10.9.1.243:5061>
Contact: <sip:Unknown@172.26.253.222>
Call-ID: 428c99d64fd3e5831b007b091c98cdaf@172.26.253.222
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 94

Messages-Waiting: no
Message-Account: sip:asterisk@172.26.253.222
Voice-Message: 0/0 (0/0)


========================================================
=============
Time:          09:38:29.40
Type:          SIPOutgoing
Description:     200 OK
From:          10.9.1.243
To:          172.26.253.222:5060
========================================================
=============

SIP/2.0 200 OK
Via: SIP/2.0/UDP 
172.26.253.222:5060;branch=z9hG4bK64cbb8b4
From: "Unknown" 
<sip:Unknown@172.26.253.222>;tag=as2349a4ce
To: <sip:4307@10.9.1.243:5061>
Contact: <sip:4307@10.9.1.243:5061>
Call-ID: 428c99d64fd3e5831b007b091c98cdaf@172.26.253.222
CSeq: 102 NOTIFY
Content-Length: 0



LS Register Log
Code:
 ************* Log Opened (Sep 11 09:41:05) 
*************

>>>> TxTxTxTxTx (#1, [09:41:17.429] 0 Ms, To: 
172.26.253.222:5060) >>>>
REGISTER sip:172.26.253.222 SIP/2.0
Via: SIP/2.0/UDP 
10.9.1.243:5060;rport;branch=z9hG4bK295dc1b0
From: <sip:4307@172.26.253.222>;tag=295df115
To: <sip:4307@172.26.253.222>
Call-Id: 05a2f88e-cbad-49b4-b9ba-f415e726e90d-
00000288@10.9.1.243
CSeq: 6138796 REGISTER
Expires: 60
Max-Forwards: 70
Contact: <sip:4307@10.9.1.243:5060>;user=phone
User-Agent: LanScape VOIP Media Engine/5.12.8.11  
(www.LanScapeCorp.com)
X-kgb: HV1.2.2-LS5.12.8.11-ASP1.2.0.0-CTI4.7.14070.0-
VAC4.03-PA1899
Content-Length: 0



<<<< RxRxRxRxRx (#1, [09:41:17.523] 0 Ms, From: 
172.26.253.222:5060) <<<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 
10.9.1.243:5060;rport;branch=z9hG4bK295dc1b0;received=10
.9.1.243
From: <sip:4307@172.26.253.222>;tag=295df115
To: <sip:4307@172.26.253.222>
Call-ID: 05a2f88e-cbad-49b4-b9ba-f415e726e90d-
00000288@10.9.1.243
CSeq: 6138796 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 
SUBSCRIBE, NOTIFY
Contact: <sip:4307@172.26.253.222>
Content-Length: 0



<<<< RxRxRxRxRx (#2, [09:41:17.527] 4 Ms, From: 
172.26.253.222:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 
10.9.1.243:5060;rport;branch=z9hG4bK295dc1b0;received=10
.9.1.243
From: <sip:4307@172.26.253.222>;tag=295df115
To: <sip:4307@172.26.253.222>;tag=as6b5f349a
Call-ID: 05a2f88e-cbad-49b4-b9ba-f415e726e90d-
00000288@10.9.1.243
CSeq: 6138796 REGISTER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 
SUBSCRIBE, NOTIFY
Expires: 60
Contact: <sip:4307@10.9.1.243:5060>;expires=60
Date: Thu, 11 Sep 2008 14:41:17 GMT
Content-Length: 0



<<<< RxRxRxRxRx (#3, [09:41:25.990] 8463 Ms, From: 
172.26.253.222:5060) <<<<
NOTIFY sip:4307@10.9.1.243:5060 SIP/2.0
Via: SIP/2.0/UDP 
172.26.253.222:5060;branch=z9hG4bK175be8c2
From: "Unknown" 
<sip:Unknown@172.26.253.222>;tag=as12edcb73
To: <sip:4307@10.9.1.243:5060>
Contact: <sip:Unknown@172.26.253.222>
Call-ID: 746191ca2d868fc636b73fa70f24ac93@172.26.253.222
CSeq: 102 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: message-summary
Content-Type: application/simple-message-summary
Content-Length: 94

Messages-Waiting: no
Message-Account: sip:asterisk@172.26.253.222
Voice-Message: 0/0 (0/0)


>>>> TxTxTxTxTx (#2, [09:41:25.996] 8567 Ms, To: 
172.26.253.222:5060) >>>>
SIP/2.0 481 Transaction Does Not Exist
Via: SIP/2.0/UDP 
172.26.253.222:5060;branch=z9hG4bK175be8c2
From: "Unknown" 
<sip:Unknown@172.26.253.222>;tag=as12edcb73
To: <sip:4307@10.9.1.243>;tag=4ea60d00
Call-Id: 746191ca2d868fc636b73fa70f24ac93@172.26.253.222
CSeq: 102 NOTIFY
User-Agent: LanScape VOIP Media Engine/5.12.8.11  
(www.LanScapeCorp.com)
X-kgb: HV1.2.2-LS5.12.8.11-ASP1.2.0.0-CTI4.7.14070.0-
VAC4.03-PA1899
Content-Length: 0




************* Log Closed (Sep 11 09:41:31) *************


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: September 11 2008 at 12:13pm | IP Logged Quote support
Hi Fitz,

We can take both of your questions at the same time.

The Short Story:
To make a long story short, your VOIP app can handle any received NOTIFY SIP request the media engine may receive from another SIP device. Its very simple to allow your app to handle unsolicited NOTIFY requests from Asterisk.

The Long Story:
The media engine maintains the concept of received solicited and unsolicited NOTIFY requests.

Solicited NOTIFY requests are NOTIFY SIP messages that are the direct result of the media engine SUBSCRIBE-ing to a NOTIFY event that is published by another SIP device… usually some kind of SIP server. For example, If we were developing a SIP voice email client that wanted to receive “voice mail message waiting” indications from the voice mail server, then our SIP client would SUBSCRIBE to the needed events the SIP server supports. Once the SIP server receives our SUBSCRIBE requests, it send to us the proper “solicited” NOTIFY SIP messages corresponding to those events when they occur. The media engine takes the received events that are contains in the received NOTIFY messages and maps them back to the SUBSCRIBE request(s). If an event match is found, the NOTIFY request is presented to the application and the media engine responds with a “good” “200 OK” response.

If an event match is NOT found, the media engine assumes we do not accept events of this type and send out the 481 response.

Using solicited SUBSCRIBE/NOTIFY messages helps to keep network traffic down as compared to SIP devices simply sending out unsolicited NOTIFY requests even if the SIP client did not want to receive them. This is one way SUBSCRIBE/NOTIFY messages are used.

Unsolicited NOTIFY requests are exactly what the name implies – we do nothing special in our SIP app to request the reception of these NOTIFY requests… they are send by the other SIP device (or server) whenever it wants. This is what Asterisk does for voicemail waiting indications when voicemail “indication” are configured. The media engine can handle these unsolicited NOTIFY requests easily. This is another way that NOTIFY requests are used.

Documentation Snafu…

I see that our Software Developer’s Reference contains an outdated structure definition for the NOTIFY_REQUEST structure and does not contain the new API proc: SetReceivedUnsolicitedNotifyState(). We will fix this document omission today. The proper NOTIFY_REQUEST structure definition is as follows:


Code:

// structure passed back to applications when the media engine receives
// event notifications.
//
typedef struct NOTIFY_REQUEST
{
     NOTIFY_TYPE NotifyType;          // the notify request is the result of a subscription
                                      // or it is an unsolicited notify.

     char *pSrcUserName;              // the name of the device sending the event.

     char *pSrcHost;                  // the host adddress of the sender.

     DWORD SrcPort;                   // the port adddress of the sender.

     char *pEventName;                // the null terminated name of the event we are being notified about.

     char *pEventParameter;           // Depending on the sender of this event, the sender may chose to
                                      // supply this additional "user specified" event parameter string.
     
     char *pDestUserName;             // the name of the device receiving the event.

     char *pDestHost;                 // the host address of the destination.

     DWORD DestPort;                  // the port address of the destination.

     char *pSipMsgStr;                // the receive SIP message.

     int UnsolicitedNotifyResponse;   // Used only when receiving unsolicited NOTIFY requests.
                                      // Application software can set this value to a valid SIP
                                      // response code. If the applications wants to inform
                                      // the sender that the NOTIFY was accepted, it should be set to 200.
                                      // If an error response is desired, it should be set in the range 
                                      // of 400-699 depending on the specific SIP error response desired.
                                      // Generally a 400 (Invalid Request) error response is acceptable.

}NOTIFY_REQUEST;





The function prototype for the SetReceivedUnsolicitedNotifyState() proc is:

Code:


TELEPHONY_RETURN_VALUE VOIP_API SetReceivedUnsolicitedNotifyState(
          SIPHANDLE hStateMachine,
          BOOL EnableState
          );





Handling all types of received NOTIFY requests:
Your media engine will handle any received NOTIFY request automatically if it has an outstanding subscription for the event or events of the received NOTIFY.

To ensure that your app also handles unsolicited NOTIFY that are received, your app should call the SetReceivedUnsolicitedNotifyState() API procedure to enable this capability.

Once enabled, your app will be notified about unsolicited received NOTIFY SIP messages using the SipEventNotifyReceived immediate event. The NotifyType member in the NOTIFY_REQUEST structure that gets passed to your app will be set to UNSOLICITED_NOTIFY instead of the SUBSCRIPTION_NOTIFY value.

When you process the SipEventNotifyReceived immediate event, your app can access the raw SIP message and inspect the event parameters in the SIP message body and take whatever action is required. Before returning from the SipEventNotifyReceived immediate event, the app can set the UnsolicitedNotifyResponse structure member to a SIP error value in the range of 400-699 if required. By default, the unsolicited NOTIFY will be responded to using a standard “200 OK” SIP response.

This response is a bit “long winded” – hopefully this sheds more light on the subject.

Note: We are still working on the call ignore issue from the other post…. Hang on….


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: September 11 2008 at 2:50pm | IP Logged Quote mfitzgerald
I have applied the SetReceivedUnsolicitedNotifyState()
function and the 481 messages for the "Unsolicited
Notify" are not sent.

LS now sends the expected 200 - OK message.

Thank you




Back to Top View mfitzgerald's Profile Search for other posts by mfitzgerald Visit mfitzgerald'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