On Fri, Jul 4, 2008 at 5:35 PM, Ruud Klaver <ruud at ag-projects.com> wrote: > Hi all, > > I've noticed that certain modules will register methods with the pjsip > endpoint that subsequently end up in the Allow header which can be > queried from it, for example to be used in response to a OPTIONS > request. The evsub module will register SUBSCRIBE and NOTIFY, while > the publishc module will register PUBLISH. > > I was just wondering if this is in fact correct behaviour. I'm not at > all certain about the semantics of the Allow header, but it tend to think that this header includes any methods that the endpoint will > successfully process if sent to it. Now the evsub module in this case > allows for UAS sessions to be created, but I think the publishc module > is only a client and does not allow for processing of incoming PUBLISH > requests. > I think in general the semantic of Allow header is at best unclear. Section 20.5 only says "The Allow header field lists the set of methods supported by the UA generating the message". Having said that I tend to agree with your interpretation (in other words probably it's not appropriate to put PUBLISH in Allow header). > > Can anyone on this list confirm or deny that the Allow header works in > this way and expand on what the correct behaviour is in this case. > Just to be clear I want to implement a UA that does not handle > SUBSCRIBE requests, but can send SUBSCRIBE requests to an agent. > Reading RFC 3261 again, I found that there is a different semantic for Allow header when it's sent with INVITE or responses to INVITE. In this case, the Allow header specifies the methods that can be sent *within* the dialog. I would assume that this applies to dialog created by SUBSCRIBE too, although RFC 3265 is silent about this. Not sure how this would answer your query (probably it's best to ask this to sip-implementors list), but I'll be removing PUBLISH from my Allow header. :) Cheers Benny -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20080707/fd86c6a7/attachment-0001.html
