Subject: [Sipping] netann Issue #2: Result Code for Early Media Termination

From: "Eric Burger" <[email-masked]>
Date: Thu, 20 Mar 2003 14:43:49 -0500

Problem: How does the media server signal that it has completed an early media announcement?

Prior drafts had the media server send a 487 REQUEST TERMINATED result code.  However, RFC3261 reserves that result code as a response to a request sent after the UAS has processed a BYE or CANCEL from the UAC.

The behavior netann seeks is identical in every way to a user that rejects a *particular* connection attempt.  That is, the rejection must not imply the user is not there, will not be there later, or that there is a failure at the media server.  We cannot have a proxy server optimize attempts by thinking that the annc user is not available and thus should not make follow-on connection attempts.

Options are:

410 GONE - Doesn't work because this implies a permanent condition; "annc" clearly is still at the media server.

480 TEMPORARILY UNAVAILABLE - looks identical to a user rejecting a call, e.g., Do-Not-Disturb.  Implies that another attempt to the same user (annc) may succeed.

486 BUSY HERE - also a good choice: identical to a user rejecting a call, AND lets the UAC play local busy tone after the announcement finishes.  If the user misses the announcement, they will still get meaningful call progress.  Note that 486 was the result code used in -00.  It was changed to 487 in -01 because some people felt that 486 might indicate something about the original target of the request that was not true.

487 REQUEST TERMINATED - we were trying to capture the idea of a request that had some treatment but was ultimately canceled.  Thus there was a virtual CANCEL from the UAC after the announcement played.  Even though any 4xx response should terminate a session, there is a non-conforming SIP phone that ignores 487's on dialogs where the phone did not send a CANCEL or BYE.

600 BUSY EVERYWHERE - a good choice: not only does it look like the user rejecting a call and the UAC playing local busy as in 486, but it stops forking proxies from continuing a search at locations other than the one that resulted in an announcement.  The only problem is, this might be seen as a bug, not a feature.

603 DECLINE - this would be an excellent choice, except for one possible problem.  6xx responses are 'definitive'. My concern is a zealous proxy might 'optimize' a 6xx response and hold-off further attempts to a given request-URI.  In fact, that is the correct action if there is a Retry-After header.  If the media server could return 603 with a Retry-After: 0, then there would not be a problem.  However, zero is not a valid Retry-After value.  Although it is not conforming behavior, if a proxy uses a non-zero default Retry-After value, future announcement requests will be blocked for a period of time.

4xx or 6xx new code - we could "say what we mean" and create a new response code.  The semantics of this code are "the user rejected the call."  However, given that this is identical to 480 or 603, why would we not simply use 480 or 603?

Proposal:
Use 480, because we do not want to break meaningful forking proxies.
_______________________________________________
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: Gonzalo Camarillo <[email-masked]>
Date: Mon, 31 Mar 2003 13:45:48 +0300

Eric,

the issue here is that you are using the INVITE request in a very
peculiar way. Typically, the purpose of an INVITE is to establish a
session. That's why, when the session is established, you send a 200 OK
(the purpose of the INVITE - session establishment - went OK).

However, you are proposing to send an INVITE whose purpose is not
establishing a session. Its purpose is to do something in the media
stream, and then send back a status code saying that the purpose of the
INVITE (not establishing a session, but playing an early announcement)
went OK.

On one hand, you would want to send a 200 OK (the announcement was
played)... but on the other hand, you cannot (there was no session
established).

Thus, you are looking for a status code that means "OK" for this
particular scenario...

In any event, since you say in the draft that an INVITE that triggers an
announcement has an implicit CANCEL associated to it, 487 sounds like
the most appropriate status code.

Besides, I would assume that this status code will seldom reach the UAC.
The proxy (application server) will typically provide the UAC a more
meaningful status code to the UAC (e.g., Busy) upone reception of the
487 from the media server.

Gonzalo

-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 30 52
FIN-02420 Jorvas          Email :  [email-masked]
Finland                   http://www.hut.fi/~gonzalo
_______________________________________________
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