Subject: [sipcore] Info Even Open Issue: Method types and offer/answer for Recv-Info

From: "Christer Holmberg" <[email-masked]>
Date: Thu, 29 Oct 2009 08:57:42 +0100

Hi,
 
I have got WGLC comments from different people regarding the request methods in which we allow the Recv-Info header field. 
 
It IS related to something we have discussed before, but I want to point it out, to make sure we can agree on a view.
 
1) REF and SUB
------------------------
 
There has been some comments and question about whether we should allow the R-I header field in REF and SUB.
 
Now, both REF and SUB are target refresh requests, and CAN be sent within an invite dialog usage. However, I assume the dialog-usage RFC recommends against doing so.

2) ACK and PRA
-------------------------
 
Keith suggested we shouldn't allow the header in ACK and PRA either.
 
Personally I would not like to make that restriction at this point, unless there is a good technical reason, but I would like to hear what other people think.

3) "offer/answer"
-----------------------
 
The draft currently does not define o/a type-of rules when UAs are to indicate their Info Package set (using the Recv-Info header field).
 
Personally I don't think we need to define a "o/a" rules for Recv-Info. We only need to indicate in which message the header field is allowed.
 
We could say that, when a UA receives the I-P set from the remote user, it is recommend that it sends back its own set as soon as possible - if the set has changed.
 
Because, if the set hasn't changed I don't think the UA needs to send back anything, which means that whatever set it has sent before within that dialog is still valid. That is the biggest difference compared to o/a, which always requires the receiver to send its SDP back - even if nothing has changed.

Regards,
 
Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 29 Oct 2009 11:23:23 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 29 October 2009 07:58
> To: [email-masked]
> Subject: [sipcore] Info Even Open Issue: Method types and 
> offer/answer for Recv-Info
> 
> Hi,
>  
> I have got WGLC comments from different people regarding the 
> request methods in which we allow the Recv-Info header field. 
>  
> It IS related to something we have discussed before, but I 
> want to point it out, to make sure we can agree on a view.
>  
> 1) REF and SUB
> ------------------------
>  
> There has been some comments and question about whether we 
> should allow the R-I header field in REF and SUB.
>  
> Now, both REF and SUB are target refresh requests, and CAN be 
> sent within an invite dialog usage. However, I assume the 
> dialog-usage RFC recommends against doing so.
[JRE] I don't see any need for Recv-Info in REF and SUB.

> Personally I would not like to make that restriction at this 
> point, unless there is a good technical reason, but I would 
> like to hear what other people think.
[JRE] I don't see a lot of need for Recv-Info in ACK and PRA, but I won't object if we allow it.

>  
>  
> 3) "offer/answer"
> -----------------------
>  
> The draft currently does not define o/a type-of rules when 
> UAs are to indicate their Info Package set (using the 
> Recv-Info header field).
>  
> Personally I don't think we need to define a "o/a" rules for 
> Recv-Info. We only need to indicate in which message the 
> header field is allowed.
>  
> We could say that, when a UA receives the I-P set from the 
> remote user, it is recommend that it sends back its own set 
> as soon as possible - if the set has changed.
>  
> Because, if the set hasn't changed I don't think the UA needs 
> to send back anything, which means that whatever set it has 
> sent before within that dialog is still valid. That is the 
> biggest difference compared to o/a, which always requires the 
> receiver to send its SDP back - even if nothing has changed.
[JRE] I don't think we should tie the two directions together at all. A side should only be required to send when it wants to advertise or when it wants to change a former advertisement.

John

---

From: Brett Tate <[email-masked]>
Date: Thu, 29 Oct 2009 05:02:37 -0700

Greetings,

My opinion is the same as it was when discussed at various times earlier this year; thus I'll quote a few snippets.

"There are numerous locations where I prefer new/updated Recv-Info not be used because of race condition ambiguities; these include ACK, PRACK, and PRACK 2xx.  However if the working group doesn't think such race conditions are a problem, leaving it is ok with me."

"In case it matters, ACK can't be authenticated and introduces more race conditions.

RFC 3261 did not define Supported and Allow to be optional within an ACK.  I mention it in case there were similar race condition and authentication concerns associated with using ACK to indicate/update what is supported and allowed."

Concerning REFER, SUBSCRIBE, NOTIFY, and their responses, "I'm not opposed to it being optional although it introduces more potential for race conditions."

Concerning offer/answer, I prefer not to go down that road again since I don't think that is needed.  If preference among similar packages is the issue, allow their ordering to have relevance.  If inability to use B after starting to use A is the issue, mechanisms are in place to allow Recv-Info to be updated and/or trigger 469.

http://www.ietf.org/mail-archive/web/sip/current/msg27037.html

http://www.ietf.org/mail-archive/web/sipcore/current/msg00082.html

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Thursday, October 29, 2009 3:58 AM
> To: [email-masked]
> Subject: [sipcore] Info Even Open Issue: Method types and offer/answer
> for Recv-Info
> 
> Hi,
> 
> I have got WGLC comments from different people regarding the request
> methods in which we allow the Recv-Info header field.
> 
> It IS related to something we have discussed before, but I want to
> point it out, to make sure we can agree on a view.
> 
> 1) REF and SUB
> ------------------------
> 
> Now, both REF and SUB are target refresh requests, and CAN be sent
> within an invite dialog usage. However, I assume the dialog-usage RFC
> recommends against doing so.
> 
> 
> 2) ACK and PRA
> Personally I would not like to make that restriction at this point,
> unless there is a good technical reason, but I would like to hear what
> other people think.
> 
> 
> 3) "offer/answer"
> -----------------------
> 
> The draft currently does not define o/a type-of rules when UAs are to
> indicate their Info Package set (using the Recv-Info header field).
> 
> Personally I don't think we need to define a "o/a" rules for Recv-Info.
> We only need to indicate in which message the header field is allowed.
> 
> We could say that, when a UA receives the I-P set from the remote user,
> it is recommend that it sends back its own set as soon as possible - if
> the set has changed.
> 
> Because, if the set hasn't changed I don't think the UA needs to send
> back anything, which means that whatever set it has sent before within
> that dialog is still valid. That is the biggest difference compared to
> o/a, which always requires the receiver to send its SDP back - even if
> nothing has changed.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2009 10:29:33 -0400

> It IS related to something we have discussed before, but I want to point it out, to make sure we can agree on a view.

Even when REF/SUB and INVITE are sharing a dialog, I don't see any need 
to have R-I in the REF/SUB. It would only matter if the ref/sub was 
*changing* the target to something with different properties than 
before. In that case a reINVITE can be sent to handle the R-I.

> 2) ACK and PRA

I see issues with ACK (not being authenticated) that others have 
mentioned, so it seems a bad choice. I have less trouble with PRACK, but 
can go either way.

> 3) "offer/answer"

The situation here is less complex than o/a because this is really a 
declaration rather than a negotiation.

However, as always, issues can arise from 3pcc. A UA may receive a 
reinvite, and think nothing has changed, but in reality what is changing 
is that it has a peer UA that is not aware of its R-I settings.
So I think it should be recommended that R-I always be sent in response 
to a reinvite.

Also, to cover the case where the two ends get out of sync for some 
reason, I think it should be allowed, and suggested or required, to 
include R-I in a 469 response.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 30 Oct 2009 15:10:36 +0100

Hi, 

>>Now, both REF and SUB are target refresh requests, and CAN 
>>be sent within an invite dialog usage. However, I assume the 
>Even when REF/SUB and INVITE are sharing a dialog, I don't 
>see any need to have R-I in the REF/SUB. It would only matter 
>if the ref/sub was
>*changing* the target to something with different properties 
>than before. In that case a reINVITE can be sent to handle the R-I.

So, if nobody indicates a reason why we should allow it in REF/SUB I
will keep it away.

>>Personally I would not like to make that restriction at 
>>this point, unless there is a good technical reason, but I 
>>would like to hear what other people think.
> 
>I see issues with ACK (not being authenticated) that others 
>have mentioned, so it seems a bad choice. I have less trouble 
>with PRACK, but can go either way.

If we don't allow it in ACK, how will you implement the 3pcc case below?
You would have to send an extra re-INVITE/UPDATE just because you
couldn't send the I-P list in the ACK. Or?

And, if there are no rules one can of course send a list both in the
INVITE and the ACK. I don't know if that is likely to happen, but if the
ACK trigger the remote entity's list to change it would have to trigger
a request in order to change the list, since there is no response to
ACK.

So, maybe we should say that the I-P list can only be sent in INV OR
ACK, or that the I-P list must be identical if sent in both INV AND ACK.

>>Personally I don't think we need to define a "o/a" rules 
>>for Recv-Info. We only need to indicate in which message the 
>>header field is allowed.
>>  
>>Because, if the set hasn't changed I don't think the UA 
>>needs to send back anything, which means that whatever set it 
>>has sent before within that dialog is still valid. That is 
>>the biggest difference compared to o/a, which always requires 
>>the receiver to send its SDP back - even if nothing has changed.
> 
>The situation here is less complex than o/a because this is 
>really a declaration rather than a negotiation.
> 
>However, as always, issues can arise from 3pcc. A UA may 
>receive a reinvite, and think nothing has changed, but in 
>reality what is changing is that it has a peer UA that is not 
>aware of its R-I settings.
>So I think it should be recommended that R-I always be sent 
>in response to a reinvite.

Of course, that would require that the R-I header has previously been
used during the dialog. Otherwise the UAS won't even know whether the
sender supports I-P.

At the moment my intention is to require it.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 30 Oct 2009 10:38:21 -0400

> If we don't allow it in ACK, how will you implement the 3pcc case below?

Good point. I take it back.

> a request in order to change the list, since there is no response to

But this is not a negotiation, just a declaration.
So what harm is there in changing between INVITE and ACK?
(As unlikely as that seems.)

> ACK, or that the I-P list must be identical if sent in both INV AND ACK.

I don't feel strongly about it. But every additional requirement is 
something else to test.

> used during the dialog. Otherwise the UAS won't even know whether the

Which dialog? Since this is 3pcc, and the interesting case is a 
transfer, there are *3* dialogs.

It should never hurt to send an R-I in the context of a response to a 
reinvite.

There may indeed be a problem in one case. Here's a picture to refer to:

	A ----- B ----- C
	            |
	            --- D

Initially A is connected, via B to C. Then B initiates a 3pcc transfer 
by sending a reinvite to A.

Now suppose that both A and C support I-P, but D does not. How will A 
ever learn that D does not? It won't receive an R-I header from D, and 
so will assume its unchanged from what it had from C. And when it sends 
INFOs with an I-P, D will think they are legacy. It will never send a 
469, so it won't quench the sending.

To solve that, I think the reinvite exchange must always redeclare the 
R-I in both directions.

> At the moment my intention is to require it.

OK, that's good. I didn't even see it allowed in the 469 response in 
Table 2 updates.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Sat, 31 Oct 2009 13:48:59 +0100

Hi, 

>>INVITE and the ACK. I don't know if that is likely to happen, but if 
>>the ACK trigger the remote entity's list to change it would have to 
>>trigger a request in order to change the list, since there is no 
>>response to ACK.
>

Maybe it works.

But, would it then also be allowed to send one list in a reliable 18x,
and then a new list in the next relaible 18x, and then a third list in
the 200 OK - all for the same transaction?

OR, should we have a rule saying that a UA can send at most one list per
transaction?

something else to test.
>>reinvite, and think nothing has changed, but in reality what is 
>>changing is that it has a peer UA that is not aware of its R-I 
>>settings.
>>So I think it should be recommended that R-I always be sent in 
>>response to a reinvite.
> 
reinvite.

The draft says that you don't send a list unless you know that the other
party - for that dialog - supports the mechanism.

ever learn that D does not? It won't receive an R-I header from D, and
so will assume its unchanged from what it had from C. And when 
>it sends INFOs with an I-P, D will think they are legacy. It will never
send a 469, so it won't quench the sending.

I assume B has contected D before it sends the re-INVITE to A, right?

So, if D does NOT support I-P, I guess B would have to include R-I:nil
in the re-INVITE to A.

A will of course still think that D supports I-P, but that D is not
willing to receive any I-Ps.

Table 2 updates.

It wasn't :)

Regards,

Christer