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
