Thanks,
-----Original Message-----
From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 31, 2006 4:14 PM
To: Sarkar, Uttam; [EMAIL PROTECTED];
sip-implementors@cs.columbia.edu
Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
First Invite in this figure is really a re-Invite. Pl. refer to the text
accompanying this figure:
Let's assume, that in the middle of the session, A wishes to change
the IP address where it is receiving media. Figure 3 shows this
scenario.
SDP1: A includes an offer in a re-INVITE (1)
>-----Original Message-----
>From: Sarkar, Uttam [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 31, 2006 3:56 PM
>To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
>sip-implementors@cs.columbia.edu
>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
>
>Here is that figure. I don't see any re-INVITE at all.
>Here INVITE (1) had 200 OK (7) and ACK (8).
>No further re-INVITE.
>
>
>
> A B
>
> | |
> |-------------(1) INVITE SDP1--------------->|
> | |
> |<------(2) 183 Session Progress SDP2--------|
> | *** *** |
> |--*R*-----------(3) PRACK-------------*R*-->|
> | *E* *E* |
> |<-*S*-------(4) 200 OK (PRACK)--------*S*---|
> | *E* *E* |
> | *R* *R* |
> | *V* *V* |
> | *A* *A* |
> | *T* *T* |
> | *I* *I* |
> | *O* *O* |
> | *N* *N* |
> | *** *** |
> | *** |
> | *** |
> |-------------(5) UPDATE SDP3--------------->|
> | |
> |<--------(6) 200 OK (UPDATE) SDP4-----------|
> | |
> |<-----------(7) 200 OK (INVITE)-------------|
> | |
> |------------------(8) ACK------------------>|
> | |
> | |
>
>
>-----Original Message-----
>From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
>Sent: Tuesday, October 31, 2006 3:48 PM
>To: Sarkar, Uttam; [EMAIL PROTECTED];
>sip-implementors@cs.columbia.edu
>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
>
>
>
>>-----Original Message-----
>>From: Sarkar, Uttam [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, October 31, 2006 3:17 PM
>>To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
>>sip-implementors@cs.columbia.edu
>>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
>>
>>I see UPDATE is used before sending 200 OK (for INVITE). I don't see
>>any re-INVITE scenario here. Am I missing something here?
>
>Yes. Pl. see sec. 13.1, Figure 3.
>
>
>>
>>-----Original Message-----
>>From: Sanjay Sinha (sanjsinh) [mailto:[EMAIL PROTECTED]
>>Sent: Tuesday, October 31, 2006 2:56 PM
>>To: Sarkar, Uttam; [EMAIL PROTECTED];
>>sip-implementors@cs.columbia.edu
>>Subject: RE: [Sip-implementors] Query 100rel in re-INVITE
>>
>>I think RFC 3312 has some examples where 18x is needed for
>>preconditions in a mid-call session.
>>
>>Sanjay.
>>
>>>-----Original Message-----
>>>From: Sarkar, Uttam [mailto:[EMAIL PROTECTED]
>>>Sent: Tuesday, October 31, 2006 2:05 PM
>>>To: Sanjay Sinha (sanjsinh); [EMAIL PROTECTED];
>>>sip-implementors@cs.columbia.edu
>>>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];
>>>sip-implementors@cs.columbia.edu
>>>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]; sip-implementors@cs.columbia.edu
>>>>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: sip-implementors@cs.columbia.edu
>>>>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
>>>>Sip-implementors@cs.columbia.edu
>>>>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
>>>>Sip-implementors@cs.columbia.edu
>>>>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.
>>>
>>
>>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.
>>
>
>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.
>
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
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
