[asterisk-dev] [Code Review] handle_request_subscribe is too slow cause of iterating through all sip dialogs
sst at sil.at
sst at sil.at
Fri Sep 3 16:32:01 CDT 2010
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/901/#review2675
-----------------------------------------------------------
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 ;)
- schmidts
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
>
>
More information about the asterisk-dev
mailing list