Re: Re: [nist-sip-dev] what to do when NOTIFY arrives before OK on SUBSCRIBE ?

Ranga,

No-one said it would be easy... ;)

For the procedure below to work, a first necessary step is to create and 
maintain a { From-tag + call-id } -> dialog mapping even before sending out 
the SUBSCRIBE. You also need to store the Event header with the dialog. 
Conceptually, you would have a Dialog object and a SubscribeUsage object 
(the latter consisting of the Event header, expiry timers, and more)

Side note: (IMHO) ideally, the API would be extended to support 
SUBSCRIBE/NOTIFY better. You need to watch out not to create the dialog 
mapping for proxy applications, one way to do this is to distinguish between 
received SUBSCRIBE requests and locally generated ones (using some flag).

Then, when a NOTIFY arrives, you would do the following (pseudo code):

0. If a ST already exists, it would filter out retransmitted NOTIFY. So 
below, assume it is a new one
1. Dialog match = dialogs.lookup( Notify.to-tag + Notify.call-id );    // 
Note: use ~to~ tag here
2. if no match: send 481 (best without creating a ServerTransaction, to 
mitigate DoS attacks)
3. if match: check match.eventHeader == Notify.eventHeader, send 481 if no 
match (again, no ST)
4. if (match.remote-tag==null) {
      set match.remote.tag = Notify.from-tag
    }
    if (match.remote-tag == Notify.from-tag) {    // either set above or 
SUBSCRIBE 2xx was already received
    create ST, associate with {match} dialog
    pass to application (subscription state may be terminated)
   } else {
        Dialog forked = match.forkedDialogs[ Notify.from-tag  ]  // use 
Notify.from-tag as index into a map of 'forked dialogs' associated with 
{match}
        if (forked==null) {
            forked = new forked dialog associated with match (i.e. put in 
match.forkedDialogs)    // may need to set forked.application_data = 
match.application_data here
        }
        create ST, associate with {forked} dialog
        pass to application (subscription state may be terminated)
   }

Note that some of the code can be reordered to avoid duplication. It does 
get quite complicated, but this is necessary if you want to fully support 
all the joys RFC3265 brings us.

Once you have this, you can use the same principles to support forked 
INVITEs

Regards,

Jeroen

----- Original Message ----- 
From: "M. Rangnathan" <[email protected]>
To: "Jeroen van Bemmel" <[email protected]>
Cc: "Bayart, Frederik" <[email protected]>; 
<[email protected]>; "sip mailing" <[email protected]>
Sent: Sunday, April 16, 2006 6:53 PM
Subject: Re: [nist-sip] Re: [nist-sip-dev] what to do when NOTIFY arrives 
before OK on SUBSCRIBE ?


> Jeroen,
>
> I think the proceedure to use in matching the NOTIFY to an uncompleted 
> SUBSCRIBE is a bit more complicated that what I inferred from your scheme 
> below. Here's the paragraph from the Subscribe Notify RFC
>
> NOTIFY requests are matched to such SUBSCRIBE requests if they contain the 
> same "Call-ID", a "To" header "tag" parameter which matches the "From" 
> header  "tag" parameter of the SUBSCRIBE, and the same "Event" header 
> field.  Rules for comparisons of the "Event" headers are described in 
> section 7.2.1. If a matching NOTIFY request contains a 
> "Subscription-State" of  "active" or "pending", it creates a new 
> subscription and a new dialog  (unless they have already been created by a 
> matching response, as described above).
>
> I did have such a checking method but was not calling it when creating the 
> server tx for the incoming Notify.
>
> Comments?
>
> Ranga
>
>
> Jeroen van Bemmel wrote:
>
>> Ranga,
>>
>> There is a problem here: How will the application match the NOTIFY with a 
>> subscription it initiated? And who (application or stack) is supposed to 
>> send "481 call/transaction does not exist" when the NOTIFY does not match 
>> an existing subscription?
>>
>> My approach is to maintain dialogs using { from-tag + call-id } as key. 
>> Then, when a NOTIFY comes in, this is used to lookup the corresponding 
>> SUBSCRIBE-initiated dialog, and 481 is sent when it does not exist.
>>
>> The above setup is also needed to support forking: when multiple NOTIFYs 
>> with different from-tags arrive, N dialogs should be created. If you only 
>> create the dialog upon SUBSCRIBE 200 OK, it won't work (since other 2xx 
>> responses may get filtered by proxies)
>>
>> Regards,
>>
>> Jeroen
>>
>> ----- Original Message ----- From: "M. Rangnathan" <[email protected]>
>> To: "Bayart, Frederik" <[email protected]>
>> Cc: <[email protected]>; "sip mailing" <[email protected]>
>> Sent: Sunday, April 16, 2006 5:28 AM
>> Subject: [nist-sip] Re: [nist-sip-dev] what to do when NOTIFY arrives 
>> before OK on SUBSCRIBE ?
>>
>>
>>> Hi Frederik,
>>>
>>> This case is working. I modified the examples/subsnotify to send notify 
>>> first. My original answer was wrong. Yes the getServerTransaction should 
>>> indeed return a null pointer, This is because the dialog has not yet 
>>> been established by the Subscribe (it gets established on an OK). You 
>>> can create one using sipProvider.getNewServerTransaction().
>>>
>>> I have committed the new example to the nist cvs repository.
>>>
>>> Ranga
>>> Bayart, Frederik wrote:
>>>
>>>> Hallo Ranga,
>>>>
>>>> Did you had time to look at this problem ?
>>>>
>>>> Best regards,
>>>>
>>>> Frederik
>>>>
>>>> -----Original Message-----
>>>> From: M. Ranganathan [mailto:[email protected]]
>>>> Sent: Monday, March 20, 2006 8:06 PM
>>>> To: Bayart, Frederik
>>>> Cc: [email protected]
>>>> Subject: Re: [nist-sip-dev] what to do when NOTIFY arrives before OK on
>>>> SUBSCRIBE ?
>>>>
>>>>
>>>> Hi Frederik,
>>>>
>>>> It should not return a null pointer. I will check and fix the bug if it 
>>>> exists.
>>>>
>>>> Ranga
>>>>
>>>> If you can Bayart, Frederik wrote:
>>>>
>>>>
>>>>> Hallo,
>>>>>
>>>>> Can someone tell me how to proceed in the next case :
>>>>>
>>>>> |  SUBSCRIBE       |
>>>>> | ---------------> |
>>>>> |                  |
>>>>> |    NOTIFY        |
>>>>> | <--------------- |
>>>>> |                  |
>>>>> |    OK SUBSCRIBE  |
>>>>> | <--------------- |
>>>>>
>>>>>
>>>>> If the NOTIFY arrives before the OK on the SUBSCRIBE, the call to 
>>>>> event.getServerTransaction( ) in the function processRequest( 
>>>>> RequestEvent event ) returns a null pointer. According to me, this is 
>>>>> because the OK on the subscribe is not arrived yet. So I can't reply 
>>>>> on the NOTIFY (with the function 
>>>>> event.getServerTransaction( ).sendResponse). What is the way to detect 
>>>>> this case and to proceed ?
>>>>>
>>>>> Regards,
>>>>>
>>>>> Frederik
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> nist-sip-dev mailing list
>>>>> [email protected]
>>>>> http://fs4.antd.nist.gov/mailman/listinfo/nist-sip-dev
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> M. Ranganathan
>>> Advanced Networking Technologies Division,
>>> National Institute of Standards and Technology (NIST),
>>> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. tel:301 975 3664 , 
>>> fax:301 590 0932 http://w3.antd.nist.gov/
>>> Advanced Networking Technologies For the People!
>>>
>>>
>>> _______________________________________________
>>> nist-sip mailing list
>>> [email protected]
>>> http://www-x.antd.nist.gov/mailman/listinfo/nist-sip
>>
>>
>>
>> _______________________________________________
>> nist-sip-dev mailing list
>> [email protected]
>> http://fs4.antd.nist.gov/mailman/listinfo/nist-sip-dev
>
>
>
> -- 
> M. Ranganathan
> Advanced Networking Technologies Division,
> National Institute of Standards and Technology (NIST),
> 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. tel:301 975 3664 , 
> fax:301 590 0932 http://w3.antd.nist.gov/
> Advanced Networking Technologies For the People!
>