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

From: Al Varney <[email-masked]>
Date: Mon, 12 Aug 2002 23:20:24 -0500

At 08:11 PM 8/9/02 -0500, Peterson, Jon wrote:

>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.

    Four (too lengthy) comments.

  1) For SIP-ISUP draft:  Note that Q.764, 2.4.1 constrains SUS/RES to only 
answered calls.  That shouldn't constrain SIP behavior, but I don't believe 
a gateway should be generating ISUP SUS/RES messages that are 'unexpected' 
by the PSTN.  (That's not an argument for UPDATE vs. re-INVITE, just an 
ISUP constraint.)

  2) Regarding the "holding" before answer:  At one time in the USA PSTN, 
it was possible to 'flash', placing calls on hold before the initial call 
was answered.  For example, the second leg of a three-way or conference 
call could be initiated while the initial call was still 
ringing.  Unfortunately, some deliberate pranks are then easy, as well as 
the potential for illegal harassment.

    Also, any in-band call progress tones/announcements from the network 
regarding the called party go un-heard while on hold, because the media 
stops in both directions at the local exchange.  Worse, two separate call 
attempts in quick succession, with the first unanswered, can be treated by 
the local exchange as a 'flash' + three-way call.  The first call would 
continue ringing (unknown to the caller), and might eventually be 
answered/billed (but there's no caller any more).  Since the PSTN uses 
'calling party control' for most calls, the first call continues to be held 
(and billed) even after the called party hangs up.  Only after the caller 
disconnects from the second call would billing stop for the first.

   For these reasons (and others), the PSTN now typically ignores 'flash' 
triggers while the current call is un-answered.  I realize a SIP UAC/UAS 
could intelligently manage 2 or more early dialogs and any associated early 
media, and should not be constrained by past PSTN limitations.  There are 
likely good applications of this capability.  I'm only suggesting that, 
particularly when interworking a SIP call to a PSTN gateway, it might be 
useful to have human callers be able to hear any tones/announcements when 
other simultaneous dialogs are initiated.  Maybe that's not a protocol 
issue, just good UAC/UAS design?  After all, if you INVITE someone to come, 
isn't it rude to not be there when they accept?

> > From: Michael Hammer [mailto:[email-masked]]
> > Sent: Friday, August 09, 2002 8:46 AM
> >
> > 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.

  3) On Section 9:  It might have been clearer if section 9.1 more clearly 
labeled/described the 'network initiated' SUS/RES case, with more than just 
a sentence in the first paragraph.  Network-initiated SUS/RES uses timers 
T6/T38, rather than T2, and occur so often and briefly that it probably 
doesn't make sense to do any media changes for that case.  Maybe 
network-initiated should have been a section 9.3 to avoid confusion.

    And since the ISDN-subscriber version of SUS is pretty rare, I'm not 
sure the removal of media via SIP is worth the design/implementation 
effort.  If the media flow must be stopped for 9.1 or 9.2 cases, wouldn't 
it be easier to just interrupt the ISUP/IP circuit inter-connection 
controlled by the gateway(s)?

    Also, since the PSTN does not treat the network-initiated SUS as 
implying any sort of "hold", it would seem reasonable to keep the 
indication of "called party on-hook" to a SIP caller clearly separate from 
SIP indications of ISDN subscriber-initiated SUS and CPG HOLD.  SIP 
services (and some legal mandates) might require special treatment of the 
former (quick disconnect) but disconnect would be inappropriate for a true 
far-end-on-hold situation.

  4) T6 confused with T38?:  Section 10.2.2 covers SUS prior to REL.  It 
implies timer T6 is running in the PSTN (at the callee exchange) when it 
would normally be running at the originating node (the MGC in the 
example).  T38 would be running at other exchanges in the PSTN, possibly 
including the callee exchange.  Since T6 is a shorter value, this would 
change the direction of REL (would be sent MGC-to-PSTN).  Only if the 
exchange running T6 failed to respond with REL would T38 expire.

    In a SIP bridging scenario, T6 would be running in a node on the other 
(left) side of the SIP connection, and any T38 expiry could result in REL 
from the PSTN as shown.  But that's an unusual case in the PSTN.

---
    Jon, you state that the on-hook callee case is "the more common case by 
far" (in 9.1).  I agree.  Looking at some old ISUP data, 41% of answered 
calls generated 1 or more SUS messages.  Of several thousand SUS messages, 
none were "ISDN subscriber initiated".

Al Varney

_______________________________________________
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: Christer Holmberg <[email-masked]>
Date: Tue, 13 Aug 2002 09:22:15 +0300

Hi,

>intended for use in early dialogs.

Isn't UPDATE going to be added to the session-timer spec, which is a feature on a
CONFIRMED dialog?

>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.

Why would the USER have to accept an SDP that would put the media on hold? If one
wants to put the media on hold there is really not much the other party/parties
in the call can/should do about that, is there?

Also, I think that the recipient of a new offer almost always have to make a
decision if to accept/reject it. No, the human user may not be alerted, but the
"media handler" still MAY have to make a decission if, or if not to, accept the
offer. In most cases that will probably take a very short time (even if the media
handler is in another node, controlled by H.248, for example), so the response
will be sent "immediately" from a SIP time perspective point of view, but I still
think that "must be responde to immediatly" is a little missleading when we talk
about UPDATE (and, also PRACKs carrying offers).

A little off-topic maybe, but I'd appreciate your comments :)

Regards,

Christer Holmberg
Ericsson Finland