Isn't that exactly what preconditions does. That is, use the 1xx
messages to pas SDP back and forth until both sides have agreed on the
media conditions required.
Jonathan Rosenberg wrote:
The intention was that, when reliable provisionals are used, the answer
would NOT appear in the 200 OK to the original INVITE. The paragraph in
RFC3261 is talking specifically about the case of an unreliable
provisional response.
The drawback of sending the answer in the reliable 18x and then
repeating it in the 200 OK, is what if they are not the same. It gets
really complicated if there are multiple O/A exchanges in UPDATE/PRACK
prior to the final 200 OK.
-Jonathan R.
Paul Kyzivat wrote:
Robert Sparks wrote:
Yes, I did mean 200 INVITE.
On Nov 19, 2007, at 3:22 PM, Sanjay Sinha (sanjsinh) wrote:
It is not clear from the call flow if the 200 OK is for PRACK or
INVITE?
I guess you meant 200 OK for Invite. If that is the case, I think the
RFC is clear that the answer sdp is optional in it and if it does have
an answer sdp, it MUST be idential to answer in 18x.
Really? Point me to where you find this please.
Mostly in 3261 sec 13.2.1. It says:
o 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. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
The first three sentences are the clearly normative part. When
combined with RFC 3262 definition of reliable provisionals, they say
that the reliable provisional contains the answer.
The last sentence doesn't really say the UAS may include sdp in
subsequent responses to the invite transaction, but neither does it
say you can't. It does say the UAC should ignore them if present,
which implies they can be present, but says nothing about what value
they must have if they are present.
AFAIK there is nothing that says the answer may be repeated in the
200. However it is seemingly done a lot, so one had better beware.
Paul
But I think the
offer-answer draft has clarified it further that it should not have any
answer sdp. This is probably harsh in case of one offer-answer
exchange,
but makes sense if there are multiple early dialog offer-answer
exchanges in say Prack/200 OK or using UPDATE.
Sanjay
-----Original Message-----
From: Robert Sparks [mailto:[EMAIL PROTECTED]
Sent: Monday, November 19, 2007 4:14 PM
To: sip List
Subject: [Sip] SIPit21: SDP in a 200OK when using 100rel
There was a lot of discussion and disagreement at SIPit21
about whether the following 200 OK is allowed (or should) have
SDP in it:
INVITE (offer)
-------->
18x (with 100rel) (answer)
<--------
PRACK
--------->
200 OK (can this carry SDP?)
<---------
ACK
--------->
I couldn't find anything definitive in RFC form. Paul's
offeranswer draft talks about this I think.
If I understand things, the right answer here is that it's not
supposed to carry any SDP and that you should ignore it if it shows
up.
The question is, other than waste, what can go wrong if it is there?
When we end up with clear text around the requirement, will it
say SDP SHOULD NOT, or MUST NOT appear?
Or do I have this wrong?
RjS
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
--
**********************************************************************
Lincoln Lavoie
Senior Engineer
UNH InterOperability Laboratory
121 Technology Drive, Suite 2, Durham, NH 03824
+1-603-862-4809
AIM: LincolnAtIOL, MSN: [EMAIL PROTECTED]
Jabber: [EMAIL PROTECTED]
Ars sine scientia nihil est! -- Art without science is nothing.
Scientia sine ars est vacua! -- Science without art is empty.
**********************************************************************
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
