[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]

To: "Paul Kyzivat (pkyzivat)" <pkyzivat at cisco.com>, "Christer Holmberg" <christer.holmberg at ericsson.com>
Subject: Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
From: "Sanjay Sinha (sanjsinh)" <sanjsinh at cisco.com>
Date: Mon, 28 Jul 2008 10:30:26 -0400
Authentication-results: rtp-dkim-2; header.From=sanjsinh at cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; );
Cc: sip at ietf.org
Delivered-to: ietfarch-sip-web-archive at core3.amsl.com
Delivered-to: sip at core3.amsl.com
Dkim-signature: v=1; a=rsa-sha256; q=dns/txt; l=8544; t=1217255430; x=1218119430; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh at cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20<sanjsinh at cisc o.com> |Subject:=20RE=3A=20[Sip]=20New=20REFER=20request=20before= 20202=20received=20for=20previous=20[was=20RFC3515=3A=20Mult iple=20REFER=20Requests=20in=20a=20Dialog=20-Need=20clarific ation] |Sender:=20 |To:=20=22Paul=20Kyzivat=20(pkyzivat)=22=20<pkyzivat at cisco. com>,=0A=20=20=20=20=20=20=20=20=22Christer=20Holmberg=22=20 <christer.holmberg at ericsson.com>; bh=8qvjSdxk9+NUAej84281J1Tv93SPcj718McRNNhHXD8=; b=F9V8s/qqfIb2/nvo3us/h3fd3JuNdeO2zZ4c84o0HBzeNKrihk0Lk/FPmG Vd2vpcOMjkD/g2J9QTkDOm5TNkP7yl9SMvJbkH3Yv7rtVkgaKlbkk2PTGxs4 4PT48O/ygM;
In-reply-to: <488DD0D7.7070405@cisco.com>
List-help: <mailto:sip-request@ietf.org?subject=help>
List-id: Session Initiation Protocol <sip.ietf.org>
List-post: <mailto:sip@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
Sender: sip-bounces at ietf.org
Thread-index: AcjwuhSTSI9UzI9zR6WDz7Li66pdWAAA1nFw
Thread-topic: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]

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; sip at ietf.org
>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.

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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
>Behalf Of 
>>> Christer Holmberg
>>> Sent: Sunday, July 27, 2008 2:09 PM
>>> To: Paul Kyzivat (pkyzivat); Robert Sparks
>>> Cc: sip at ietf.org
>>> 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: sip-bounces at ietf.org [mailto:sip-bounces at ietf.org] On 
>Behalf Of 
>>> Paul Kyzivat
>>> Sent: 25. heinäkuuta 2008 17:32
>>> To: Robert Sparks
>>> Cc: sip at ietf.org
>>> 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 
>>>>> sip-implementors at cs.columbia.edu 
>>>>> <mailto:sip-implementors at cs.columbia.edu> for questions 
>on current 
>>>>> sip Use sipping at ietf.org <mailto: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
>>> _______________________________________________
>>> 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-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-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-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip

Follow-Ups:
- Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
  - From: Paul Kyzivat

References:
- Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
  - From: Paul Kyzivat

Prev by Date: Re: [Sip] New REFER request before 202 received for previous [wasRFC3515: Multiple REFER Requests in a Dialog -Need clarification]
Next by Date: Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
Previous by thread: Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
Next by thread: Re: [Sip] New REFER request before 202 received for previous [was RFC3515: Multiple REFER Requests in a Dialog -Need clarification]
Index(es):
- Date
- Thread