Subject: RE: [Sip] REFER issues

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

inline

> -----Original Message-----
> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, November 26, 2001 12:49 PM
> To: [email-masked]
> Subject: [Sip] REFER issues
> 
> 
> 
> 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? 

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.

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

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

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

Lets NOT go there. As much as it tries to act like it, REFER really
doesn't need to be the SIP Remote-Control method. 

The 3xx question you're asking here is similar to the 401/407 question.
It's B's responsibility to provide the credentials necessary to get
through the network to C, and it may take a round or two of challenges
to get that done.

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

_______________________________________________
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:15:17 +0200

Hi,

>the ACK, so from A and B's perspective this looks just like the

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)?

>>may receive multiple 2xx final responses, in which case multiple NOTIFYs will be

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.

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

>>3xx, so that A can issue a new REFER to tell B to contact the address received in the 3xx?
> 

Yes.

Regards,

Christer Holmberg
Ericsson Finland

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 26 Nov 2001 15:46:04 -0500

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