Subject: [Sip] RFC 3515: Multiple REFER Requests in a Dialog - Need clarification

From: "Vavilapalli Srikanth-A19563" <[email-masked]>
Date: Fri, 25 Jul 2008 14:06:32 +0800

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-December/0
05829.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-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Fri, 25 Jul 2008 14:51:48 +0800

Hi
 
To solve this problem we could use the mechanism defined in RFC 4488 -
Suppression of SIP Refer method Implicit subscription. 
 
So here when the UAC i.e the REFER Issuer is sending the 2nd REFER
request, it can follow the procedures defined in above RFC so that the
REFER recipient does not create another implicit subscription for the
REFER request.
 
But here too it is not clear how the REFER issuer would know if the
REFER recipient supports RFC 4488 or not - unless REFER recipient
inserts the mentioned option-tags in the response to first REFER request
-- because if it does not, then implicit subscription is anyway created
for 2nd REFER request too as per RFC 3515.

Regards 
Ranjit 

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Vavilapalli Srikanth-A19563
Sent: Friday, July 25, 2008 11:37 AM
To: [email-masked]
Subject: [Sip] RFC 3515: Multiple REFER Requests in a Dialog -
Needclarification

Hi

 
Please clarify me.
 
Regards
Srikanth

---

From: Robert Sparks <[email-masked]>
Date: Fri, 25 Jul 2008 09:09:14 -0500

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-December/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
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Jul 2008 10:32:08 -0400

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:
> 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).
> 
> 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
> 
>> 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
>>  
>> Use [email-masked] 
>> <mailto:[email-masked]> for questions on current sip
>> Use [email-masked] <mailto:[email-masked]> for new developments on 
>> the application of sip
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Christer Holmberg" <[email-masked]>
Date: Sun, 27 Jul 2008 20:08:47 +0200

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-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 25. heinäkuuta 2008 17:32
To: Robert Sparks
Cc: [email-masked]
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:
>> This list is for NEW development of the core SIP Protocol Use 
>> [email-masked] 
>> <mailto:[email-masked]> for questions on current 
>> sip Use [email-masked] <mailto:[email-masked]> for new 
>> developments on the application of sip
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip Use 
> [email-masked] for new developments on the application of sip
This list is for NEW development of the core SIP Protocol Use [email-masked] for questions on current sip Use [email-masked] for new developments on the application of sip

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Sun, 27 Jul 2008 16:09:22 -0400

RFC 3261 says that overlapping non-Invite transactions are allowed and REFER RFC is silent on it, but imo, the UAC should be discouraged from doing so. Overlapping transactions are application dependent and there is no one rule which applies to all usage.
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.

Sanjay

>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Christer Holmberg
>Sent: Sunday, July 27, 2008 2:09 PM
>To: Paul Kyzivat (pkyzivat); Robert Sparks
>Cc: [email-masked]
>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
>
>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
>
>
>
> 
>
>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:
>[email-masked] for questions on current sip 
>Use [email-masked] for new developments on the application 
>of sip _______________________________________________
>[email-masked] for questions on current sip

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 28 Jul 2008 08:04:42 +0200

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

>Christer Holmberg
>Subject: [Sip] New REFER request before 202 received for previous [was 
>RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
>
>
>Hi,
>
>Behalf Of Paul Kyzivat

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2008 09:59:51 -0400

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?

	Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 28 Jul 2008 10:06:16 -0400

Pl. see inline ..

>Sent: Monday, July 28, 2008 2:05 AM
>To: Sanjay Sinha (sanjsinh); Paul Kyzivat (pkyzivat); Robert Sparks
>Cc: [email-masked]
>Subject: Re: [Sip] New REFER request before 202 received for 
>previous [wasRFC3515: Multiple REFER Requests in a Dialog 
>-Need clarification]
>
>
>Hi, 
>
>>RFC 3261 says that overlapping non-Invite transactions are 
>allowed and 
>>REFER RFC is silent on it,
>

Yes, I think it should be. I believe it should be left upon the application in which transacations are used to figure out overlapping transactions are good for it or not. Clearly for target refresh it is not a good idea.

>
>>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.

That right. 

Sanjay

>>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).
>>
>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
>>
>>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
>>
>>
>>
>> 
>>
>>Paul Kyzivat
>>Subject: Re: [Sip] RFC 3515: Multiple REFER Requests in a 
>Dialog -Need 
>>clarification
>>
>>What Robert said.
>>
>first refer 
>>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.
>>

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 28 Jul 2008 10:30:26 -0400

Pl. see inline .. 

>From: Paul Kyzivat (pkyzivat) 
>Sent: Monday, July 28, 2008 10:00 AM
>To: Christer Holmberg
>Cc: Sanjay Sinha (sanjsinh); Robert Sparks; [email-masked]
>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.

Sanjay

>>> 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.
>> 
>>> 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
>perspective, 
>Behalf Of 
>>> 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
>>> 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:
>---------------------------------------------------------------------
>>> -
>>>> --
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2008 10:43:10 -0400

> 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 ta…

That doesn't solve the problem. Even if you add that restriction, there 
are issues with:
- non-target-refresh requests that might be sent
- *previously sent* requests that don't get replies and need to be 
retransmitted
- retransmission of responses to earlier requests when a retransmission 
of the request is received.

So these issues either need to be clarified, or will remain ambiguous.

	Paul

---

From: "Sanjay Sinha (sanjsinh)" <[email-masked]>
Date: Mon, 28 Jul 2008 19:36:39 -0400

Pl. see inline ..

>Sent: Monday, July 28, 2008 10:43 AM
>To: Sanjay Sinha (sanjsinh)
>Cc: Christer Holmberg; Robert Sparks; [email-masked]
>>> Subject: Re: [Sip] New REFER request before 202 received 
>for previous 
>>> [was RFC3515: Multiple REFER Requests in a Dialog -Need 
>>> clarification]
>>>
>>> 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.
>>>
>>> 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:
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

>>>>> RFC 3261 says that overlapping non-Invite transactions 
>are allowed 
>>>>> and REFER RFC is silent on it,
>>> 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.
>>> guess the intention is that it should be used for future requests - 
>>> including the second REFER.
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2008 20:07:36 -0400

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