Hi,
>I don't think the 199 can be sent unreliably if UAC require 100rel.
>As in RFC3262, It says.
>
>The UAS MUST send any non-100 provisional response reliably if the
> initial request contained a Require header field with the option tag
> 100rel. If the UAS is unwilling to do so, it MUST reject the initial
> request with a 420 (Bad Extension) and include an Unsupported header
> field containing the option tag 100rel.
This has been discussed, and the proposed outcome was to allow 199 to be sent
unreliably even if 100rel is required.
Regards,
Christer
2009/2/27, Christer Holmberg <[email protected]>:
Hi,
>If the UAC requires 100rel ,then what should the proxy do if it
receives a no-2xx final response after forking?
The proxy should send 199 unreliably.
Regards,
Christer
2009/2/27, Christer Holmberg <[email protected]>:
Hi,
>Practically, when Call forward and fork are used in the same
system, there are
>lots of early dialogs that should be eliminated by 199
existed.
>So I think that it's useful to let 199 reliable.
>And we just added fork-service to our system ,and find 199 is
really useful, and
>if the 199 is missing, problems will happen.
I'm glad you think 199 is useful :)
But, if a proxy would have to terminate PRACKs etc it would not
be a proxy anymore - it would be a B2BUA.
So, if you really want your network to send 199 reliably, I
guess you could use a B2BUA instead of a proxy.
>It sounds good that there is a way to prevent PRACK addressed
to UAS,but i don't know how to do now.
The only way to prevent it is by the proxy not sending the 199
relaible.
>ps:
>RFC3261 16.7 Response Processing
>Since a proxy may not insert a tag into the To header field of
>a 1xx response to a request that did not contain one, it
cannot
>issue non-100 provisional responses on its own.
Yes, but I we have agreed that a proxy is allowed to send 199.
But, the proxy is not going to generate new To header tag
values for the 199. It will use whatever tags that have already been created
for the early dialogs.
Regards,
Christer
*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
--------------------------------------------------------
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
