Subject: RE: [Sip] REFER issues

From: Robert Sparks <[email-masked]>
Date: Mon, 26 Nov 2001 15:26:09 -0500

> > > I have some questions/clarifications on REFER.
> > >
> > > Q1.
> > >
> > > Consider the following scenario:
> > >
> > > A          B          C
> > > -----------------------
> > >
> > > --REFER---->
> > > <-202-------
> > >            ---INVITE-->
> > >            <--200------
> > >
> >>Now, bis-05 says that if a C doesn't receive an ACK it should send a
> >>re-INVITE to B, including the same SDP it included in the 200 OK. If
> >>this happens, what response code does B insert in the 
> NOTIFY to A? 200
> >>OK?
> >In that scenario, B issues the NOTIFY and will probably do so long
> >before C gives up waiting for an ACK (maybe even before it _sends_
> >the ACK, so from A and B's perspective this looks just like the
> >success case.
> 
> In this case I guess the B should NOT accept the re-INVITE, 
> since it has
> already sent a NOTIFY with an error code (some 4xx, I guess)?

You've got a scenario in your head that's different from
what you put in the message. In the one you describe, B
got a 200 OK. At that point it can (most implementations would)
send a NOTIFY with a 200 OK. The transport (and possible failure) 
of the ACK happens after that. 

> 
> >>Q2.
> >>
> >>If the INVITE "triggered" by the REFER gets forked, the UAC
> >>may receive multiple 2xx final responses, in which case 
> multiple NOTIFYs will be
> >>sent to the client who issued the REFER. The draft does say "each
> >>NOTIFY", but maybe this scenario should be mentioned a little more?
> >You've made quite a leap here - the REFER draft makes no requirement
> >for such multiple NOTIFYs. The "each NOTIFY" string 
> corresponds to having
> >multiple REFER statements in a dialog - a completely 
> different context.
> > 
> >Now, the effect of multiple 2xxs to an INVITE on what the referred
> >party generates is a policy decision the referred party must make.
> >If they have a minimal implementation, they'll send a NOTIFY upon
> >receiving the first 200 OK and toss the implied subscription state.
> >Other implementations might do as you suggest and generate subsequent
> >notifications (meaning "I succeeded again"?) but they would most
> >likely get 481ed.
> 
> I do agree that this should be a decission made by the referred party,
> and it should not be a requirement in the draft how to handle it. 
> 
> However, since forking IS a part of SIP, I think it would be 
> a good idea
> to mention forking scenarios in the draft.

OK

> 
> >>Q3.
> >>
> >>Consider the following scenario:
> >>
> >> A          B          C
> >> -----------------------
> >>
> >> --REFER---->
> >> <-202-------
> >>            ---INVITE-->
> >>            <--3xx------
> >>
> >>If a 3xx final response is received for the INVITE I guess B
> >>MAY forward that response code in a NOTIFY. IF that 
> happens, however,
> >>can A ASSUME that B did NOT issue a new INVITE?
> > 
> >This would be a really odd thing for B to do. B is more likely to
> >either automatically recurse or prompt B's user for instructions
> >on how to proceed. A NOTIFY would not be generated until the
> >subsequent request(s) were sent and some knowledge of success or
> >failure is available (or if B decided it didn't know how to recurse
> >or was unwilling to do so, in which case it would return with
> >a 503 or 603).
> > 
> >If B did return a NOTIFY containing a 3xx start-line, A would assume
> >the referred action failed and take whatever its fail path is.
> 
> I agree. Again, do you think this is this something that should me
> mentioned in the draft?

I think its already there, but I'll reread with this perspective
in mind and look for places to improve clarity.

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Nov 2001 22:33:53 +0200

Hi,

>of the ACK happens after that.

It's the same scenario, but I assumed that the NOTIFY with the 200 won't
be sent until the call actually is established. However, the referred
party doesn't know if the ACK reaches C or not, so I guess it WILL (as
you said) send the NOTIFY as soon as it gets the 200...

Thanks!

Christer Holmberg
Ericsson Finland