*allowing* (much less *requiring*) the 199 to be reliable introduces
nasty problems. The 199 is only an optimization, so having it be
unreliable is ok IMO.
The problem is that if a proxy sends the 199, then the recipient of the
PRACK should be the proxy. But the PRACK is an in-dialog message, so it
must be addressed to the Contact of the UAS.
If the proxy sends a reliable 199, and the PRACK is addressed to the
UAS, the UAS will be very surprised, since it has not send a reliable
provisional, and is so not expecting a PRACK. In fact, it has sent a
final response, has presumably already received the ACK, and so is
expecting nothing.
Very ugly.
Paul
[email protected] wrote:
>
> Hi,
>
> And there still two questions left.
>
> 1. Is the 199 should be reliable or unreliable?
> I think that 199 should be reliable if possible.
>
>
> First, If a client receives an unreliable 199 response on a dialog
> which has
> not previously been created (this can happen if a 199 response
> reaches the client before a 18x response) the client SHALL discard
> the 199 responses.
>
> The figure below shows an example.The 180 is sent first but arrives
> later than 199.
> If the 199 is reliable, the proxy should retransmit 199 (step 4),and
> then the retransmitted
> 199 will be accepted by UAC,and the early dialog will be teminated.
>
> UAC P
> 1. INVITE
> --------------->
> 2. 180
> <----- \/-------
> /\ 3. 199
> <-----/ \------
> 4. 199(retransmitted)
> <---------------
>
> second, According to practical use, 199 can be intended to teminate
> one early dialog and release
> resources associated with the specific early dialog, so the cost spent
> on reliable 199 is worthy.
> If the 199 cannot be sent reliable,then we should send it unreliable.
>
> 2. In your last letter, you said "the second 199 could include
> information which is to be forwarded to the
> UAC", then do you mean, the early dialog is still alive after the first
> 199 is accepted?
>
>
> Also, In my last letter, I miss a "NOT" by mistake.
> It should be
> [Eric]: Surely the UAS is NOT allowed to send another reliable response
> until the first one is acknowledged...
>
> Regards,
> Eric wang
>
>
>
>
> *"Christer Holmberg" <[email protected]>*
>
> 2009-02-27 03:04
>
>
> 收件人
> "Eric wang" <[email protected]>
> 抄送
> <[email protected]>, <[email protected]>
> 主题
> RE: Questions about "draft-ietf-sip-199-05"
>
>
>
>
>
>
>
>
> Hi,
>
> >I still have some difficult in using IETF and cannot find the whole
> sorted comments about this draft, so i have some doubt about this draft.
> >
> > 1. "If a forking proxy receives a reliably sent 199 response for a
> dialog, for which the proxy has previously generated and sent a 199
> response, the proxy MUST forward the 199 response."
> >
> > Does it describe the case below? Although P1 have sent a 199
> response, P1 havs to forword the send reliably 199 too.Or is the
> first 199 mistaked for 18x?
> >
> > UAC P1 UAS_2
> > --- INVITE ------>
> > --- INVITE (leg 2) ->
> > <-- 199(leg 2) --
> > <-- 199 (leg 2) -----
> > <-- 199(leg 2) --
>
> >I think it shall be 199, as currently written.
> >
> >[Eric]: If this is 199, then Is there a special purpose to send two
> 199 in the same dialog?
> >I think that one 199 is enough.
> >And the first 199 may be reliable too, that will make it a little
> difficult to send the second 199.
>
> The second 199 could include information which is to be forwarded to the
> UAC.
>
>
> >2. "10. Usage with 100rel
> >
> > When a 199 Early Dialog Terminated provisional response is sent by a
> UAS, since the provisional response is only used for information
> purpose, the UAS SHOULD send it unreliably even if the 100rel
> > option tag [RFC3262] is present in the Require header of the
> associated request."
> >
> >
> >I have seen a comment on this question,but still not understood about
> >it. If the INVITE has a Require tag "Require: 100rel",does the UAS
> still
> >use unreliable 199 response?
> >
> >That is the recommendation, yes. The reasons is that we want to keep
> 199
> >as "lightweight" as possible, without requireing re-transmissions and
> >PRACKs.
> >
> >[Eric]: But reliable 199 have more advantage, and It is worth to use
> the reliable 199,I think.
>
> I don't know what that advantage would be, compared to having to send
> PRACKs etc. This has been discussed quite much, so I would really need
> some good justification to change it now.
>
> Also, the draft doesn't forbid you to send the 199 reliably. It's only a
> SHOULD.
>
>
> >If 199 is reliable, there is one more advantage. If the 199 arrives
> >before the first 18x response, UAC can discard the first 199 and
> process
> >it until UAC receives the first 18x response that has the same
> >to-tag as 199, as the reliable 199 should be re-transmited until
> >received PRACK.
> >
> >If the INVITE contains "Require: 100rel", the first 18x must also be
> >sent reliably. And, I don't think the UAS is allowed to send another
> >reliable response until the first one is acknowledged, so I don't think
> >a reliable 199 would reach the UAC before the first reliable 18x.
> >
> >[Eric]: Surely the UAS is allowed to send another reliable response
> until the first one is acknowledged,
>
> If I remember correctly, the FIRST reliable response must be acknowleded
> before the next reliable response is sent. But, we can double check in
> the PRACK spec.
>
> >but reliable 199 will be useful if the first 18x is unreliable, or the
> first 18x has been acknwledged. It's another case different from the
> above one whose INVITE contains "require: 100rel".
>
> If 100rel is required the 18x cannot be unreliable.
>
> Regards,
>
> Christer
>
>
>
>
>
>
>
>
>
>
> --------------------------------------------------------
> ZTE Information Security Notice: The information contained in this mail is
> solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to others.
> This email and any files transmitted with it are confidential and intended
> solely for the use of the individual or entity to whom they are addressed. If
> you have received this email in error please notify the originator of the
> message. Any views expressed in this message are those of the individual
> sender.
> This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
