Hi Ramya,
>>If 180 was reliable the, 200ok NEED NOT have the answer
>>If 180 was not reliable, then 200ok MUST have the same answer
If 180 was reliable, then 200ok SHOULD NOT have the answer.
>From draft.
SDP should not be included in the final response once offer/answer has been
completed
http://tools.ietf.org/wg/sip/draft-sawada-sipping-sip-offeranswer-00.txt
Regards,
Thangarajan.
FlextronicsSoftware
Worlds largest SIP stack vendor
"Ramya Jothi"
<[EMAIL PROTECTED]
works.com> To
Sent by: "'Ajit Kumar'"
sip-implementors- <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] "'Anshuman Rawat'"
ia.edu <[EMAIL PROTECTED]>,
"'priya pandit'"
<[EMAIL PROTECTED]>,
12/26/2005 10:09 <[email protected]>
AM cc
Subject
Re: [Sip-implementors] Multiple 2xx
responses
Answers Inline
[ASR] I think that it still has to send SDP in 200 OK even if the answer
has been sent by a provisional response. Can some 3rd person confirm?
<RAMYA>
Extract from RFC 3261
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.
Extract from RFC 3262
A UAS MAY send any non-100 provisional response to INVITE reliably,
so long as the initial INVITE request (the request whose provisional
response is being sent reliably) contained a Supported header field
with the option tag 100rel.
>From the above extracts We can say that
If 180 was reliable the, 200ok NEED NOT have the answer
If 180 was not reliable, then 200ok MUST have the same answer
-Regards
Ramya
" Failure is not when you fall down
Its only when you don't get up again "
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ajit
Kumar
Sent: Friday, December 23, 2005 3:14 PM
To: 'Anshuman Rawat'; 'priya pandit'; [email protected]
Subject: Re: [Sip-implementors] Multiple 2xx responses
Comments inline
Regards
Ajit
-----Original Message-----
From: Anshuman Rawat [mailto:[EMAIL PROTECTED]
Sent: Friday, December 23, 2005 2:36 PM
To: Ajit Kumar; priya pandit; [email protected]
Subject: RE: [Sip-implementors] Multiple 2xx responses
See inline.
Regards,
Anshuman
2. Though an ACK is sent back to all, which one should be considered
finally
?
-> their will be only one ACK response from UAC that will the server
transaction to transition itself from completed to confirmed state, rest
of all ACK's will be absorbed by UAS having no effect of server
transaction state.
[ASR] I think the above explanation might be incorrect. Section 13.1 in
3261 states that -
"A 2xx response to an INVITE establishes a session, and it also
creates a dialog between the UA that issued the INVITE and the UA
that generated the 2xx response. Therefore, when multiple 2xx
responses are received from different remote UAs (because the INVITE
forked), each 2xx establishes a different dialog. All these dialogs
are part of the same call."
-> [ajit] I am here not talking about forked response I am talking about
the retransmission of ACK from a particular UAC to a particular UAS.
What you have said is true in case of forked request and the ACK
generated by UAC will also be meant for different UAS.
This explanation should also answer the original question.
3.Can all of them contain SDPs (pbly answer SDPs)?
-> each of the 200Ok response can or need not have the SDP, if one
retransmission has SDP answer than all will have. Remember answer can
also be sent in 1xx provisional response like 180 ringing.
[ASR] I think that it still has to send SDP in 200 OK even if the answer
has been sent by a provisional response. Can some 3rd person confirm?
[ajit] ya 200ok must carry the SDP even if 180 carries SDP. I was not
clear though. Sorry.
Regards,
Priya.
_______________________________________________
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
********************** Legal Disclaimer ****************************
"This email may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or
distribution by others is strictly prohibited. If you have received the
message in error, please advise the sender by reply email and delete the
message. Thank you."
**********************************************************************
_______________________________________________
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
*********************** 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]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
