Sanjay,
So I gather you are suggesting that after sending a target refresh
request, the UA should refrain from sending anything else until a
response is received. This is in spite of the fact that there is in
general no reason to believe that the response will change the target.
(While it *might*, this would in general be a race condition. It it was
going to change its address it would be sending its own target refresh
unless you catch it at *just* the right time.)
Probably the most likely scenario for this kind of problem is with
NOTIFY. There are potentially lots of cases where it might want to send
another NOTIFY quickly after a first one. I'm very reluctant to say that
it MUST not.
In general I think we can say you SHOULD NOT send a 2nd request of any
sort while another is outstanding, because request reordering can cause
one to fail due to CSeq ordering problems. The potential target refresh
issues are another justification for this, but probably not worse.
What I think is lacking is any normative statement of what a UA that has
just offered a change to its address is to do regarding requests
arriving on the old one.
Paul
Sanjay Sinha (sanjsinh) wrote:
Pl. see inline ..
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, July 28, 2008 10:43 AM
To: Sanjay Sinha (sanjsinh)
Cc: Christer Holmberg; Robert Sparks; [email protected]
Subject: Re: [Sip] New REFER request before 202 received for
previous [was RFC3515: Multiple REFER Requests in a Dialog
-Need clarification]
Sanjay Sinha (sanjsinh) wrote:
Pl. see inline ..
-----Original Message-----
From: Paul Kyzivat (pkyzivat)
Sent: Monday, July 28, 2008 10:00 AM
To: Christer Holmberg
Cc: Sanjay Sinha (sanjsinh); Robert Sparks; [email protected]
Subject: Re: [Sip] New REFER request before 202 received
for previous
[was RFC3515: Multiple REFER Requests in a Dialog -Need
clarification]
The whole issue of target refresh seems filled with potential race
conditions and ambiguities. The second REFER before the first is
complete presents no new issues compared to a second
SUBSCRIBE before
a first is complete, and that is a much more likely case,
especially
with differing event packages.
The semantics of target refresh have always troubled me.
Presumably there must be some period of time during which both the
old and new addresses are valid. But when does that period end? And
what if you are making the change because the old address stopped
working already?
I think having such a mechanism will add to the confusion
and for the reasons you mentioned above, will be difficult to
implement. I think a better approach will be to forbid sending
overlapping target refresh request until the previous one is
complete, as per the rules in RFC 5057.
That doesn't solve the problem. Even if you add that
restriction, there are issues with:
- non-target-refresh requests that might be sent
I believe those should be restricted as well. If a target refresh request has
been sent which is pending and the successful response to it will indicate what
the current remote target is, then an application is better off waiting the
outcome of that request.
- *previously sent* requests that don't get replies and need
to be retransmitted
Use current remote target, but there may be race conditions. I am inclined to
say that UA should not initiate another transaction (target refresh or
otherwise) if another is pending.
- retransmission of responses to earlier requests when a
retransmission of the request is received.
That will be a transaction layer thing, right, which will just retransmit the
last response.
Sanjay
So these issues either need to be clarified, or will remain ambiguous.
Paul
Sanjay
Paul
Christer Holmberg wrote:
Hi,
RFC 3261 says that overlapping non-Invite transactions
are allowed
and REFER RFC is silent on it,
Yes, but I wonder whether there are more strict rules for
target refresh requests.
Having said that, I am not sure if call flow below is a problem.
Since UAS will not update the remote target until it has
sent a final
response and UAC should not assume that the remote target
is updated until it has received that final response. So even if
second Refer contains an updated remote target, it will update the
previous one.
Yes, but if the first 202 contains a new remote target, I
guess the intention is that it should be used for future requests -
including the second REFER.
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Christer Holmberg
Sent: Sunday, July 27, 2008 2:09 PM
To: Paul Kyzivat (pkyzivat); Robert Sparks
Cc: [email protected]
Subject: [Sip] New REFER request before 202 received for previous
[was
RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
Hi,
I have received a question related to this, so I assume there ARE
use-cases where multiple REFERs are sent within a single dialog
(sorry, I don't have any detailed information about the use-case
available).
The question is: since REFER is a target refresh request, is it
allowed to send a new REFER request (within the same
dialog) before you have received the 202 response to the previous
REFER?
Call-flow:
UAC UAS
--------- REFER (1) -------->
--------- REFER (2) -------->
<-------- 202 (1) -----------
<-------- 202 (2) -----------
I don't know whether there is a problem from a transfer
perspective,
but as far as I understand it is now allowed to issue a
new target
refresh request one there is one pending.
Regards,
Christer
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of
Paul Kyzivat
Sent: 25. heinäkuuta 2008 17:32
To: Robert Sparks
Cc: [email protected]
Subject: Re: [Sip] RFC 3515: Multiple REFER Requests in a Dialog
-Need clarification
What Robert said.
Perhaps it is possible that the operation requested by the first
refer fails, and is notified, but does not *immediately*
terminate
the subscription. (Not that I can think of a reason
why.) Then the requester might try another refer and get a second
subscription before the first goes away.
In the usual way of things, you should probably try to
avoid creating
such a situation, unless you have some as yet unknown
good reason.
But if you are on the receiving side you should do the
right thing if
it happens to you.
Paul
Robert Sparks wrote:
You are not likely to run into this for transfer.
I'm not aware of any applications that will exercise
this use case
today, but I expect someone eventually will come up with
something (it
might look like referring a UA to multiple MSRP
connections or some
other conference-like mesh, or somebody may eventually
try to use
REFER to ask the UA to look at several things over HTTP at once).
The id= parameter on the Event header in the notify is there
to allow
you to tell the subscriptions apart (so you can manage
those usages
independently). The element accepting the REFERs is
required to send
it in the NOTIFYs of the second and subsequent
subscriptions. Again,
I haven't seen attempts to use this capability in
applications yet -
it would not surprise me if there's something there that
turns out to
be really hard (like figuring out which of those
subscriptions goes
with which REFER).
RjS
On Jul 25, 2008, at 1:06 AM, Vavilapalli Srikanth-A19563 wrote:
Hi
I have seen some discussion happened on this topic in the
following
mail trail, but still not clear with one thing:
https://lists.cs.columbia.edu/pipermail/sip-implementors/2003-Decembe
r/005829.html
Is there any use case where we receive second REFER
message that
creates a subscription while there exists an already an 'active'
REFER subscription in the same dialog? RFC 3515 has given a
use case
by saying that "If more than one REFER is issued in the
same dialog
(a second attempt at transferring a call for example)".
But in the
above scenario, I assume that the first attempt to call
transfer has
failed (i.e. first REFER subscription terminated).
Please clarify me.
Regards
Srikanth
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol Use
[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]> for questions
on current
sip Use [EMAIL PROTECTED] <mailto:[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
_______________________________________________
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
