Correct syntax for docker-compose.yml DiscardMethod

Question

Correct syntax for docker-compose.yml DiscardMethod

lukeescude opened this issue 3 years ago · 20 comments

lukeescude commented 3 years ago

Hello, what is the correct syntax to supply HeplifyServer with DiscardMethod?

I am using the following, and I don't believe it works (I can still look at OPTIONS packets inside Homer):

"HEPLIFYSERVER_DISCARDMETHOD=['OPTIONS','NOTIFY','SUBSCRIBE']"

Thanks!

Answer 1 · 2021-10-02T16:00:44.000Z

According to the docs that should be correct indeed:

DiscardMethod = ["OPTIONS","NOTIFY"]

Answer 2 · 2021-10-02T16:32:40.000Z

That makes sense for normal heplify server, but for docker compose file I’m not sure how it wants an array of strings?

Answer 3 · 2021-10-02T16:44:40.000Z

There is no translation, heplify-server looks for the same settings in ENV so they are equivalent/transparent (escaping excluded which might perhaps be the issue here) the compose file just passes everything forward

Answer 4 · 2021-10-02T16:52:29.000Z

Okay I will play around with escaping and let you know!

Answer 5 · 2021-10-02T20:04:09.000Z

Yes unfortunately it seems the docker image is not paying attention to DiscardMethod... OPTIONS, NOTIFY, and SUBSCRIBE packets are still being logged in homer-app

Answer 6 · 2021-10-02T20:21:24.000Z

Ok, will try reproduce.

Answer 7 · 2021-10-02T21:07:15.000Z

for docker you should not escape it
DiscardMethod = [OPTIONS,NOTIFY]

Answer 8 · 2021-10-03T16:09:08.000Z

I have tried that as well, still OPTIONS packets are logged in Homer.

Answer 9 · 2021-10-04T15:07:43.000Z

I have learned more:

DiscardMethod works for NOTIFY packets, but it is not working for SUBSCRIBE or OPTIONS it seems.

Answer 10 · 2021-10-04T15:13:35.000Z

Are those inband OPTIONS (within a call-flow) or out-of-band in the generic partition?

Answer 11 · 2021-10-04T15:14:35.000Z

I believe out-of-band, used just for devices to qualify or "ping" the server. (and for the server to qualify or "ping" devices)

Answer 12 · 2021-10-04T16:27:42.000Z

let me check it

Answer 13 · 2021-10-04T16:31:49.000Z

nop, it should discard it - look at the code

https://github.com/sipcapture/heplify-server/blob/master/decoder/decoder.go#L143-L148


if len(config.Setting.DiscardMethod) > 0 {
			for k := range config.Setting.DiscardMethod {
				if config.Setting.DiscardMethod[k] == h.SIP.CseqMethod {
					h.ProtoType = 0
					return nil
				}
			}
		}

what if you add switch positions OPTIONS and NOTIFY in the DiscardMethod ? Will it change something ?

Answer 14 · 2021-10-04T19:01:17.000Z

Out of curiosity, would it be a good idea to use both CseqMethod and FirstMethod for discarding?

I will try reordering and let you know

Answer 15 · 2021-10-04T20:36:58.000Z

Out of curiosity, would it be a good idea to use both CseqMethod and FirstMethod for discarding?

why ?

Answer 16 · 2021-10-04T20:38:15.000Z

It looks like they should both work, but maybe the issue is that CseqMethod is not populating for OPTIONS packets because they are out-of-band (stateless)

Answer 17 · 2021-10-04T20:40:55.000Z

no, because CSeq always includes the method to build a transaction flow and doesn't matter if it stateless or state full

Answer 18 · 2021-10-04T22:02:37.000Z

Okay the order is the problem.

Switched OPTIONS and NOTIFY, now OPTIONS are being discarded but NOTIFY is back.

Answer 19 · 2021-10-04T22:07:21.000Z

aha, so, lets add it twice as a workaround and i will recheck why it happens during next days...

Answer 20 · 2022-06-21T20:16:04.000Z

Do you have an update on this? The discard methods not being read properly (order)