Subject: [Sipping] RE: Meaning of status codes

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 5 Dec 2002 05:14:09 -0500

Some notes inline.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Gonzalo Camarillo [mailto:[email-masked]]
> Sent: Wednesday, December 04, 2002 11:33 PM
> To: Francois Audet
> Cc: 'William Marshall'; [email-masked]';
> [email-masked]'; [email-masked]';
> [email-masked]'; 'Alan Johnston'; sipping; Adam Roach
> Subject: Meaning of status codes
> 
> 
> Folks,
> 
> we have had some private mail exchanges regarding the early media draft
> about the meaning of the status codes. 
> 
> I maintain that the information of any status code is completely
> orthogonal to the status of the media session. That is, the status code
> does not tell you anything about the media session. It does not tell you
> that you will have media and it does not tell you that you will not have
> media either. Those are offer/answer issues. NOthing to do with the
> status code.
> 
> Therefore, if a UA received a 180 Ringing response, all the UA knows is
> that the other party is being alerted. Nothing about who will generate
> the ringback tone (this info will be in the offer/answer).
> 

The issue is that the text in RFC3261 you refer to below says that a UAC MAY
generate local ringback when it receives a 180. The text makes no mention
that offer/answer should be factored in to its decision about this matter.
The reason for this, I think, is that the alternative to locally-generated
ringback that we are considering here (transmission of provisional media
from a gateway) is not a part of normal UAS behavior. No native SIP phone
UAS should send a ringing tone over a media stream instead of merely sending
a 180 - playing a ringing tone over a media stream is comparatively very
inefficient and should be counterindicated.

The text in sipping-isup-06 started from the assumption that when a 180 is
sent, a UAC might start to generate local ringback - in the case I described
above, where a native SIP phone UAS sends a 180 with no media, a UAC SHOULD,
I think, do something to tell its user that the remote end is being alerted,
which depending on its interface and capabilities MAY entail generating a
local ringtone. So, I think the assumption made in sipping-isup-06 is quite
reasonable.

If it is your position that RFC3261 says that UACs categorically cannot
generate local ringback unless offer/answer tells them to do so, then our
interpretations definitely differ.

> And I believe that my view is consistent with the SIP way of doing
> things. 

The SIP way of doing things is to describe the provisional status of a
dialog with response codes. Early media is the aberrant case in which that
is not possible; status information about the dialog is provided in-band
instead of in status codes.

> However, some folks believe that I am wrong, and that the status
> codes give you information about the media session, as you can see
> below:

I think it is the other way around - the media session (the in-band audio)
gives you information you would ordinarily get from status codes. That
leaves us with a problem when we select a status code to represent this
condition (that some media is coming that will give you further status). 180
might not be suitable suitable.

> 
> > Gonzallo, it seems that Bill, Alan, Jon and myself all share the view
that
> > it is consistent with 3261 (and sip-isup-06) to couple 180 with locally
> > generated ringback.
> 

I don't couple them, personally - I don't think RFC3261 says that you MUST
generate local ringback when you receive a 180. But because the UAC MAY do
so, a gateway MUST NOT assume that local ringback will NOT be generated when
a 180 is received (regardless even of offer/answer - though conceivably, an
extension could override this). I don't think the text admits of any other
interpretation. I mean, 180 means ringing, means that the user is being
alerted. But that isn't necessarily what provisoinal media means.

> Just as a clarification, the text above refers to a MAY in the SIP spec
> when defining 180. IMO, that MAY is correct.
> 
> I would like to get more opinions on this. What do people think about
> this?
> 
> 1) Status codes and media are two different things
> 2) Status codes and media have to be coupled
> 
> 
> And please, try to answer the question I am asking. 

Actually, this question isn't the issue you described above. That question
would be:

1) Status codes and locally-generated ringback are two different things
2) Status codes and locally-generated ringback have to be coupled

The relationship between media and locally-generated ringback is at the core
of this issue, but the two are hardly identical.

In any event, there is clearly only one politically-correct answer to the
question you posed, which is (1). However, as I said above, early media
through gateways (the problem we are considering) is a case in which the
media stream is used to describe the status of the call.  This is not a
'normal' SIP condition - native SIP should never do this. This is an
aberrant condition that occurs only in gateway interworking. In this case,
quite literally, (2) is true - status is completely and necessarily coupled
to media. Figuring out how to make this work with native SIP is the essence
of the early media problem (as are the related considerations of clipping,
forking, etc).

I'd also like to say that I think we are expending a lot of mental effort on
this small part of the problem (180 and local ringback) unnecessarily.
In-band provisional status information can be mapped to the 183 status code,
which has no connotation of local ringback (the spec doesn't suggest that
one MAY generate local ringback when 183 is received). This is important
because early media from a gateway may not in fact be ringing (it can be a
busy signal or announcement), but in cases where status is in-band, the
gateway really has no way to know what dialog status is reflected by the
media it is about to transmit to the UAC.

It does seem obviously mistaken to me to use a 180 Ringing status code (even
with an SDP answer) to communicate the presence of early media when that
media could contain a busy signal. Imagine a UAC with a graphical interface
that reads "Ringing" when a busy tone is playing over the audio channel. 183
is neutral as to the state of the call - it doesn't suggest that the
end-user is being alerted. I therefore think it is much better suited to the
early media case.

> Every time we tackle
> something that is somehow related to the PSTN we end up with endless
> threads that miss focus easily. 

We are still trying to find the scope of the problem. I think it is little
too early to declare what is in focus and what it out of focus.

> Let's try to avoid that.
> 
> As I stated previously, I believe 1) is the way to go.
> 
> Thank you,
> 
> 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

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 05 Dec 2002 13:09:03 +0200

Jon,

> that offer/answer should be factored in to its decision about this matter.

I agree with this MAY. And I believe that it is OK as well that the SIP
spec does not specify in which circumstances you will generate the
ringback and in which situations you wouldn't. This decision will depend
on many factors, ranging from the offer/answer to the presence of a
speaker in your SIP system.

I have described this before as a "local policy decision". Therefore, I
agree that you MAY generate local ringback upon reception of a 180. But
I disagree that this has to be a MUST.

But I believe that our positions on this are not that different.

> inefficient and should be counterindicated.

I disagree with this. I want my UAS to send you a 180 Ringing and at the
same time play (early) media saying "Today Gonzalo is upstairs repairing
the ceiling, it may take a little longer than usual for him to come down
to pick up the phone. Please be patient. I am already alerting him". I
believe that this should be possible even in a SIP to SIP (i.e., no
gateways) scenario.

> above, where a native SIP phone UAS sends a 180 with no media

This is where our assumptions differ. I believe that a vanilla SIP UAS
may send early media and a 180 Ringing (the example above) at the same
time.

>, a UAC SHOULD,

My position is that we should at least document scenarios where
generating local ringback upon reception of a 180 may not be such a
great idea. Nothing normative, because even if your UAC generates local
ringback while I am sending you the early media message in the example
above, nothing in the protocol will break. But to have a better user
experience, it would be useful to explain in which scenarios you may not
want to do that.
 
> instead of in status codes.

Fair enough. In band media will provide you with status information. But
that does not mean that you have to ignore the status codes because of
that. Therefore, if I am a SIP entity (e.g., a gateway) that knows well
that the user is being alerted, I will send a 180 even if I am
generating early media.

Therefore, I would say "and" rather than "instead of" in your sentence
above: "status information about the dialog is provided in-band
AND in status codes."

> alerted.

I agree 100% with this last statement. I would add: 180 means that the
user is being alerted, "nothing more".

> But that isn't necessarily what provisoinal media means.
> 
> question you posed, which is (1).

I agree with that.

> However, as I said above, early media
> aberrant condition that occurs only in gateway interworking.

I believe that we are almost in agreement about everything but this
part. You believe that a vanilla SIP UAS will never send early media
with a 180, and I believe it MAY.

> In this case,

Note that I am not claiming that you MUST send a 180 if you have early
media. I am saying that, if the user is being alerted, you MUST send a
180. But if the user is busy, you, of course, will not send a 180. You
would send a "18x Busy" response or, if you do not have any 18x status
code that is appropriate (because 18x Busy does not exist), you would
send 183 Session Progress.

I guess what I am saying can be summarized as follows: in a given
moment, a UAS has to send the provisional status code whose semantics
are closer to what is going on in reality, regardless of the presence or
absence of in-band information.

Thanks for the comments,

Gonzalo