Subject: RE: SIP Provisional Responses

From: Eric Tremblay <[email-masked]>
Date: Tue, 19 May 1998 18:05:53 -0400

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.

EricT

Eric Tremblay       | Mediatrix Telecom
Ingénieur Stagiaire | -----------------
email: [email-masked]
Tel: +1(819)829-8749 ext. 238
Web: www.mediatrix.com

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: 19 mai, 1998 17:22
> To: Eric Tremblay
> Cc: [email-masked]
> Subject: Re: SIP Provisional Responses
> 
> 
> Eric Tremblay wrote:
> > 
> > I think I just found small problem:
> > 
> > A SIP User Agent client (UAC)invites a remote user agent 
> server (UAS).
> > The server's response to this request is Trying (100) and 
> it then take
> > whatever action needed to see if the user is on the system. 
>  The server
> > finds the user on the local system and alerts him.  The 
> server now could
> > send 180 (Ringing) responses to the UAC, but how?  According to the
> > latest draft, the server has to wait for a retransmission by the UAC
> > (which is once every 30 seconds) before sending again a response.  I
> > think a remote UAC cannot wait such a delay before knowing that the
> > remote party is ringing.  How can the UAC be notified in time?
> 
> The user agent server *retransmits* its current response upon 
> receiving
> a retransmission of the request, but it can send a response 
> at any time.
> Thus, you would send the 180 whenever you want, and the 200 
> (if the call
> is accepted) as soon as the user accepts - no need to wait 
> for a request
> retransmission. 
> 
> -Jonathan R.
> 
> -- 
> Jonathan D. Rosenberg                       Lucent Technologies
> Member of Technical Staff                   101 Crawfords Corner Rd.
> High Speed Networks Research                Holmdel, NJ 07733
> FAX:   (732) 834-5379                       Rm. 4C-526
> EMAIL: [email-masked]
> URL: http://www.cs.columbia.edu/~jdrosen
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 19 May 1998 19:03:48 -0400

> in response of a retransmission, which is around 30 seconds later.

The 1xx responses are not reliable.

> simply a transition from 100 to 200.

Why? 

You should note that the 100 provisional response is not always sent
(only if a server anticipates not being able to answer right away); a
caller can send a request and see a 200 response immediately without
ever receiving a 100, let alone 180.

-Jonathan R.

---

From: Henning Schulzrinne <[email-masked]>
Date: Tue, 19 May 1998 20:20:06 -0400

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