I understand that this is a guideline/practice we could follow to support a custom-message. How about handling an unknown message (say XYZ)?
In the TCK (for JSR289) one of the test is sending an unknown message. Is it okay to expect the SIP element handle this unknown message? NarayanaSwamy A. ---------------------------------------------------------------------------- --------------------------------------------------------- This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -----Original Message----- From: Dale Worley [mailto:[email protected]] Sent: Tuesday, March 03, 2009 2:35 AM To: [email protected] Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Sip-implementors] Regarding custom messages On Mon, 2009-03-02 at 17:56 +0530, NarayanaSwamy wrote: > HI All, > > As per RFC 3261 > Request-Line = Method SP Request-URI SP SIP-Version CRLF > > Method: This specification defines six methods: REGISTER for > registering contact information, INVITE, ACK, and CANCEL for setting > up sessions, BYE for terminating sessions, and OPTIONS for querying > servers about their capabilities. SIP extensions, documented in > standards track RFCs, may define additional methods. > > > Can anyone pls tell me which RFC defines custom methods in the request > URI to be supported by sip elements. If a method was defined in an RFC, it would not be "custom"! However, there are conventions for "custom", "private", or "extension" identifiers that are used in many IETF protocols: If you want to define an identifier for your own experimental use, start it with "X", then a word that is your project's name, your company's name, or even your own name, to provide some "scoping" for the extension, such as "NORTEL", and then another word which identifies the extension. This gives results like: X-NORTEL-RULETEST1 sip:[email protected]:5060 SIP/2.0 CSeq: 1 RULETEST1 If your extension becomes popular enough that multiple projects use it in a consistent way, change the name to remove the project-name part: X-RULETEST1 sip:[email protected]:5060 SIP/2.0 CSeq: 1 RULETEST1 This convention can be applied to other element names in protocols. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
