sngrep CallState turns into DIVERTED after 50X responses

Asterisk doesnt handle well UPDATE methods. Since it replies with "501 Method Not Implemented", sngrep incorrectly changes call state to DIVERTED.

Check https://github.com/irontec/sngrep/blob/f51e99cb405710c2348e2f5322e04100714a97a5/src/sip_call.c#L227

Oct 29 '19 17:10 juradoz

Hi @juradoz

This was introduced in https://github.com/irontec/sngrep/pull/154 some time ago.

Maybe we should add an extra condition to only check the response code of initial transactions to mark the call as diverted, like we do with 4XX responses.

https://github.com/irontec/sngrep/blob/f51e99cb405710c2348e2f5322e04100714a97a5/src/sip_call.c#L224

Or maybe we should just mark the call as diverted on 181, 301 or 302 responses.

Oct 29 '19 17:10 Kaian

Can we consider responses to UPDATE methods dont change call state? I didn't dig RFC that much...

Oct 29 '19 19:10 juradoz

Seems legit: https://tools.ietf.org/html/rfc3261#section-21.5.2

Can we consider responses to UPDATE methods dont change call state? I didn't dig RFC that much...

Oct 29 '19 20:10 systemcrash

Call State is something not mentioned in any RFC as far as I know. It's something implemented in wireshark that we have took as an idea but we don't share the same implementation.

I think I would stick to those initial transaction responses to mark the call as diverted. Any in-dialog requests (p.e. INFO) can generate misleading responses for call state.

Thanks for the inputs!

Oct 30 '19 08:10 Kaian

Above commit should mark the call as DIVERTED only when a 181, 301 or 302 response has been received.

Thanks for the feedback :)

Oct 31 '19 17:10 Kaian