Hi Nataraju,
This is the current usage of offer/answer model in SIP communication.
In theory, any SIP message can include session description in its
body. But not all the session description in a SIP message is an
offer or an answer. Only the session description that conforms to the
rules described in the standard track RFCs can be interpreted as an
offer or an answer. The rules how to handle offer/answer model are
currently defined in several RFCs. Unless defined in an RFC
explicitly as an offer or an answer, except ones in non-reliable
provisional response to INVITE request, a session description should
not be included in SIP messages to avoid confusions.
Regards,
Thangarajan.
FlextronicsSoftware
Worlds largest SIP stack vendor
"Nataraju
Basavaraju"
<[EMAIL PROTECTED] To
networks.com> <[EMAIL PROTECTED]
com>, "Ramya Jyoti"
12/26/2005 01:36 <[EMAIL PROTECTED]>
PM cc
<[EMAIL PROTECTED]
ia.edu>, "priya pandit"
<[EMAIL PROTECTED]>,
<[email protected]>
Subject
RE: [Sip-implementors] Multiple 2xx
responses
Comments Inline...
Regards,
Nataraju A.B.
From: [EMAIL PROTECTED] on behalf of
[EMAIL PROTECTED]
Sent: Sun 12/25/2005 11:10 PM
To: Ramya Jyoti
Cc: [EMAIL PROTECTED]; 'priya pandit';
[email protected]
Subject: Re: [Sip-implementors] Multiple 2xx responses
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
[ABN] many of the implementations may nto support this draft
implementation. again this is still in draft stage..
So you can't mandate for not to send the SDP in 200 OK in case SDP answer
was sent in the reliable 1xx. You should still accept the 2xx with same SDP
which was there in earlier reliable 1xx.
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
The information contained in this message may be confidential to Kodiak
Networks, Inc. and its subsidiaries and protected from disclosure. If this
message did not reach the intended recipient, or an employee or agent
responsible for delivering it to the intended recipient, you are hereby
informed that any distribution or copying of this communication is
prohibited. If you have received this communication in error, please notify
us immediately by replying to the sender of the message and then delete the
message. Thank you.
*********************** 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
