This question came up in looking at a REFER call flow. The question is whether an "Accept: message/sipfrag" is ever required in order to indicate ability to accept the notifications resulting from the refer.
In 3261, the majority of the semantics of Accept are deferred to RFC2616. But that isn't much help for this, because the scope of an Accept in 2616 seems to be limited to the response to the message carrying it, and that doesn't seem appropriate for SIP.
So, in the context of SIP it isn't clear to me if an Accept message should be exhaustive, like Allow is, or just a way of reporting some of the types accepted. The description of error 406 in 3261 certainly suggests that a server should treat the Accept header as a complete and exhaustive list, else it would never be appropriate to return a 406 error.
Let me pose a specific scenario that I am curious about:
1) INVITE ... (initiates new dialog) (no Accept header - default is Application/SDP)
2) 200 OK
3) ACK
5) REFER ... (same dialog) (no Accept header)
6) 202 OK 7) NOTIFY ... Cotent-Type: message/sipfrag
According to 3261, the default for Accept is application/sdp. Should the server conclude it can't send the notify? If so, what should it do? Should it refuse the REFER with a 406? Should it just not send the NOTIFY?
Or should the server assume an implied Accept: message/sipfrag in message #5?
Would anything change if there was an explict Accept header in message #1 that doesn't mention sipfrag, such as "Accept: application/sdp,text/plain"?
Thanks,
Paul_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
