Replies Interspersed.... On Tue, Mar 3, 2009 at 1:30 AM, NarayanaSwamy <[email protected]>wrote:
> Thanks for the replies!! > Is this the expected behaviour of doRequest method? [Venkatesh] YES. I would think so. > > If application wants to send their 'proprietary' messages, then what are > the > transaction/dialog state that has to be maintained for this... [Venkatesh] It should pretty much obey the rules of a non INVITE transaction. > > > 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] > - Show quoted text - > [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----- > - Show quoted text - > > >> 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
