Subject: [Sip] bis-05: use of 100 Trying

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 1 Nov 2001 12:02:11 -0000

Based on the CANCEL thread that is going on, I was trying to sort out the
usage that is currently mandated for generating 100 Trying, which is
different from bis-04.

For INVITE transactions, 

-	stateless proxies never generate it (16.9). It must pass it on no
matter what request it relates to (section 16.9);

-	for all other servers: figure 7 (page 95) and the text in 17.2.1
cover this. The text says MAY generate a 100 unless... The figure implies a
MUST generate 100. 

I think a distinction should be drawn here between proxy servers and user
agent servers. I have no problem indicating that proxy servers MUST generate
100 Trying. 

For user agent servers, surely there is always a better provisional response
to send. Even if the UAS is taking time during a lookup, there is important
information to send that a UA has been reached, and therefore 183 is always
more appropriate that 100. Therefore surely it would be better to specify
UAS MAY generate 183 unless...

For non-INVITE transactions,

-	stateless proxies never generate it (16.9). It must pass it on no
matter what request it relates to (section 16.9);

-	for all other servers: figure 8 (page 105) and the text in 17.2.2
cover this. There is no text covering the generation of any provisional
response, not even 100 Trying. However figure 8 indicates that the TU may
generate 1xx responses, and that the server process will then pass them on.

Does this mean that a TU in a proxy can independently generate 1xx responses
(including 100), or is it an attempt to represent that if a proxy receives a
1xx response, it will pass it on through the TU and therefore the server
side will generate it? 

While the figures cover this for the client and server state machine, the TU
needs requirements to state that this happens in the text, and these I
cannot find. At a minimum therefore, I believe we have a hole in the
specification, but I am not sure how to fill it. Surely it would be better
to preclude 1xx responses altogether in this case, and therefore if a
stateful proxy client receives such a response it kills it. 

I am unsure whether 100 Trying should be permitted or barred in the above
case. Currently the balance of the text would imply it is precludes for
non-INVITE which would appear to me to be fine.

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 01 Nov 2001 14:33:32 +0200

Hi Keith,

>agent servers. I have no problem indicating that proxy servers MUST generate

You have my full support on that :)
 
>UAS MAY generate 183 unless...

This was discussed before, when we talked about the routing of pre-call
INFOs etc. My proposal then was that a UAS MUST send a 18x, INCLUDING
the To header tag, as soon as it receives the INVITE. There was even a
propose for a specific 18x code (184, if I remember correct) for this
purpose, so it wouldn't affect the SIP-ISUP mapping etc. Well, because
of the good old "backward compability" issue that was not acceptable... 

Maybe we should propose it again, because there sure are lots of other
things, affecting the backward compability, that has changed since then.
 
>generate 1xx responses, and that the server process will then pass them on.

I guess this depends on if we are allowed to CANCEL non-INVITEs or not,
AND/OR if we have requests which don't generate a final response quick
enough.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 19 Nov 2001 20:33:15 +0200

Hello,

inline:

> UAS MAY generate 183 unless...

Line 2703 already says that if you are going to generate another
provisional response or a final response you do not have to generate
100.

"The server transaction MUST generate a 100 response (not any status
code - the specific value of 100) unless it knows 2703
that the TU will generate a provisional or final response within 200 ms,
in which case it MAY generate a 100 2704
response. 2705"

You claim that the UAS will ALWAYS have something better to send than a
100. Well, if my UAS is a SIP to ISUP gateway the best response I can
send is 100, because I cannot send a 183 on behalf of the end user until
I receive something from the ISUP network (typically ACM, early ACM or
even CPG in ANSI networks).

Therefore, I believe the current text is perfect as it is.

A different issue is that some folks want to return a provisional
response from any gateway in order to provide Contact info to the UAC.
However, I still have not seen a single example where this might be
useful.

Regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 20 Nov 2001 08:21:32 +0200

Hi,

As Gonzalo said, it's probably not a good idea for an UAS GW to send 183
instead of 100, before it has received an ISUP message "triggering" the
183 (it would be mapped into an ISUP message in the UAC GW, and that may
cause problems later when we do receive ISUP messages on the UAS GW
side).

So, my question is: does anyone of the "gateway people" think it would
be worth adding a new response code - "184 Gateway reached"?

This code would be sent by the gateway when the INVITE is received,
instead of 100 Trying, and it would not be mapped into any ISUP message
on the UAC GW side.

This way it would be possible for the UAS GW to provide the Contact
header and To header tag at an early stage.

Also, there may be services, and other decissions (related to the bearer
and/or signalling) which are done based on if the call ends up in
another PSTN network or in the SIP network itself. The 184 response code
would inform the UAC, and intermediate SIP nodes, about this.

Comments?

Christer Holmberg
Ericsson Finland