The interesting cases come up in 3pcc. Even when supported, UPDATE
doesn't in general do the job. What one wants to do is solicit the other
party to make an offer. This can't be done with UPDATE. There is much
discussion of this in the 3pcc call flows document.
Paul
Agrawal, Vishal wrote:
> A re-INVITE request allows 18X responses, right?
>
> The statement that re-INVITE MUST always be immediately answered with a
> 200 OK response doesn't seem right. I think if a UAC wants an immediate
> answer then it should send an UPDATE (if supported) request and not a
> re-INVITE. If UPDATE is not supported then the UAC should remove the
> "Supported: 100rel" from the re-INVITE and should ignore the 18X
> responses for re-INVITE.
>
> A re-INVITE seems appropriate when adding/removing new/old media to/from
> the existing session or other cases (as mentioned by others for QoS
> etc).
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Sarkar,
> Uttam
> Sent: Tuesday, October 31, 2006 1:05 PM
> To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
> [email protected]
> Subject: Re: [Sip-implementors] Query 100rel in re-INVITE
>
> Whole idea of 100rel is to make sure 18X message is received by the
> other party so that they can be sure of exchnage any media before
> session is established.
> Re-INVITE is for established session.
> Please correct me if I am wrong.
>
> -----Original Message-----
> From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 31, 2006 1:09 PM
> To: Sarkar, Uttam; [EMAIL PROTECTED];
> [email protected]
> Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
>
> It might be useful for QoS cases.
>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> Sarkar, Uttam
>> Sent: Tuesday, October 31, 2006 11:28 AM
>> To: [EMAIL PROTECTED]; [email protected]
>> Subject: Re: [Sip-implementors] Query 100rel in re-INVITE
>>
>> I still can't understand why 100rel is requiring to a
>> re-INVITE (change media from audio to audio and video).
>> In the re-INVITE it will carry the new media. Other endpoint
>> will respond back with final response (like 200 OK or 488 Not
>> Acceptable Here).
>> I can't imagine other end will send 18X with media and send
>> PRACK for a session that is already established.
>>
>> Thanks,
>>
>> -----Original Message-----
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of
>> [EMAIL PROTECTED]
>> Sent: Tuesday, October 31, 2006 10:57 AM
>> To: [email protected]
>> Subject: Re: [Sip-implementors] Query 100rel in re-INVITE
>>
>> From: "Sarkar, Uttam" <[EMAIL PROTECTED]>
>>
>> 100rel does not make sense in re-INVITE as session is already
>> established. UAS is expected to send final response
>> (2XX/4XX/5XX etc ).
>> It can send 100 trying to stop retransmission of INVITE while it's
>> preparing the final response.
>> It's not recommended for UAS to send 1XX response for the re-INVITE.
>>
>> One can imagine scenarios where a re-INVITE might not be
>> instantaneous, and so 100rel might be a useful mechanism. For
>> instance, if one endpoint wishes to upgrade an audio call to
>> an audio-and-video call, the other endpoint might want to ask
>> its user before activating the video camera.
>>
>> Dale
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> This email and any attached files herein contain information
>> that is intended only for the use of the individual or entity
>> to whom it is addressed and may contain information that is
>> legally privileged, confidential or otherwise exempt from
>> disclosure under applicable laws. If the reader of this
>> message is not the recipient, any disclosure, dissemination,
>> distribution, copying or other use or retention of this
>> communication or its substance is prohibited.
>>
>>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> [email protected]
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
> This email and any attached files herein contain information that is
> intended only for the use of the individual or entity to whom it is
> addressed and may contain information that is legally privileged,
> confidential or otherwise exempt from disclosure under applicable laws.
> If the reader of this message is not the recipient, any disclosure,
> dissemination, distribution, copying or other use or retention of this
> communication or its substance is prohibited.
>
>
>
> _______________________________________________
> 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
