Re: Re: [nist-sip-dev] what to do when NOTIFY arrives before OK on SUBSCRIBE ?
"M. Ranganathan" <[email protected]>
| Newsgroups | gmane.comp.voip.nist-sip |
|---|---|
| Message-ID | <[email protected]> |
Jeroen, Frederik,
Thanks. RFC 3265 is joyful indeed. I did things a bit differently than
suggested by Jeroen. I am not sure all cases below in Jeroen's
pseudocode are covered. In the RI, I search through the pending
Subscribe Transactions see SIPTransactionStack.findSubscribeTransaction
(which is slow but simple - I will revise that for better performance if
time permits). In any case, I hacked away at the bugs, put some tighter
error checking into the code and other things and have committed the
results to CVS on the nist CVS repository. For the benifit of those who
are behind unforgiving firewalls, I updated the zip on java.net.
Frederik, please give it a try and let me know if it behaves as
expected. I am not sure if all cases for Forked Subscriptions are
correctly handled. Please take a look at examples/forked/subscribe if
you have the time and let me have your feedback.
Thats 'nuff SUBSCRIBE NOTIFY for a while me thinks !
Ranga
Jeroen van Bemmel wrote:
> 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!
>>
>
>
> _______________________________________________
> 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!