Christer,
My point was to formalize the moment a 199 is sent by relating it to the
RFC3261 ICT state machine (BTW we're all silently assuming non-INVITE
requests don't use provisional responses here)
So associated with PROCEEDING-->COMPLETED, but indeed only if a to-tag
was received before (so not only 100)
Regards,
Jeroen
PS perhaps an idea to explicitly disallow 199 for non-INVITE requests?
Rockson Li (zhengyli) wrote:
Yes, it's a typo, 100 does not establish early-dialog.
-Rockson
-----Original Message-----
From: Christer Holmberg [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 24, 2008 6:32 PM
To: Rockson Li (zhengyli); Jeroen van Bemmel
Cc: [email protected]
Subject: RE: [Sip] Draft submission: draft-ietf-sip-199-00
Hi,
Should the 199 response contain a Contact header? And if yes, in case
a proxy sends it, should it contain the address of that proxy (since the UAS already sent a final response)?
IF the 199 is sent reliably be the proxy must contain a Contact header
containing the address of the proxy, yes.
Should we say that a proxy may only generate and send a 199 when it
receives a final error response on an INVITE client Transaction which
was in the PROCEEDING state? (i.e. 1xx response was received before,
so conceptually sending the 199 response is an action associated with
the transition from PROCEEDING to COMPLETED)
I am not sure I understand. The idea IS to send 199 when a final error
response is received by the forking proxy, if a 18x has previously been received.
[Rockson] PROCEEDING does not mean early-dialog is established, 100
Trying also move INVITE client Transaction to PROCEEDING state.
[Christer] 199 is only sent when an early dialog has been established. 100
Trying does not establish an early dialog.
Regards,
Christer
Also, a forking proxy with multiple INVITE client Transaction may
receive/forward 180 from one of them, and receive no provisional resp and final
resp directly from the other one, so INVITE client Transaction's state is not
dependable. The decision making must be done in TU.
Christer Holmberg wrote:
Hi,
I agree it may be a good idea to not forbid sending it reliably.
I do think it would be good to have text, saying that it can be sent unreliable
even if reliable responses are required, though, so that proxies aren't forced
to terminate PRACKs etc.
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: 21. kesäkuuta 2008 1:38
To: [email protected]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
From: "Christer Holmberg" <[EMAIL PROTECTED]>
[CHH] Whether the text should be in the document at all depends on if we
allow 199 to be sent reliably in the first place. Based on the comments
received so far we should not mandate 199 to be sent reliably, even if
100rel is required by the UAC. But, the question if whether we want to
FORBID sending it reliably.
If we ever might allow 199 to be used for HERFP, we should admit the
possibility of sending it reliably in the first draft. Otherwise, we'll be
locked out of sending it reliably in the future.
Dale
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED] for questions on current sip Use
[EMAIL PROTECTED] for new developments on the application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED]
for questions on current sip Use [EMAIL PROTECTED] for new developments on the
application of sip
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
