Hi thangarajan,
Thanks for the reply.
Sorry to have mistakenly drawn the sip call flow for the second query.
Redrawing it :
Q)
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)------>
<------- 180 (no SDP)
<------- 200 Ok for Invite (No SDP)
Prack (SDP)------>
<------ 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 eatablished as per SDP exchange in
Invite and 1xx.
Hoe does above statement from the RFC take care of this scenario??
Regards,
Kavita
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
Sent: Thursday, December 01, 2005 9:10 AM
To: Kavita Rai
Cc: Seshu; '[email protected]';
[EMAIL PROTECTED]; Vibhuti V Natraj
Subject: Re: [Sip-implementors] Prack Queries
Hi Kavita,
1) When PRACK times out,
Transaction layer:
If Timer F fires while the client transaction is still in the
"Trying" state, the client transaction SHOULD inform the TU about the
timeout, and then it SHOULD enter the "Terminated" state.
UAC core:
When a timeout error is received from the transaction layer, it MUST be
treated as if a 408 (Request Timeout) status code has been received.
Action:
If the response for a request within a dialog is a 481
(Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC
SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if
no response at all is received for the request
2)
Invite (SDP)------>
<------- 180 (no SDP)
Prack (no SDP) -----> (no SDP)
<-------200 OK for Invite (SDP)
Prack (SDP)------>
<------ 200 OK(SDP)
SIP trapezoid is not clear.
In SIP trapezoid there are 2 PARCK [one is with SDP and other is with out
SDP].
But only one RPR is there.
Regards,
Thangarajan.
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
11/30/2005 05:17 <[EMAIL PROTECTED]>
PM Subject
[Sip-implementors] Prack Queries
Hi,
1) In a situation where we send 2xx for Invite before receiving Prack for
a
reliable 1xx which does not have session description and session gets
established, how should we handle Prack time out ? Does it affect the
connected session?
Invite (SDP)------>
<------- 180 (no SDP)
Prack (no SDP) -----> (no SDP)
<-------200 OK for Invite (SDP)
ACK------>
---------------------Session Established-------------------
Prack--->
...
...
Prack TimeOut() happens
what happens to the session state or what action should be taken at UAC for
Prack Timeout?
2) 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 where the reliable 1xx did not have SDP and we go ahead and
send 2xx for Invite without waiting for Prack. What if the Prack we receive
has an offer?
Invite (SDP)------>
<------- 180 (no SDP)
Prack (no SDP) -----> (no SDP)
<-------200 OK for Invite (SDP)
Prack (SDP)------>
<------ 200 OK(SDP)
Regards,
Kavita Rai,
[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
*********************** FSS-Private ***********************
"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
