Subject: [Sip] REFER issues

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Nov 2001 20:48:37 +0200

Hi,

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? 

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?

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?

Also, IF the 3xx final response is sent in the NOTIFY, should it be a
MUST to also include the Contact header(s) received in the 3xx, so that
A can issue
a new REFER to tell B to contact the address received in the 3xx?

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Mon, 26 Nov 2001 16:39:12 -0500

inline

> -----Original Message-----
> From: Bob Penfield [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 2:46 PM
> To: Robert Sparks; 'Christer Holmberg'; [email-masked]
> Subject: Re: [Sip] REFER issues
> 
> 
> > > Q2.
> > >
> > 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.
> >
> I made the same interpretation when reviewing the draft. In 
> section 3.9, you
> say "Using message/sipfrag bodies to return the progress and 
> results of a
> REFER request is extremely powerful". I interpret "progress" 
> to mean that
> the recipient MAY send multiple NOTIFYs with things like provisional
> responses. If this is not true, the draft should explicitly 
> state that there
> should only by one NOTIFY per REFER.

Yes, a recipient MAY send multiple NOTIFYs reflecting provisional
responses (there's been much discussion on the list in the past
as to just how useful this may or may not be).

The situation Christer brought up concerned multiple FINAL responses.
The point to take away is that the draft only requires (and that only
at SHOULD strength) one (1) NOTIFY representing success or failure.
It allows multiple NOTIFYs, so sending progress via provisionals is ok.

It would even allow multiple NOTIFYs containing potentially different
final responses, which is probably not a bad thing given that REFER is
supposed to be a general purpose tool. Each use should talk about what
multiple final response NOTIFYs might mean. For transfer, we only get
one failure final response, usually one success final response, and
at the edge multiple success final responses to the INVITE. Its pretty
clear what to do with the NOTIFY in the case of the failure final
response. Its also pretty clear what to do with the NOTIFY if there
is only one success final response. The question is do we need to put
requirements on the use of REFER in transfers wrt notification of
multiple
successes? I'm strongly inclined to say no. Nothing prevents them from
being sent, nothing breaks if they are sent - does anything break if
they
aren't? I don't think so.

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 27 Nov 2001 13:56:30 -0500

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 1:49 PM
> To: [email-masked]
> Subject: [Sip] REFER issues
> 
> 
> 
> Hi,
> 

Just to clarify, subsequent list discussion seems to have converged on
sending a BYE in this case rather than a re-INVITE, to simplify things and
to unify the treatment with the initial INVITE, where a BYE is sent. I don't
think that alters the subsequent comments on treatment of this case, but I
want to make sure people are aware of that.

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com