[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Draft submission: draft-ietf-sip-199-00
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 RE=
CEIVE 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Pau=
l Kyzivat
Sent: 24. kes=E4kuuta 2008 15:25
To: Dale.Worley at comcast.net
Cc: sip at ietf.org
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 U=
AS. 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 ment=
ioned, 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 thi=
s 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 address=
es 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 situatio=
n 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 relia=
ble and unreliable 199, but for now we don't specify any cases when a relia=
ble 199 is sent.
=
Another thought - there aren't any issues if the *UAS* sends the 199 reli=
ably. But that isn't going to be the common case.
=
Paul
=
Dale.Worley at comcast.net wrote:
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
[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 commen=
ts
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 =
sip-implementors at cs.columbia.edu for questions on current sip Use =
sipping at ietf.org 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 sip-impleme=
ntors at cs.columbia.edu for questions on current sip Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip
ent-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Sender: sip-bounces at ietf.org
Errors-To: sip-bounces at ietf.org
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 RE=
CEIVE 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On Behalf Of Pau=
l Kyzivat
Sent: 24. kes=E4kuuta 2008 15:25
To: Dale.Worley at comcast.net
Cc: sip at ietf.org
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 U=
AS. 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 ment=
ioned, 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 thi=
s 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 address=
es 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 situatio=
n 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 relia=
ble and unreliable 199, but for now we don't specify any cases when a relia=
ble 199 is sent.
=
Another thought - there aren't any issues if the *UAS* sends the 199 reli=
ably. But that isn't going to be the common case.
=
Paul
=
Dale.Worley at comcast.net wrote:
From: "Christer Holmberg" <christer.holmberg at ericsson.com>
[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 commen=
ts
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 =
sip-implementors at cs.columbia.edu for questions on current sip Use =
sipping at ietf.org 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 sip-impleme=
ntors at cs.columbia.edu for questions on current sip Use sipping at ietf.org 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 sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip