To add to my statements how else would you ensure your container is capable of sending/receiving generic requests?!?!
Sent from Venky's iPhone On Mar 2, 2009, at 11:00 PM, Venkatesh <[email protected]> wrote: > I think you are missing the whole point of the test. Like dale > mentions one can in theory define any method name. All the test is > trying to do is to ensure that the container is capable of > generating an arbitary request. Not sure I understand your concern > with the same. > > Thanks, > Venkatesh > > Sent from Venky's iPhone > > On Mar 2, 2009, at 8:08 PM, NarayanaSwamy <[email protected]> > wrote: > >> 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 _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
