Subject: Re: AD Response Re: [SIPPING] SUS and RES use of UPDATE method

From: [email-masked]
Date: Wed, 14 Aug 2002 10:57:31 EDT

In a message dated 8/13/02 7:00:53 AM Eastern Daylight Time, [email-masked] 
writes:

> Michael,
> 
> The IETF process is that we have a IETF/community-wide Last Call
> for an announced time.  The previous step of Working Group 
> Last Call is expected to be more repeatable and subject to more 
> flexible timings. The IETF Last Call for sipping-isup closed on
> August 5.
> 
> Comments and discussion are valued, but at this point, we would
> need you to be exposing a very serious flaw.  
> 
> Allison
> 

I presume, since the Last Call for sipping-isup was on version -03 and there 
has already been a version -04 and -05 submitted, and there has been 
substantial on-going discussions on the list regarding what seem to be 
fundamental issues, and one of the authors indicated on 8/8 that he would 
change the new section 12.2 in -05 based on some comment (which appears to be 
independent of any comments submitted on the Last Call), that the IESG must 
have concluded that this draft is not ready for approval.

Note that -05 grew in size by 26k from -03, so there must be a lot of 
changes, which surely requires a new Last Call process.

Am I correct?

Mike Pierce
Artel

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 14 Aug 2002 14:29:19 -0400

The issues that have been discussed on the list in the last few days are not
'fundamental', in my opinion. They are interesting, and obviously
controversial, but they are quite specific details of mapping
implementation. 'Fundamental' would be "I think ISUP encapsulation is
untenable" or something. Trust me, the review process of RFC3261 led to
quite a few changes throughout WG and IETF LC, including fairly radical
ones. From all of the mail on SIPPING, as well as communications I have
received in private, I can say that sipping-isup-05 has received significant
review from the group.
 
The results of that review have been three questions:
 
1) Should UPDATE or re-INVITE be mapped to SUS?
2) Should 180 or 183 be sent by a gateway when in-band media is available
from the ISUP side?
3) How do you map interworking indicators FCI/BCI?
 
Of these questions, only the first one is new - the other two have been the
subject of consideration here for some time. All three have been answered, I
think, in the discussions that have taken place here.
 
I agree that there were a number of changes in response to IESG comments.
The most significant were the addition of normative language
(RFC2119-ification) and increased Security Considerations. Between the two
they resulted in a lot of new text, but not much new behavior. None of that
behavior has been the subject of any controversy in the ensuing discussions.
 
Jon Peterson
NeuStar, Inc.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, August 14, 2002 10:58 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: AD Response Re: [SIPPING] SUS and RES use of UPDATE method 

Michael, 

Allison 

I presume, since the Last Call for sipping-isup was on version -03 and there
has already been a version -04 and -05 submitted, and there has been
substantial on-going discussions on the list regarding what seem to be
fundamental issues, and one of the authors indicated on 8/8 that he would
change the new section 12.2 in -05 based on some comment (which appears to
be independent of any comments submitted on the Last Call), that the IESG
must have concluded that this draft is not ready for approval. 

Am I correct? 

Mike Pierce 
Artel

---

From: Michael Hammer <[email-masked]>
Date: Thu, 15 Aug 2002 11:54:55 -0400

All,

I do not wish to upset the consensus of the group or the process.  But, I 
came across something that appeared (at least to me) to be ambiguous and 
wished to clear that up.

The UPDATE was merely a suggestion based on the principle of separation of 
call signaling and media control proposed by others on this list.  I had 
thought that in those cases where it is only the media that is changing and 
not the parties to the dialog (e.g., a redirection) then a series of UPDATE 
transactions could be performed rather than a re-INVITE.  I had assumed 
that the number of SIP headers to process would be fewer and therefore 
faster.  I did not see a difference between an:

UPDATE-->
<--response
human decision
<--UPDATE
response-->

and the:

INVITE-->
<--100 Trying
human decision
<--200 OK
ACK-->

sequence.  They appeared isomorphic to me.  I will not fall on my sword if 
the group puts this out without that.  That discussion is probably better 
to be had within the context of the UPDATE draft.

But, I would appreciate if someone would confirm or clarify the following:

It had seemed to me that the essence of the SUS message revolves around the 
use of timer T2 and the decision to release the call or not.  I thought 
this was an ISUP feature and not a SIP feature, and thus thought that this 
would be absent from SIP endpoint to PSTN phone cases, and only apply in 
transit bridging cases.

In another discussion with Jon, he pointed out that one can tell the 
difference between a re-INVITE with SDP indicating hold causing a SUS to be 
generated (9.1) versus a CPG (9.2) by the encapsulated ISUP carried in the 
re-INVITE.  In transit cases this may be clear.  In cases, where the 
re-INVITE arrives without an ISUP body, it is ambiguous, unless you default 
to the 9.2 case and send a CPG.  If so, the only cases where a SUS would be 
sent would be in transit cases.

So, can I assume that 9.2 is used if no ISUP body is present?  Can I assume 
that a SIP end-point will not cause a SUS to be sent?  If not, what 
protocol element triggers one over the other.

Mike

At 02:29 PM 8/14/2002 -0400, Peterson, Jon wrote:
>The issues that have been discussed on the list in the last few days are 
>not 'fundamental', in my opinion. They are interesting, and obviously 
>received in private, I can say that sipping-isup-05 has received 
>significant review from the group.
>
>Of these questions, only the first one is new - the other two have been 
>the subject of consideration here for some time. All three have been 
>answered, I think, in the discussions that have taken place here.
>
>they resulted in a lot of new text, but not much new behavior. None of 
>that behavior has been the subject of any controversy in the ensuing 
>discussions.
>
>Jon Peterson
>NeuStar, Inc.
>In a message dated 8/13/02 7:00:53 AM Eastern Daylight Time, 
>[email-masked] writes:
>
>
>
>>Michael,
>>
>I presume, since the Last Call for sipping-isup was on version -03 and 
>there has already been a version -04 and -05 submitted, and there has been 

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 15 Aug 2002 18:42:54 -0400

A few (last?) comments on this issue below - we certainly have other things
to focus on here...

Jon Peterson
NeuStar, Inc.

> From: Michael Hammer [mailto:[email-masked]]
> Sent: Thursday, August 15, 2002 8:55 AM
> To: Peterson, Jon
> Cc: [email-masked]'; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: AD Response Re: [SIPPING] SUS and RES use of 
> UPDATE method 
> 
> 
> All,
> 
[snip]
> I had assumed 

One difference is that the SDP answer to an offer in an UPDATE actually
appears in the 2xx response to the UPDATE, not in another UPDATE message
sent in the backwards direction. If the response to the initial UPDATE could
not contain the answer, there's a problem (in other words, this is an issue
about where 'human decision' takes place). The response to UPDATE must
either reflect that the change has been made, or reject the request (as
described in sip-update-02 5.2), so any human decisions need to happen
between the SDP offer and SDP answer:

   If the session description has changed, the UAS MUST
   adjust the session parameters accordingly and generate an answer in
   the 2xx response.

   However, unlike a re-INVITE, the UPDATE MUST be
   responded to promptly, and therefore the user cannot generally be
   prompted to approve the session changes. If the UAS cannot change the
   session parameters without prompting the user, it SHOULD reject the
   request with a 504 response.

The other fact, one whose failure to persuade is a little puzzling to me, is
the simple statement in 5.1 that:

   Although UPDATE can
   be used on confirmed dialogs, it is RECOMMENDED that a re-INVITE be
   used instead.

Why isn't this sufficient to argue for a re-INVITE here? Even if they are
'isomorphic', is there any advantage to switching to UPDATE? Was something
broken before? This is what I don't understand.

> to be had within the context of the UPDATE draft.

Agreed this is a discussion to be had about UPDATE, and please don't fall on
your sword. It wasn't a useless or stupid suggestion, but I am a little
unclear as to why you persist in presenting it in the face of the textual
evidence above, especially when you don't argue that it has some clear
advantage over the existing method.

> protocol element triggers one over the other.

Yes, that is our intention - 9.2 should be used if no ISUP body is present.
It is also our intention that there is no circumstance under which a normal
SIP phone putting a call on hold will instruct a gateway to send a SUS,
explicitly or implicitly. If this seems confusing in sipping-isup-05, I'd be
happy to add some text to that effect at the beginning of section 9.