Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 21 Nov 2007 08:19:56 +0100

Hi,

I don't see any use case for this additional answer.

The text in chapter 13.2.1 says that the answer must be sent in "A" (it
doesn't say "only one") reliable response. The text also says that SDPs
in subsequent responses to the INVITE.

I DO agree life would be much easier if we from the beginning would have
said that an answer MUST only be sent ONCE - without "previews",
"re-sendings in additional responses" etc. But, no matter what the
intention of chapter 13.2.1 was, it does cover the case when additional
SDPs are received, so people just have to implement it correctly...

Regards,

Christer

________________________________

	From: [email-masked]
[mailto:[email-masked]] 
	Sent: 21. marraskuuta 2007 5:40
	To: Christer Holmberg
	Cc: Jonathan Rosenberg; Paul Kyzivat; Sanjay Sinha (sanjsinh);
sip List
	Subject: RE: [Sip] SIPit21: SDP in a 200OK when using 100rel

		Since in the UAC point of view the behaviour is defined
clearly, whats the issue?
	Does anybody see any use case for this additional answer, from
an UAS perspective?
	 
	Prince.

	-----"Christer Holmberg" <[email-masked]> wrote:
-----

		To: "Jonathan Rosenberg" <[email-masked]>, "Paul
Kyzivat" <[email-masked]>
		From: "Christer Holmberg"
<[email-masked]>
		Date: 11/21/2007 12:33AM
		cc: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>,
sip List <[email-masked]>
		Subject: RE: [Sip] SIPit21: SDP in a 200OK when using
100rel
		
		Hi,
		
		An implementation should keep offer/answer state and
simply discard the SDP in the 200 OK.
		
		I don't think that is complicated :)
		
		Regards,
		
		Christer
		
		________________________________
		
		From: Jonathan Rosenberg [mailto:[email-masked]]
		Sent: Tue 20/11/2007 17:56
		To: Paul Kyzivat
		Cc: Sanjay Sinha (sanjsinh); sip List
		Subject: Re: [Sip] SIPit21: SDP in a 200OK when using
100rel

		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-masked]]
		>>>> 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-masked] for questions on
current sip
		>>>> Use [email-masked] 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-masked] for questions on
current sip
		>> Use [email-masked] 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-masked] for questions on
current sip
		> Use [email-masked] for new developments on the
application of sip
		
		--
		Jonathan D. Rosenberg, Ph.D.                   499
Thornall St.
		Cisco Fellow                                   Edison,
NJ 08837
		Cisco, Voice Technology Group
		[email-masked]
		http://www.jdrosen.net <http://www.jdrosen.net/>
http://www.jdrosen.net/>                          PHONE: (408) 902-3084
		http://www.cisco.com <http://www.cisco.com/>
http://www.cisco.com/> 

		_______________________________________________
		Sip mailing list
https://www1.ietf.org/mailman/listinfo/sip
		This list is for NEW development of the core SIP
Protocol
		Use [email-masked] for questions on
current sip
		Use [email-masked] 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-masked] for questions on
current sip
		Use [email-masked] for new developments on the
application of sip

	*****Aricent-Restricted *****= 
		"DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for 
	loss or damage arising from the use of the information
transmitted by this email including damage from virus."

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Nov 2007 11:19:21 -0500

[email-masked] wrote:
> Since in the UAC point of view the behaviour is defined clearly, whats 
> the issue?
> Does anybody see any use case for this additional answer, from an UAS 
> perspective?

 From a practical perspective I think that there have been a lot of 
implementors that implemented what they *thought* the spec said, but got 
it wrong. Then others have done what they thought they had to do to 
interoperate.

So there may be some use for this added answer for interoperation with 
certain broken implementations. (But I speak hypothetically - I don't 
have a specific implementation to point to.)

But for those just trying to follow the specs there is no use for this 
added SDP. Nobody should be *using* it. If they are, they need to change.

	Paul

> Prince.
> 
> 
> -----"Christer Holmberg" <[email-masked]> wrote: -----
> 
>     To: "Jonathan Rosenberg" <[email-masked]>, "Paul Kyzivat"
>     <[email-masked]>
>     From: "Christer Holmberg" <[email-masked]>
>     Date: 11/21/2007 12:33AM
>     cc: "Sanjay Sinha \(sanjsinh\)" <[email-masked]>, sip List
>     <[email-masked]>
>     An implementation should keep offer/answer state and simply discard
>     the SDP in the 200 OK.
> 
>     Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel
> 
> 
> 
>     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
>      >> 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
>      >       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
>      > 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
>      > 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
>      >>>> 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)
>      >>>> -------->
>      >>>> I couldn't find anything definitive in RFC form. Paul's
>      >>>> 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
>      >>>> This list is for NEW development of the core SIP Protocol Use
>      >>>> [email-masked] for questions on current sip
>     Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
>     Cisco Fellow                                   Edison, NJ 08837
>     http://www.jdrosen.net
>     <http://www.jdrosen.net/>http://www.jdrosen.net/>                  
>            PHONE: (408) 902-3084
>     http://www.cisco.com <http://www.cisco.com/>http://www.cisco.com/>
> 
> 
> "DISCLAIMER: This message is proprietary to Aricent 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. Aricent accepts no responsibility for 
> loss or damage arising from the use of the information transmitted by this email including damage from virus."
>