[prev in list] [next in list] [prev in thread] [next in thread]
List: sip-implementors
Subject: Re: [Sip-implementors] Multiple 2xx responses
From: "Nataraju A B" <bnataraju () kodiaknetworks ! com>
Date: 2005-12-27 13:44:19
Message-ID: 000201c60ae9$f77670b0$7302a8c0 () Nataraju
[Download RAW message or body]
Comments inline...
Thanks & Regards,
Nataraju A.B.
-----Original Message-----
From: thangarajan.i@flextronicssoftware.com
[mailto:thangarajan.i@flextronicssoftware.com]
Sent: Monday, December 26, 2005 2:58 PM
To: Nataraju Basavaraju; pkyzivat@cisco.com; tu-sawada@kddi.com
Cc: priya pandit; Ramya Jyoti; sip-implementors@cs.columbia.edu;
sip-implementors-bounces@cs.columbia.edu
Subject: RE: [Sip-implementors] Multiple 2xx responses
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.
[ABN] I agree with you, but to make it interoperable with the existing
implementations, the 200OK received with SDP where as non-reliable 1xx
did carried the SDP.. Should be considered as a valid answer...
Even though the draft you mentioned becomes an RFC, the one mentioned in
3261 must be the baseline to support... It would be better that the new
drafts would be inline with existing RFCs unless mandatorily required
the particular change....
[ABN] we can't put a restriction on the existing implementations to
update because of the new draft/RFC being published. Yes over a period
of time we can make it mandatory to support these additional drafts/RFCs
based on criticality of the issue....
"Nataraju
Basavaraju"
<bnataraju@kodiak
To
networks.com>
<thangarajan.i@flextronicssoftware.
com>, "Ramya Jyoti"
12/26/2005 01:36 <rjyoti@kodiaknetworks.com>
PM
cc
<sip-implementors-bounces@cs.columb
ia.edu>, "priya pandit"
<priya.panditt@gmail.com>,
<sip-implementors@cs.columbia.edu>
Subject
RE: [Sip-implementors] Multiple
2xx
responses
Comments Inline...
Regards,
Nataraju A.B.
From: sip-implementors-bounces@cs.columbia.edu on behalf of
thangarajan.i@flextronicssoftware.com
Sent: Sun 12/25/2005 11:10 PM
To: Ramya Jyoti
Cc: sip-implementors-bounces@cs.columbia.edu; 'priya pandit';
sip-implementors@cs.columbia.edu
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"
<rjyoti@kodiaknet
works.com>
To
Sent by: "'Ajit Kumar'"
sip-implementors- <akumar@kodiaknetworks.com>,
bounces@cs.columb "'Anshuman Rawat'"
ia.edu <anshuman.rawat@conexant.com>,
"'priya pandit'"
<priya.panditt@gmail.com>,
12/26/2005 10:09
<sip-implementors@cs.columbia.edu>
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: sip-implementors-bounces@cs.columbia.edu
[mailto:sip-implementors-bounces@cs.columbia.edu] On Behalf Of Ajit
Kumar
Sent: Friday, December 23, 2005 3:14 PM
To: 'Anshuman Rawat'; 'priya pandit'; sip-implementors@cs.columbia.edu
Subject: Re: [Sip-implementors] Multiple 2xx responses
Comments inline
Regards
Ajit
-----Original Message-----
From: Anshuman Rawat [mailto:anshuman.rawat@conexant.com]
Sent: Friday, December 23, 2005 2:36 PM
To: Ajit Kumar; priya pandit; sip-implementors@cs.columbia.edu
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
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
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
Sip-implementors@cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
Sip-implementors@cs.columbia.edu
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
Sip-implementors@cs.columbia.edu
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."
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic