Subject: RE: [Sip] bis draft: Headers in 100 Trying (was "Minor NIT on Sup ported header")

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Fri, 5 Oct 2001 16:12:08 +0100

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

> ----------
> From: 	Jonathan Lennox[SMTP:[email-masked]]
> Sent: 	28 September 2001 19:47
> To: 	Drage, Keith (Keith)
> Cc: 	[email-masked]'
> Subject: 	Re: [Sip] bis draft: Minor NIT on Supported header
> 
> On Friday, September 28 2001, "Drage, Keith (Keith)" wrote to
> "[email-masked]'" saying:
> 
> > Does anybody see any purpose for any headers other than From; To;
> Call-ID;
> > CSeq; Via; and Content-Length within a 100 Trying response.
> 
> In addition to the two Vijay mentioned (Server and Timestamp), I don't see
> anything wrong with including Date.  Some servers, including ours, insert
> it
> in every message generated.  (In a 100 it's probably roughly as useful as
> Server, i.e. it's good for debugging and for diagnosing various abnormal
> situations.)
> 
See previous mail concerning why I think Server and Timestamp are not
applicable. Having reread the bis draft concerning Date, I can see that this
is applicable.

> Bis says that Record-Route headers MAY be present in a provisional
> response,
> and doesn't separate out 100 Trying from other 1xx responses.  I can
> imagine scenarios where Record-Route in a 100 could be useful, but I'm not
> sure how plausible they are.  
> 
Yes, I can see that the current rules allow a proxy to respond. This would
only appear to have any impact on the call from a 1st proxy back to a UAC,
as it is only the UAC that sent the request in the first place that can use
the accumulated Record-Route information. Now I am stuck to see how useful
that usage is.

Currently I have a view that 100 Trying need only contain the mandatory
headers, plus optionally Date, and I am considering that it would be a
simplification of the bis draft to limit it just to that, and separate it
out from all the other 1xx responses. Therefore my inclination would be to
exclude Record-Route as getting closer to my general treatment of this
status-code.

> -- 
> Jonathan Lennox
> [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