> 1) Is the INFO method allowed for dialogs > created for methods other than > INVITE? The RFC seems to imply INVITE only > but I don't see anywhere where it is stated.
RFC 2976 was produced prior to call-leg being renamed to be dialog and prior to any non-invite dialogs. Otherwise the RFC would have been more clear. :) The header was defined explicitly for passing "session" data over the signaling path; thus it should only apply to INVITE dialogs. Because the INFO method is not too popular among some people within the working group, I doubt that an extension draft which proposes to use INFO for other dialogs would make it to RFC status. For established dialogs, the INFO and all unknown methods should traverse proxies like a BYE. However the concept of receiving an INFO, or unknown request on a SUBSCRIBE dialog is likely a nuisance for some soft state implementations. Such a usage might lead to receiving a 481 instead of the expected 405 or 501. > 2) Can INFO (and, in general other in-dialog > methods) be sent on an "early" dialog > (created by PRACK)? Yes, the INFO request can traverse an early dialog. Proxies should allow INFO and other in-dialog methods to traverse an early dialog path. _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
