There is no need to specify Unsupported:precondition. (There are
potentially an infinity of options you don't support. Nobody expects you
to list them all.)
Otherwise I think what you propose is fine. The offerer will see the
response and have to conclude that you don't support preconditions
because you have included none of a-lines that you would have included
if you did support it.
Paul
Tang Xi wrote:
> Hi,Sreeram
>
> Thanks for your help. But I am still confused about the format of SDP in 200
> response while the callee doesn't support precondition and ignore the
> precondition information. Should the SDP in 200 is like what I mentioned in
> the first mail? that is:
>
> Unsupported:precondition
> ...
> m=audio 777 RTP/AVP 1 2 3
> a=rtpmap: ....
> a=rtpmap: ....
> a=rtpmap: ....
> a=sendrecv
> Regards
> Xi Tang
>
>
>
>
>
> On 10/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>> Hi Xi Tang,
>>
>> I mean for 200 case it will be like a general invite-200-ack transaction.
>>
>> And 200 will have the SDP.
>>
>> As 580 is a special case I mentioned ..:-)
>>
>>
>>
>> Regarding 24.229:
>>
>> It means that if the UE that does not support this precondition mechanism
>> , it will ignore the precondition information.
>>
>> If it supports the precondition mechanism than accordingly it will respond
>> to the message (200/580).
>>
>>
>>
>> HTH
>>
>> Sreeram.
>>
>>
>> ------------------------------
>>
>> *From:* Tang Xi [mailto:[EMAIL PROTECTED]
>> *Sent:* Tuesday, October 17, 2006 10:03 AM
>> *To:* Sreeram Kanumuri (WT01 - IP-Multimedia Carrier & Ent Networks)
>> *Cc:* [email protected]
>> *Subject:* Re: [Sip-implementors] Query:How can UA ignore a precondition
>> offer?
>>
>>
>>
>> Hi *sreeram*
>>
>> *Thanks for your replying. So do you mean 200 presponse should not have *
>>
>> SDP? But I think it is reasonable for 200 response or 18x reliable
>> response with SDP to still establish the session ignoring the precondition
>> information.
>>
>>
>>
>> See 24.229v0611 5.1.4.1
>>
>> "NOTE 3: If the terminating UE does not support the precondition mechanism
>> it will apply regular SIP session initiation procedures."
>>
>>
>>
>> and 6.1.3
>>
>> "NOTE 2: If the terminating UE does not support the precondition mechanism
>> it will ignore any precondition information received from the originating
>> UE"
>>
>>
>> On 10/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] >
>> wrote:
>>
>>
>> Hi Xi Tang,
>>
>> When the preconditions are Mandatory and are not met by the answer: 580
>> should be send.
>> When the preconditions are optional and are not met by the answer: 200
>> will be send.
>>
>> 580 will have the SDP. with all the SDP payload as but for this
>>
>> a=des:qos mandatory local sendrecv
>> It should be:
>> a=des:qos failure local sendrecv (failure should be added)
>> and port number in M should be set 0 for the a which is not met.
>>
>> HTH,
>> Sreeram.
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of Tang Xi
>> Sent: Tuesday, October 17, 2006 8:20 AM
>> To: [email protected]
>> Subject: [Sip-implementors] Query:How can UA ignore a precondition
>> offer?
>>
>> Hi,
>> 1>in the first INVITE, UAC contain a SDP with precondition information
>> like
>> this:
>>
>> Surpported:100rel, precondition
>> ...
>>
>> m=audio 777 RTP/AVP 1 2 3
>> a=curr:qos local none
>> a=curr:qos remote none
>> a=des:qos mandatory local sendrecv
>> a=des:qos none remote sendrecv
>> ...
>>
>> 2>UAS receive the request,and UAS is able to send or receive the media
>> stream with all of the codec,
>> but it does not support the precondition, how can it ignore the
>> precondition information?
>> Should it do like this?
>>
>> Unsupported:precondition
>> ...
>> m=audio 777 RTP/AVP 1 2 3
>> a=rtpmap: ....
>> a=rtpmap: ....
>> a=rtpmap: ....
>> a=sendrecv
>>
>>
>> Would appreciate your response.
>>
>> Thanks
>> Xi Tang
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email.
>> www.wipro.com
>>
>>
>> The information contained in this electronic message and any attachments
>> to this message are intended for the exclusive use of the addressee(s) and
>> may contain proprietary, confidential or privileged information. If you are
>> not the intended recipient, you should not disseminate, distribute or copy
>> this e-mail. Please notify the sender immediately and destroy all copies of
>> this message and any attachments. WARNING: Computer viruses can be
>> transmitted via email. The recipient should check this email and any
>> attachments for the presence of viruses. The company accepts no liability
>> for any damage caused by any virus transmitted by this email.
>> www.wipro.com
>>
> _______________________________________________
> 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
