[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
