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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Nov 2001 22:26:10 -0000

Any response from the authors of the bis draft on this one yet.

Keith

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

> ----------
> From: 	Drage, Keith (Keith)[SMTP:[email-masked]]
> Sent: 	01 November 2001 12:02
> To: 	[email-masked]'
> Subject: 	[Sip] bis-05: use of 100 Trying
> 
> 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
> 

_______________________________________________
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: [email-masked]
Date: Tue, 20 Nov 2001 08:36:40 -0700

Our gateways send 100.  I still haven't heard what the usefulness is of
sending Contact and To header tag at an early stage.  We don't have an
unlimited supply of provisional response codes left and should only use them
when the need is pressing.

John Hearty
Level3

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Monday, November 19, 2001 11:22 PM
To: Gonzalo Camarillo
Cc: Drage, Keith (Keith); [email-masked]'
Subject: Re: [Sip] bis-05: use of 100 Trying

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

Gonzalo Camarillo wrote:
> 
> Hello,
> 
> inline:
> 
> "Drage, Keith (Keith)" wrote:
> >
> > cover this. The text says MAY generate a 100 unless... The figure
implies a
generate
response
important
always
> 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
> 
> >
on.
responses
> > (including 100), or is it an attempt to represent that if a proxy
receives a
> > While the figures cover this for the client and server state machine,
the TU
> --
> 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: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 20 Nov 2001 14:57:14 -0500

A Gateway can interwork with many different protocols, not just ISUP.  I
suspect that your 184 would not convey any useful information.  Better to
define new headers to indicate the true state of affairs in a 183, if
absolutely necessary.

-----Original Message-----
From: Christer Holmberg [mailto:[email-masked]]
Sent: Tuesday, November 20, 2001 1:22 AM
To: Gonzalo Camarillo
Cc: Drage, Keith (Keith); [email-masked]'
Subject: Re: [Sip] bis-05: use of 100 Trying

Hi,

Comments?

Christer Holmberg
Ericsson Finland

implies a
generate
response
important
always
on.
responses
receives a
the TU