While working on a setting PJSIP trunk with an ITSP, the ITSP asked me to remove several entries from the Allow header that comes with my outbound INVITE.
The entries he would like me to remove are:
REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, UPDATE, MESSAGE, REFER
The ones he would like me to keep are:
OPTIONS, INVITE, ACK, BYE, CANCEL
I can see Asterisk also includes PRACK in OPTIONS replies.
My current Asterisk version is 16.16.1 (but I’ll upgrade soon to Asterisk 20). The trunk I’m testing has allow_overlap, allow_subscribe and allow_transfer all set to false.
When allow_overlap, allow_subscribe and allow_transfer are set to false, shall I expect to see SUBSCRIBE and REFER to be absent from out bound INVITE ?
Is it possible or good practise to customize Allow header in outbound INVITE ? How can it be done ?
Is it possible to customize Allow header in OPTIONS replies ?
There is no ability to configure this. The Allow header is automatically generated based on functionality in the PJSIP library itself and some Asterisk modules, and is global to everything.
I would add that this is the first time I remember anyone even asking this. Also, OPTIONS is required to behave, as far a possible, like INVITE, without actually initiating a session, so I would suggest that the Allow header should be exactly the same as that on INVITE.
Allowing something doesn’t mean the provider has to use it. If they don’t want to use it, they simply should ignore the Allow for it. I suspect they are clutching at straws because of a different problem.
From a very theoritical point of view, it does make sense to have an Allow header being set to a subset of Asterisk capabilities.
I would be curious to know if the content of this Allow header has been tested in interop testings (in SIPit or elsewhere) or if others (Kamailio, Freeswith, …) fine tune its value.
Anyway, I think the ITSP guy will just take note we don’t comply with this rule and won’t keep us from sending traffic.
It’s been tested at SIPit. Noone has cared about tweaking it up to this point. The chan_sip module, which has been around longer, also has a fixed Allow list.
The only time it would be a compatibility issue is if Asterisk didn’t actually support what it claimed in the Allow. Basically, sensible things do not reject you for having too much in the Allow list, although they might reject you for too little. Even then one would normally expect them to fall back rather than reject.