Subject: Re: SIP Provisional Responses

From: "Scott Petrack"<[email-masked]>
Date: Fri, 22 May 1998 16:51:00 +0200

From: Scott Petrack@VOCALTEC on 05/22/98 04:51 PM

[... Problem that a user agent server might need to send first a 100 Trying
response and then a 180 Ringing response...]

>
>2) The server can retransmit 1xx responses periodically.
>
>For non-technical users, the difference between Trying and Ringing isn't
>all that great - certainly not something that the standard telephone
>tones (ring-back in either case) could express.

If the server first responds "100 Trying" then if later it sends "180
Ringing" this is not a _retransmit_, is it? It is a change in the
provisional response. If this is to be allowed it needs to be explicitly
stated. I thought that a retransmitted response must an exact retransmit of
the original response.

When client retransmits the INVITE the server can't give a different
response.

I think that allowing the server to "retransmit" a changed provisional
response would be very useful, but some clear rules need to be written. For
example, I wouldn't want a "Ringing" to change into a "Trying".

Perhaps we can say that the higher the number of the provisional response
code, the farther along the server has gone. (i.e. "180 Ringing" is further
along the resolution process than "100 Trying"). And then the standard can
allow a lower provisional response to be replaced by a higher one. (Of
course we will have to dole out the numbers for responses quite carefully,
but this is not too hard).

BTW, "for non-technical users", my cellphone first emits little clicks when
it is trying to find the callee, and then these clicks change into ringback
to signal that the phone is ringing. (We do this in the VocalTec PSTN
gateway as well). And in fact there are lousy cell phone services that
actually start by faking Ring back and then turn into Busy tone if the
callee is actually busy. I find the former is very useful, and the latter
extremely annoying.

Scott

[email-masked] on 05/20/98 02:20:06 AM

To:   [email-masked]
cc:   [email-masked], [email-masked] (bcc: Scott Petrack)
Subject:  Re: SIP Provisional Responses

Eric Tremblay wrote:
>
> How can the user agent server make sure that the client received the
> "new" (180) status code?  If the server just sends one 180 response, it
> can easily get lost, and the next 180 response that will be sent will be
> in response of a retransmission, which is around 30 seconds later.
>
> Should the server send more than one "new" status code?  I think so, but
> how?  I think the 180 response is important for rendering call
> progress...
>
> I understand that even if the UAC does not receives any 180 responses,
> the call can be established, but I personnaly don't like the UAC seeing
> simply a transition from 100 to 200.
>
Unfortunately, the alternative of acknowledging 1xx responses would
greatly complicate the state machinery.
Currently, either client or server can, if they so desire and are
willing to suffer the network traffic and server load consequences, get
semi-reliable status updates:
1) The client can retransmit INVITE more frequently. This is against the
rules, but otherwise causes no interoperability problems.
2) The server can retransmit 1xx responses periodically.
For non-technical users, the difference between Trying and Ringing isn't
all that great - certainly not something that the standard telephone
tones (ring-back in either case) could express.

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 04 Jun 1998 10:07:09 -0400

> stated. I thought that a retransmitted response must an exact retransmit of

There can be several 1xx responses, either the same ("retransmit") or
different. This is the same as in HTTP.

> When client retransmits the INVITE the server can't give a different

Yes, it can: If I send an INVITE, the phone rings, but the 100/180 gets
lost. [The callee can't know that the 1xx got lost.] The caller
retransmits just as the callee picks up. Naturally, the server returns a
200, not a 1xx response at that point.

> example, I wouldn't want a "Ringing" to change into a "Trying".

The state diagram always allowed this: see the transition "status
change/1xx". However, guaranteeing some ordering is very difficult (and,
I believe, counterproductive) since they may be generated by different
pieces of equipment along the way. The client should simply report the
progress, with the expectation that in almost all circumstances the
sequence will make sense to the user, but without relying on a strict
ordering 100-180-182 or similar. (As a practical matter, enforcing
monotonicity would make assignment of codes rather difficult.)

> callee is actually busy. I find the former is very useful, and the latter

Unfortunately, this is to some extent unavoidable if you have a device
on one side that has a very limited repertoire of user feedback (fast
busy, ringback and busy). How else would you handle the situation that
the callee gets the call (ringback) and then decides to refuse the call?
You'd probably want a voice announcement (assuming it's in a language
you understand - I rather have a busy tone than a message in Portugese),
but this behavior doesn't exist on the SS7 side.

Henning