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

From: Michael Hammer <[email-masked]>
Date: Fri, 09 Aug 2002 11:46:08 -0400

In section 9 of the ISUP to SIP Mapping draft it recommends the use of 
re-INVITEs or INFO method if media changes are not needed.

Has the use of the UPDATE method instead of the re-IVNITEs been 
considered?  I believe that would be a cleaner and more lightweight approach.

Mike

_______________________________________________
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: Fri, 9 Aug 2002 20:11:37 -0500

I for one hadn't considered that yet, no. Section 9 doesn't dwell on
post-RFC3261 concepts of early vs. confirmed dialogs, but it assumes that
you are putting a call on hold only after it has been established
(confirmed). If I recall, the UPDATE draft currently recommends against
using UPDATE instead of a re-INVITE on a confirmed dialog; UPDATE is really
intended for use in early dialogs. If we expanded the scope of Section 9 to
consider putting an early dialog on hold, then UPDATE would certainly be the
right thing to consider, but I don't think that's essential in this
iteration of the document.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Michael Hammer [mailto:[email-masked]]
> Sent: Friday, August 09, 2002 8:46 AM
> To: [email-masked]
> Subject: [SIPPING] SUS and RES use of UPDATE method
> 
>

---

From: Michael Hammer <[email-masked]>
Date: Mon, 12 Aug 2002 10:24:41 -0400

Jon,

While much of the language is oriented toward selling the use of UPDATE for 
early media, the text clearly indicates that is not its only use.  From the 
operation overview:

    Operation of this extension is straigthforward. The caller begins
    with an INVITE transaction, which proceeds normally. Once a dialog is
    established, either early or confirmed, the caller can generate an
    UPDATE method that contains an SDP offer [3] for the purposes of
    updating the session. The response to the UPDATE method contains the
    answer. Similarly, once a dialog is established, the callee can send
    an UPDATE with an offer, and the caller places its answer in the 2xx
    to the UPDATE. The Allow header is used to indicate support for the
    UPDATE method. There are additional constraints on when UPDATE can be
    used, based on the restrictions of the offer/answer model.

The recommendation that re-INVITEs be used instead of UPDATE is based on 
the need to allow a human user to respond to the request.  However, in the 
SUS/RES case, the user is making his desire known prior to the sending of 
the request, i.e., hanging-up causing a SUS, picking up causing a RES.

I prefer the notion that INFO carrying SUS/RES be used for the call 
signaling to set the timers, and the GW triggering of that can decide 
(depending on whether automatic silence suppression is used) whether to put 
the media on hold or not.

Mike

---

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 12 Aug 2002 15:29:47 -0400

Well, I don't think we disagree that either UPDATE or re-INVITE could work
for SUS/RES mappings in confirmed dialogs, give or take some trade-offs
either way. Given that this is at worst a matter of optimization, and not
something broken in the design, I'm disclined to change SIPPING-ISUP on this
matter considering that this issue was raised after both WGLC and IETF LC.

Speaking to your argument below, I believe that even in SUS-like situations,
the recipient of a message carrying an encapsulated SUS still might want to
make a decision about whether or not to accept the SDP offer that would put
the media on hold - if it is carried in an INVITE they can review and reject
the offer, if in an UPDATE they prety much can't. When you receive an
UPDATE, since it is a non-INVITE request you must reply immediately. It
isn't the sender of the SUS whose preferences were in danger of being
ignored. There are probably a number of reasons why the SDP offer in an SIP
request resulting from a SUS might not be satisfactory.

The problem with INFO for SUS/RES is that it only works in ISUP-SIP-ISUP
bridging cases. The use of the INFO method is non-interoperable with
ordinary SIP phones which, when they receive an INFO carrying a SUS they
can't possibly understand, will drop it on the floor.

Jon Peterson
NeuStar, Inc.

> Sent: Monday, August 12, 2002 10:25 AM
> To: Peterson, Jon
> Cc: [email-masked]
> Subject: RE: [SIPPING] SUS and RES use of UPDATE method
> 
> 
> Jon,
> 
> > > Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping

---

From: Adam Roach <[email-masked]>
Date: Mon, 12 Aug 2002 14:51:03 -0500

I agree with Jon that this is a situation of a non-bug
being brought up after last call -- we can address it
when we progress the document if it seems necessary,
but it's certainly not worth delaying publication.

A quick note on the viability of using UPDATE instead
of INVITE, though: the concept of using INVITE
instead of, say, INFO is that normal SIP endpoints
that render something to their users to indicate hold
will Do The Right Thing (tm) upon receiving an INVITE.

Taking into account that not all endpoints will implement
UPDATE, you're left with the fact that any gateway that
implements UPDATE for SUS/RES will *also* need to have
the INVITE logic, in case the other end of the call doesn't
understand UPDATE. It seems that a recommendation to use
UPDATE for SUS/RES would introduce additional complexity
in gateways for the rather dubious gain of not sending
an ACK.

<thread snipped>

/a

---

From: Michael Hammer <[email-masked]>
Date: Mon, 12 Aug 2002 17:12:50 -0400

Jon,

I don't see the issue.  If a SIP endpoint doesn't understand the INFO with 
SUS or the UPDATE with an offer, it will likely do nothing, but reject 
those requests.  I don't understand your statement that the recipient of 
the SUS can't reject an UPDATE request.  My thought here was to try and 
maintain separation of the media control and the dialog control.  Using 
re-INVITEs to control media to infer SUS seems rather convoluted to me and 
blurring the two planes with implicit rather than explicit signaling.

Second, I see this as an ISUP feature related to a PSTN phone useful only 
in bridging situations.  Or do you anticipate that every time that a SIP 
phone puts media on hold, that should cause the GW to send a SUS, starting 
timers in the PSTN world?  Maybe I'm missing it, but how do you tell the 
section 9.1 case from the section 9.2 case, particularly if privacy 
restrictions cause the identity of the sending GW to be hidden, leaving the 
GW receiving the re-INVITE guessing.

Mike

---

From: "Alexeitsev, D" <[email-masked]>
Date: Tue, 13 Aug 2002 10:58:11 +0200

Hi

Some comments:

Q.732.2 says:

Call Hold (uses CPG message):
A call may be placed on hold by the calling user, at any time after the call has been answered or additionally as a service provider option:
1)	after alerting has commenced, or 
2)	after the calling user has provided all of the information necessary for processing the call.

Terminal Portability (uses SUS/RES messages):
service request can only be accepted during the "active" phase.

I would support the recommendation to use the UPDATE method for this kind of services as they have no impact on the dialog state and only modify the session.

Greetings,
Denis Alexeitsev