Subject: [sipcore] draft-ietf-sipcore-reinvite-03

From: Peter Musgrave <[email-masked]>
Date: Sun, 14 Mar 2010 11:46:53 -0400

Hi Gonzalo/Chris/Gao,

Not sure if this is a nit - or if I am lost...

In Figure 3 the 200 OK for the second INVITE (which made an offer) does not
carry an answer. Is this deliberate? (I have the same issue in Figure 4
making me think perhaps I'm lost.)

If yes, then I think an explanatory comment would be helpful - since I would
expect a 200 with answer .

Regards,

Peter Musgrave

---

From: Brett Tate <[email-masked]>
Date: Sun, 14 Mar 2010 11:16:04 -0700

It is deliberate; see RFC 3261 concerning when answer SDP needs to be within INVITE's 2xx response.  The 18x's were sent reliable; thus completing the offer/answer exchange.  The following is mention above both figures: "PRACK transactions are not shown for clarity".

-brett

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Musgrave
Sent: Sunday, March 14, 2010 11:47 AM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]
Subject: [sipcore] draft-ietf-sipcore-reinvite-03

Hi Gonzalo/Chris/Gao,

In Figure 3 the 200 OK for the second INVITE (which made an offer) does not carry an answer. Is this deliberate? (I have the same issue in Figure 4 making me think perhaps I'm lost.)

If yes, then I think an explanatory comment would be helpful - since I would expect a 200 with answer .

Regards,

Peter Musgrave

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 15 Mar 2010 09:35:51 -0800

Hi Peter,

those 200 (OK) responses do not carry answers because of one of the main
rules of the offer/answer model. That is, the UAS only provides one
answer to a given offer. In the cases you are pointing to, the answer
was provided in a reliable provisional response.

Cheers,

Gonzalo

On 14/03/2010 7:46 AM, Peter Musgrave wrote:
> In Figure 3 the 200 OK for the second INVITE (which made an offer) does
> not carry an answer. Is this deliberate? (I have the same issue in
> Figure 4 making me think perhaps I'm lost.)
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 15 Mar 2010 18:29:27 -0500

> was provided in a reliable provisional response.

There was, IIRC, some discussion on that, with my position being that  
the 200 OK SHOULD have a copy (and if present, it MUST be an identical  
copy!) of the answer provided in the reliable provisional response.

My goal here is that this makes certain debugging scenarios easier. It  
also makes these hideous call flows more palatable to my brain, which  
along with refusing to believe in the square root of negative one also  
seems to have trouble with reliable provisional media and the plethora  
of alternative O/A sattes that can result.

However, I do believe that the consensus was as Gonzalo reports.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Mar 2010 19:50:18 -0400

[as individual]

I differ slightly from Dean on this:

- if the answer has been sent in a reliable provisional,
   it is not required, or expected, in the 2xx.

- for backward compatibility, it MAY, be *repeated* in
   the 2xx, but this is not advised.

The reason its not advised is that its presence there can only cause 
grief, not good. The only valid thing you can do if you receive it is 
ignore it. If you *use* it (i.e. switch to it) then you are going to be 
in a world of hurt if there has been more than one o/a exchange before 
the 2xx is sent. Specifically, in that case the only SDP that is 
permitted to appear in the 2xx is the *first* answer, which may well 
differ from the *last* answer that is to be used for the session.

	Thanks,
	Paul

Dean Willis wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Milinski, Alexander (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 16 Mar 2010 11:18:48 +0100

Hi Paul, Dean,

now I am confused (though I got used to the square root of -1 being i).

Which RFC explains this repetition?

Moreover, how is the repeated answer distingusished from a new offer
(the previous o/a has been completed before),
which should be answered in the ACK?

Regards,
Alex

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of ext Paul Kyzivat
> Sent: Tuesday, March 16, 2010 12:50 AM
> To: Dean Willis
> Cc: [email-masked]; [email-masked]; Peter Musgrave
> Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03
> 
> [as individual]
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 16 Mar 2010 07:00:26 -0400

Hi all,

I would assume a new offer in a 200 OK would be distinguished by
increasing the sess-verssion in the o= line of the SDP.

I do find the issue of repeating an SDP hard to pin down - after
poking into 3261 and 3262...am I looking in the right places?

Peter

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 16 Mar 2010 13:04:41 +0100

Hi Peter, Alexander

Please read RFC 3261, Clause 13.2.1:
 
In this specification, offers and answers
   can only appear in INVITE requests and responses, and ACK.  The usage
   of offers and answers is further restricted.  For the initial INVITE
   transaction, the rules are:
      o  The initial offer MUST be in either an INVITE or, if not there,
         in the first reliable non-failure message from the UAS back to
         the UAC.  In this specification, that is the final 2xx
         response.
      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.
      o  If the initial offer is in the first reliable non-failure
         message from the UAS back to UAC, the answer MUST be in the
         acknowledgement for that message (in this specification, ACK
         for a 2xx response).
      o  After having sent or received an answer to the first offer, the
         UAC MAY generate subsequent offers in requests based on rules
         specified for that method, but only if it has received answers
         to any previous offers, and has not sent any offers to which it
         hasn't gotten an answer.
      o  Once the UAS has sent or received an answer to the initial
         offer, it MUST NOT generate subsequent offers in any responses
         to the initial INVITE.  This means that a UAS based on this
         specification alone can never generate subsequent offers until
         completion of the initial transaction.
 
Regards, Thomas

________________________________

Von: [email-masked] im Auftrag von ext Peter Musgrave
Gesendet: Di 16.03.2010 12:00
An: Milinski, Alexander (NSN - DE/Munich)
Cc: [email-masked]; [email-masked]
Betreff: Re: [sipcore] draft-ietf-sipcore-reinvite-03

Hi all,

Peter

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 16 Mar 2010 08:27:06 -0400

Hi Thomas,

Thanks for the reference. I was reading that part of the spec. but
could not make my mind up about whether it forbids sending a copy of
the SDP in the 200 (if a reliable response had been provided). The
closest I came was the statement:

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.

Which makes me think if this does happen it MUST be ignored. So that
convinces me that it's not a good idea. I just didn't see any language
saying it was forbidden. Perhaps it should have been. I think what
makes this something I have to think/read carefully about is the lack
of examples in PRACK/3262.

Apologies to all if I am belabouring the point here.

Peter

---

From: Gilad Shaham <[email-masked]>
Date: Tue, 16 Mar 2010 14:32:56 +0200

> of examples in PRACK/3262.
If you are looking for some offer answer usages in SIP you can also refer to
http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer

In general, offer-answer has in practice many interop issues, so it's best
to keep your implementation as permissive as possible in terms of what you
expect to receive.

---

From: [email-masked]
Date: Tue, 16 Mar 2010 20:55:58 +0800

Hi,

please see inlines.

Thanks,

Gao 

===================================
 Zip    : 210012
 Tel    : 87211
 Tel2   :(+86)-025-52877211
 e_mail : [email-masked]
===================================

Peter Musgrave <[email-masked]> 
2010-03-16 20:27

收件人
"Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
抄送
"Milinski, Alexander (NSN - DE/Munich)" <[email-masked]>, 
[email-masked], [email-masked]
主题
Re: [sipcore] draft-ietf-sipcore-reinvite-03

Hi Thomas,

Thanks for the reference. I was reading that part of the spec. but
could not make my mind up about whether it forbids sending a copy of
the SDP in the 200 (if a reliable response had been provided). 

[Gao] RFC3261 has such definition:
o  Once the UAS has sent or received an answer to the initial
         offer, it MUST NOT generate subsequent offers in any responses
         to the initial INVITE. 

I think this is the definition you are seeking.

//////////////////////////////////////////////////////////
The
closest I came was the statement:

Peter

>         completion of the initial transaction.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Mar 2010 09:27:10 -0400

> of examples in PRACK/3262.

The language is not very clear, and can only be discerned in total by 
integrating across several RFCs and making various inferences. This led 
to a very long email discussion/debate on the subject several years ago. 
That in turn led to the writing of the offeranswer draft, which attempts 
to capture all that. We have concluded that it is all just 
clarification, rather than normative changes.

> Apologies to all if I am belabouring the point here.

Don't feel too bad - it comes up every few months. If you haven't, 
please read the offeranswer draft:

http://www.ietf.org/id/draft-ietf-sipping-sip-offeranswer-12.txt

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Mar 2010 09:30:10 -0400

Paul Kyzivat wrote:
> 
> ... We have concluded that it is all just 

I should have said more...

We decided what ambiguities required normative action should be dealt 
with separately from the o/a draft. draft-ietf-sipcore-reinvite is a 
normative draft doing just that.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Tue, 16 Mar 2010 15:14:20 -0500

On Mar 16, 2010, at 5:18 AM, Milinski, Alexander (NSN - DE/Munich)  

> Which RFC explains this repetition?

None, really. We didn't do it like I wanted it.

> which should be answered in the ACK?

The principle of repetition would say that you answer it again in the  
ACK, with an identical answer to that already sent. In other words,  
one is simply confirming in the "final" response that which was  
previously sent "provisionally". Provisional means "temporary until  
confirmed in a separate exchange", which means to me that there ought  
to be a final confirmation of the O/A executed in the provisional  
messages.

Note that I also argued that either we should have no O/A in reliable  
provisional, or that reliable provisional O/A should become mandatory  
and exclusive;  that is, that the "regular" offer/answer be discarded  
in favor of doing it in a reliable provisional exchange. This has some  
benefits when trying to grapple with the early media / early session  
problem in conjunction with PSTN gateways, and it's also useful for  
dealing with the folks who think that billing begins on 200 OK, who  
pretty much just annoy me.

--
Dean

---

From: "WORLEY, DALE R (DALE)" <[email-masked]>
Date: Tue, 16 Mar 2010 21:48:47 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Brett Tate [[email-masked]]
Sent: Sunday, March 14, 2010 2:16 PM
To: Peter Musgrave; [email-masked]
Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-03

It is deliberate; see RFC 3261 concerning when answer SDP needs to be within INVITE’s 2xx response.  The 18x’s were sent reliable; thus completing the offer/answer exchange.  The following is mention above both figures: “PRACK transactions are not shown for clarity”.
_________________________________________

It might avoid confusion if that note was extended with "Note that in some cases, the SDP answer is carried in a PRACK which is not shown."

Dale

---

From: [email-masked]
Date: Wed, 17 Mar 2010 12:41:13 +0800

> The principle of repetition would say that you answer it again in 
> the ACK, with an identical answer to that already sent. In other 
> words, one is simply confirming in the "final" response that which 
> was previously sent "provisionally". Provisional means "temporary 
> until confirmed in a separate exchange", which means to me that 
> there ought to be a final confirmation of the O/A executed in the 
> provisional messages.

[Gao] Hi Dean,
I think as the UAS send the Answer in one reliable response, there's no 
need to copy the same Answer as the confirmation in the final respone.
There are UASs do not support 100rel, so they send the SDP(no as Answer) 
in 1xx for early media usage. This is the case UAS should copy the same 
SDP as Answer in the final respone. 
And send SDP in another reliable response after the initial O/A is 
violation of current RFC3261's definition. I do not prefer there rules to 
be re-defined except for strong reasons.

> 
> Note that I also argued that either we should have no O/A in 
> reliable provisional, or that reliable provisional O/A should become
> mandatory and exclusive;  that is, that the "regular" offer/answer 
> be discarded in favor of doing it in a reliable provisional 
> exchange. This has some benefits when trying to grapple with the 
> early media / early session problem in conjunction with PSTN 
> gateways, and it's also useful for dealing with the folks who think 
> that billing begins on 200 OK, who pretty much just annoy me.

[Gao] I think the early media problem in conjunction with PSTN gateways 
can be solved by using p-early-media and its policy.

Thanks,

Gao

---

From: Dean Willis <[email-masked]>
Date: Wed, 17 Mar 2010 00:43:21 -0500

On Mar 16, 2010, at 11:41 PM, [email-masked] wrote:

>
> [Gao] Hi Dean,
> I think as the UAS send the Answer in one reliable response, there's  
> no need to copy the same Answer as the confirmation in the final  
> respone.

That was also the consensus of the working group.

> There are UASs do not support 100rel, so they send the SDP(no as  
> Answer) in 1xx for early media usage. This is the case UAS should  
> copy the same SDP as Answer in the final respone.

So, a reliably sent answer is a "final Answer", and an unreliably-sent  
answer is just being hopeful.

> violation of current RFC3261's definition.

That's actually debatable; as quoted earlier in this thread, RFC 3261  
is not completely clear on whether a copy of the same answer is a  
different answer. Certainly, CHANGING the answer is forbidden, but  
repeating it might not be. That's pat of why we have further drafts to  
clarify this.

> I do not prefer there rules to be re-defined except for strong  
> reasons.

I concur. Of course, one of the best reasons for more definition is  
because the rule wasn't well defined to start with.

> [Gao] I think the early media problem in conjunction with PSTN  
> gateways can be solved by using p-early-media and its policy.

Not without changing the gateway billing model, I think. But I look  
forward to somebody writing an I-D on how this might work.

--
Dean

---

From: [email-masked]
Date: Wed, 17 Mar 2010 17:34:48 +0800

respone. 
> So, a reliably sent answer is a "final Answer", and an unreliably-
> sent answer is just being hopeful.

[Gao] Yes. But I think there's meaning to send the non-answer-SDP before 
the Answer. And doing has no conflict with current RFCs.
I just think sending the non-answer-SDP after the Answer is not proper.

> That's actually debatable; as quoted earlier in this thread, RFC 
> 3261 is not completely clear on whether a copy of the same answer is
> a different answer. Certainly, CHANGING the answer is forbidden, but
> repeating it might not be. That's pat of why we have further drafts 
> to clarify this.

[Gao]
RFC3261 has such definition:
o  Once the UAS has sent or received an answer to the initial
         offer, it MUST NOT generate subsequent offers in any responses
         to the initial INVITE. 

I think after the initial O/A, UAS's SDP in another reliable response is 
the case. So, it is forbidden to send the new SDP(offer).
In fact, someone may argue we may say the SDP is the second Answer. To be 
honest, I just *feel* the SDP in another reliable response after one O/A 
should be treated as Offer. 

> 
> I do not prefer there rules to be re-defined except for strong reasons. 
>