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