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
