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 *
-----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]]
>> 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
EMAIL DISCLAIMER : This email and any files transmitted with it are
confidential and intended solely for the use of the individual or entity to
whom they are addressed. Any unauthorised distribution or copying is strictly
prohibited. If you receive this transmission in error, please notify the sender
by reply email and then destroy the message. Opinions, conclusions and other
information in this message that do not relate to official business of Mascon
shall be understood to be neither given nor endorsed by Mascon. Any information
contained in this email, when addressed to Mascon clients is subject to the
terms and conditions in governing client contract.
Whilst Mascon takes steps to prevent the transmission of viruses via e-mail, we
can not guarantee that any email or attachment is free from computer viruses
and you are strongly advised to undertake your own anti-virus precautions.
Mascon grants no warranties regarding performance, use or quality of any e-mail
or attachment and undertakes no liability for loss or damage, howsoever caused.
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
