[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]
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