Christer Holmberg wrote:
Hi,
If the proxy assignes its own To-tag, we can't use the To-tag to indciate which
dialog was terminated.
Right. That was part of my point. In addition, the to-tag it does use
creates *another* early dialog.
And then, suppose we did allow the proxy to reuse the existing dialog
for the 199, with a new contact. Then the UAC, upon receipt of the 199,
will have to send the PRACK within the dialog. So the dialog can't be
immediately destroyed. When *does* it get destroyed??? When the 200 to
the PRACK is received?
The extra state management and time required to handle this seems to run
contrary to the goal of the 199.
One option, as proposed by Paul, is to say that a UAC shall be able to RECEIVE
reliable 199 responses.
Based on my comments above, I am reconsidering the advisability of that.
One ugly solution would be to retransmit the UNRELIABLE 199 a few times - we
already use that type of mechanism in ICE, so... ;)
Yes, that *is* ugly!
Paul
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Kyzivat
Sent: 24. kesäkuuta 2008 15:25
To: [EMAIL PROTECTED]
Cc: [email protected]
Subject: Re: [Sip] Draft submission: draft-ietf-sip-199-00
There is a very messy slippery slope here with the reliable 199.
I believe we have agreed that the 199 is to have the to-tag used by the UAS. So
conceptually it is *from* the UAS. If you want the proxy to send the 199
reliably, then it will have to field the response. As others have mentioned,
this seems to mean that it will have to use its own contact address, which will
be a change from the contact used previously by the UAS for this early dialog.
That gives me heartburn - it just seems wrong. Ignoring that, it puts the 199
into the middle of the open question about changing of contact addresses and
how they take effect.
This could be addressed by always sending the 199 with a To-tag assigned by the
proxy. But that has its own problems. It actually makes the situation worse for
UACs that don't support 199.
We sidestep all these problems by not sending the 199 reliably.
Maybe we we should say that the UAC must be prepared to handle both reliable
and unreliable 199, but for now we don't specify any cases when a reliable 199
is sent.
Another thought - there aren't any issues if the *UAS* sends the 199 reliably.
But that isn't going to be the common case.
Paul
[EMAIL PROTECTED] wrote:
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
