Thanks for the replies!! Is this the expected behaviour of doRequest method? If application wants to send their 'proprietary' messages, then what are the transaction/dialog state that has to be maintained for this...
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: [email protected] [mailto:[email protected]] On Behalf Of Venkatesh Sent: Tuesday, March 03, 2009 12:54 PM To: Somesh S. Shanbhag Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: Re: [Sip-implementors] Regarding custom messages Think you are confusing with the existence of a test case in JSR 289 (SIP Servlet API 1.1) with something else. The Allow header is a means to indicate to the far end what methods you are capable of handling. The test in JSR 289 is simply validating the capability of JSR 289 compliant implementation to send/receive 'generic' SIP requests/responses. Thus should a need arise for an application developer to define 'proprietary' headers for whatever reason or a new header is proposed in the SIPPING/SIP WG, the application developer is not 'stuck' waiting for a software update from the Servlet Container vendor they chose to package their offering. Thanks, Venkatesh On Mon, Mar 2, 2009 at 11:11 PM, Somesh S. Shanbhag <[email protected] > wrote: > Thats with *Allow* header. According to RFC 3261, > 20.5 Allow > > The Allow header field lists the set of methods supported by the UA > generating the message. > > All methods, including ACK and CANCEL, understood by the UA MUST be > included in the list of methods in the Allow header field, when > present. The absence of an Allow header field MUST NOT be > interpreted to mean that the UA sending the message supports no > methods. Rather, it implies that the UA is not providing any > information on what methods it supports. > > Supplying an Allow header field in responses to methods other than > OPTIONS reduces the number of messages needed. > > Example: > > Allow: INVITE, ACK, OPTIONS, CANCEL, BYE > > Somesh > > * Please do not take print out of this e-mail unless its absolutely > necessary *- Show quoted text - > > -----Original Message----- > From: [email protected] on behalf of > Venkatesh > Sent: Tue 3/3/2009 12:34 PM > To: Venkatesh > Cc: [email protected]; [email protected]; [email protected]; > [email protected] > Subject: Re: [Sip-implementors] Regarding custom messages > > 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] <[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
