[asterisk-dev] [Code Review] handle_request_subscribe is too slow cause of iterating through all sip dialogs

[Russell Bryant]

> On 2010-09-03 16:32:01, schmidts wrote:
> > i´ve read the RFC 3265 to find an answer how asterisk should handle these subscribes and i would understand chapter 4.4.9. as following:
> > If such behavior is not allowed, the first potential dialog-
> >    establishing message will create a dialog.  All subsequent NOTIFY
> >    messages which correspond to the SUBSCRIBE message (i.e., match "To",
> >    "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event",
> >    and "Event" header "id" parameter) but which do not match the dialog
> >    would be rejected with a 481 response.
> > 
> > this means a client should response with a "481 Subscription does not exist" which will cause asterisk to delete this subscription.
> > 
> > and also chapter 3.3.4
> > 
> > Responses are matched to such SUBSCRIBE requests if they contain the
> >    same the same "Call-ID", the same "From" header "tag", and the same
> >    "CSeq".  Rules for the comparison of these headers are described in
> >    SIP [1].  If a 200-class response matches such a SUBSCRIBE request,
> >    it creates a new subscription and a new dialog (unless they have
> >    already been created by a matching NOTIFY request; see below).
> > 
> > so i would say it wouldnt be a RFC Violence to keep old subscriptions with the same to and from header, cause the call-id and cseq is different (other dialog). so its up to the client to response with an 481 if several notifys for the same subscripe will get recieved.
> > 
> > but i will just try this with my linksys SPA962 to see if i will get a 481 back ;)
> > 
> >

How does Asterisk handle a 481?  I'm pretty sure this was added to prevent receiving a storm of 481s to NOTIFYs.  Do we actually remove a subscription after receiving a 481?


- Russell


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/901/#review2675
-----------------------------------------------------------


On 2010-09-03 07:08:29, schmidts wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/901/
> -----------------------------------------------------------
> 
> (Updated 2010-09-03 07:08:29)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> in chan_sip.c the handle_request_subscribe function is very slow cause of iterating through all sip dialogs on every subscribe, to find old subscribes from this peer to exten at context. This patch will disable this iteration cause its not necessary.
> 
> 
> Diffs
> -----
> 
>   branches/1.6.2/channels/chan_sip.c 284848 
> 
> Diff: https://reviewboard.asterisk.org/r/901/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> schmidts
> 
>