Subject: [Sipping] Meaning of status codes

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

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

And I believe that my view is consistent with the SIP way of doing
things. 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:

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

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. Every time we tackle
something that is somehow related to the PSTN we end up with endless
threads that miss focus easily. 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: Alan Johnston <[email-masked]>
Date: Thu, 05 Dec 2002 09:48:42 -0600

Gonzalo,

See my comments below.

Thanks,
Alan.

>when defining 180. IMO, that MAY is correct.

I wrote this text in 3261, and it is a MAY because the UA might not have 
audio capabilities.  For example, sending an INVITE to setup a instant 
messaging session, the client receiving a 180 Ringing would not play 
ringback, instead it would flash a message or pop up a window, for example.

The MAY does not mean that the calling UA MAY ignore the meaning of the 180 
ringing.

>threads that miss focus easily. Let's try to avoid that.

The problem here is that #1 is not backwards compatible with deplyoed PSTN 
gateways today.  Some of us have commercial services using these 
gateways.  Making a non-backwards compatible change is just not possible 
now.  Any suggestion to do this will be vigorously fought by a great many 
of us.

I would argue instead that if a major non-backwards compatible change is to 
be made, it should be made to the UPDATE/PRACK side of things as it is not 
yet deployed or implemented.  I would propose using a new 184 response code 
which would mean what I think you want all 18x to mean ("this status code 
has no SIP meaning, but look in the SDP for a clue").

Recall, 183 was first proposed to solve the early media problem for 
gateways.  It was subsequently (incorrectly in my opinion) co-opted in the 
manyfolks discussions.

---

From: Michael Hammer <[email-masked]>
Date: Thu, 05 Dec 2002 12:12:39 -0500

Inline.

>2) Status codes and media have to be coupled

I would contend that alerting is signaling along the line of status codes 
and not media per se.  The fact that such signals are delivered in-band is 
an artifact.  Thus, you shouldn't take a philosophical "separation of media 
and signaling" tact here.  The problem here is that you can have 0, 1, or N 
simultaneous signals distributed over both codes and embedded in 
media.  The protocol can attempt to limit this to one on the sending side, 
or prioritize on the receiving side.

The subsequent messages seem to agree on a good direction, but I can not 
yet form that into a mental case statement for each node in the backward 
signaling path.

Mike H.