Thangarajan Inbarajan wrote:
>
>
>
> Hi Paul,
>
>
> Invite (SDP offer )------>
>
> <------- 180 (no SDP)
>
> <------- 200 Ok for Invite (SDP answer)
>
> Prack (SDP)------>
>
>
> In the above case PRACK should not have SDP(offer).
> But if UAC misbehave, by sending SDP in the PRACK request.
> Then what UAS should do. What error code(4xx) is appropriate here.
I don't know. Pick one. AFAIK an error to a prack isn't going to be
recoverable, so it doesn't matter much.
Paul
> UAS can not discard this PRACK message because
>
> "If the UAS does send a final response when reliable responses are still
> unacknowledged, it
> SHOULD NOT continue to retransmit the unacknowledged reliable
> provisional responses, but it MUST be prepared to process PRACK
> requests for those outstanding responses. "
>
> Regards,
> Thangarajan.
>
>
>
>
>
> Paul Kyzivat
> <[EMAIL PROTECTED]
> om> To
> Sent by: [EMAIL PROTECTED]
> sip-implementors- are.com
> [EMAIL PROTECTED] cc
> ia.edu Seshu <[EMAIL PROTECTED]>,
> Vibhuti V Natraj
> <[EMAIL PROTECTED]>,
> 12/02/2005 07:22 "'[email protected]'
> PM "
> <[email protected]>,
> Kavita Rai <[EMAIL PROTECTED]>
> Subject
> Re: [Sip-implementors] Prack
> Offer/answer scenario
>
>
>
>
>
>
>
>
>
>
>
>
> [EMAIL PROTECTED] wrote:
>
>>
>>
>>Hi kavitha,
>>
>>I have few doubts about the call flow given
>>
>>Rfc 3262 says "If the initial offer is in an INVITE, the answer MUST be
>
> in
>
>>a reliable non-failure message from UAS back to UAC which is
>>correlated to that INVITE ".
>>In this call flow the answer must be generated either in 18x or 2xx but
>
> in
>
>>call flow given neither 18x or 2xx contain the Answer.
>>
>>Even though lets assume that you generated the answer in 2xx (final
>>response), I am not sure whether RFC mentions the UAC handling
>>for pending PRACK with SDP ?? In case PRACK without SDP is received then
>>2xx for PRACK may be the proper response.
>>
>>Waiting for the reply from sip gurus.........
>
>
> I agree the flow below is wrong. More below.
>
> Paul
>
>
>>Rgds,
>>Gururaj.
>>
>>
>>
>>
>>
>
>
>> Kavita Rai
>
>
>> <[EMAIL PROTECTED]
>
>
>> ch.com>
>
> To
>
>> Sent by:
>
> "'[email protected]'
>
>> sip-implementors- "
>
>
>> [EMAIL PROTECTED] <[email protected]>
>
>
>> ia.edu
>
> cc
>
>> Seshu <[EMAIL PROTECTED]>,
>
>
>> Vibhuti V Natraj
>
>
>> 12/01/2005 11:40 <[EMAIL PROTECTED]>
>
>
>> AM
>
> Subject
>
>> [Sip-implementors] Prack
>
>
>> Offer/answer scenario
>
>
>
>
>
>
>
>
>>
>>
>>
>>Hi,
>>Section 3 of RFC 3262 mentions
>>
>>"The UAS MAY send a final response to the initial request before having
>>
>>received PRACKs for all unacknowledged reliable provisional responses,
>>
>>unless the final response is 2xx and any of the unacknowledged reliable
>>
>>provisional responses contained a session description."
>>
>>In a scenario the reliable 1xx did not have SDP and we go ahead and
>>
>>send 2xx for Invite without waiting for Prack. What if the Prack for the
>>relaible 1xx we receive has an offer?
>>
>>Invite (SDP)------>
>
>
> The above SDP is the offer
>
>
>><------- 180 (no SDP)
>>
>><------- 200 Ok for Invite (No SDP)
>
>
> The above violates 3261. The 200 MUST contain an answer.
>
>
>>Prack (SDP)------>
>
>
> And this violates both 3262 and 3264 - it is sending another offer in a
> prack when there has been no answer to the earlier offer.
>
>
>><------ 200 OK(SDP)
>>
>>By sending the offer in PRACK user wanted to re-negotiate the parameters,
>>but in this case we have already sent 2xx for invite and other side will
>>respond with ACK and the session will be established as per SDP exchange
>
> in
>
>>Invite and 1xx.
>>
>>How does above statement mentioned above from the RFC take care of this
>>scenario??
>>
>>Will be grateful to have some direction from you on this..
>>
>>Regards,
>>
>>Kavita Rai
>>E-mail: <mailto:[EMAIL PROTECTED]> [EMAIL PROTECTED]
>>
>>This message (including any attachments) is a confidential and Privileged
>>communication to the intended addressee. If you are not the Intended
>>addressee, you have received this message in error. In that case, please
>>permanently delete this message and notify the sender so that we can
>
> avoid
>
>>this inconvenience in the future. Thank you.
>>
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[email protected]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>>
>>
>>*********************** FSS-Unclassified ***********************
>>"DISCLAIMER: This message is proprietary to Hughes Software Systems
>
> Limited
>
>>(HSS) and is intended solely for the use of the individual to whom it is
>>addressed. It may contain privileged or confidential information and
>>should not be circulated or used for any purpose other than for what it
>
> is
>
>>intended. If you have received this message in error, please notify the
>>originator immediately. If you are not the intended recipient, you are
>>notified that you are strictly prohibited from using, copying, altering,
>
> or
>
>>disclosing the contents of this message. HSS accepts no responsibility
>
> for
>
>>loss or damage arising from the use of the information transmitted by
>
> this
>
>>email including damage from virus."
>>
>>_______________________________________________
>>Sip-implementors mailing list
>>[email protected]
>>http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>>
>
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
>
>
>
> *********************** FSS-Private ***********************
> "DISCLAIMER: This message is proprietary to Flextronics Software
> Systems Limited (FSS) and is intended solely for the use of the
> individual to whom it is addressed. It may contain privileged or
> confidential information and should not be circulated or used for
> any purpose other than for what it is intended. If you have received
> this message in error, please notify the originator immediately.
> If you are not the intended recipient, you are notified that you are
> strictly prohibited from using, copying, altering, or disclosing
> the contents of this message. FSS accepts no responsibility for
> loss or damage arising from the use of the information transmitted
> by this email including damage from virus."
>
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
