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

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Nov 2009 09:07:49 -0500

responses inline.

	Thanks,
	Paul

Christer Holmberg wrote:
> Hi, 
> 
>>> 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.
>> 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.)
> 
> 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?

What bad things happen if you do that?

The worst thing I can see is that you might get sent an I-P you don't 
want to receive. Then you just ignore it, or send a 469, and go on about 
your business.

Perhaps its more trouble on the sending side, though its hard to 
generalize. Consider the specific case of DTMF. A UA may be trying to 
decide how to set itself up to send DTMF, choosing from among the 
multitude of ways that are possible. If it gets a change - adding or 
removing a DTMF info package, then it may have to change other things as 
well, such as adding or removing telephone-events from its media types.

But, that problem exists whether or not we we allow changes in R-I 
between responses, so its not a big deal.

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

I could live with either way, but prefer not to impose arbitrary rules 
that are not strongly motivated.

>>> 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.
>> I don't feel strongly about it. But every additional requirement is
> something else to test.
>>> 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.
>>
>> 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.
> 
> The draft says that you don't send a list unless you know that the other
> party - for that dialog - supports the mechanism.

In 3pcc that can be a problem. You don't ever know if you are talking to 
the same party that you were last time.

>> 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.
> 
> I assume B has contected D before it sends the re-INVITE to A, right?

There are lots of ways to do it, depending on the goals of the case. So 
maybe yes, maybe no.

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

That means it won't work correctly unless B itself has an understanding 
of info packages. It would be better if that were not a requirement.

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

A good reason for ensuring that there is no functional difference 
between those two cases.

>>>> 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.
>>> 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.
> 
> It wasn't :)
> 
> Regards,
> 
> Christer
> 
>

---

From: Bob Penfield <[email-masked]>
Date: Mon, 2 Nov 2009 09:59:39 -0500

1) REFER and SUBSCRIBE can be sent on a dialog that has an INVITE usage, but they are associated with the subscription usage, not the INVITE usage. Therefore, Recv-Info should not be allowed on SUBSCRIBE, REFER, or NOTIFY.

2) I think being able to update Recv-Info in PRACK and ACK is useful (e.g. 3pcc for ACK).

3) Recv-Info is not an offer/answer negotiation. In fact, it is really an advertisement rather than a negotiation. The content of the Recv-Info affects what the far end can send, not what the near end (the Recv-Info sender) can send.

cheers,
(-:bob

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

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Nov 2009 21:21:17 +0100

Hi, 

>1) REFER and SUBSCRIBE can be sent on a dialog that has an INVITE
usage, but they are associated with the subscription usage, not the
INVITE usage. Therefore, Recv-Info should not be allowed on 
>SUBSCRIBE, REFER, or NOTIFY.

Yes. I have removed it for SUB, REF and NOT.

>2) I think being able to update Recv-Info in PRACK and ACK is useful
(e.g. 3pcc for ACK).

I haven't heard any real objections to that, so I think we can continue
based on that.

>3) Recv-Info is not an offer/answer negotiation. In fact, it is really
an advertisement rather than a negotiation. The content of the Recv-Info
affects what the far end can send, not what the near end 
>(the Recv-Info sender) can send.

Yes.

Regards,

Christer

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

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: "Christer Holmberg" <[email-masked]>
Date: Mon, 2 Nov 2009 21:32:05 +0100

Hi, 

>What bad things happen if you do that?

Maybe nothing. I just wanted to make sure you were ok with it :)

removing a DTMF info package, then it may have to change other things as
well, such as adding or removing telephone-events from its 
>media types.

Maybe we could recommend against updating the list more than once per
transaction, especially if the list could have impacts on other
exchanged information (SDP etc).

--------------------------

reinvite.
>> 
>>The draft says that you don't send a list unless you know that the 
>>other party - for that dialog - supports the mechanism.
>
>In 3pcc that can be a problem. You don't ever know if you are talking
to the same party that you were last time.
maybe yes, maybe no.
in the re-INVITE to A.

But, how is this different from any other extension/capability (non-SDP)
that A and C may previously have agreed upon, and D doesn't support?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Nov 2009 09:58:02 -0500

> Maybe nothing. I just wanted to make sure you were ok with it :)

Yes, I'm ok with it. It doesn't need to be forbidden just because its weird.

> exchanged information (SDP etc).

I guess I don't have a problem with recommendations.

> that A and C may previously have agreed upon, and D doesn't support?

The same issues can arise. But a 3pcc controller can try to be lenient 
in its processing of messages, only messing with things it understands, 
and relaying headers it doesn't understand. We raise the bar if we 
require the 3pcc controller to do something *active* in order to make 
things work in this case.

If we don't make it so that simply relaying the headers is enough, then 
perhaps there needs to be a whole section of B2BUA behavior, in addition 
to that for UAC and UAS.

	Thanks,
	Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 3 Nov 2009 23:19:03 +0100

Hi,

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

In that case lots of things we do would be forbidden :)

>>>want to receive. Then you just ignore it, or send a 469, and go on 
>>>about your business.

>>>removing a DTMF info package, then it may have to change other things

>>>as well, such as adding or removing telephone-events from its
>>>media types.
>>>

I rewrote section 3.2. The 2nd paragraph deals with this specific issue.

NOTE: The text does NOT yet cover the 3pcc issue discussed further down.

----

<section anchor="S.Nego.Ua" title="User Agent Behavior">
		<t>
			A UA which supports the Info Package mechanism
MUST indicate, using the Revc-Info header field, the 
			set of Info Packages for which it is willing to
receive INFO requests. A UA can list multiple Info Packages 
			in a single Recv-Info header field, and the UA
can use multiple Recv-Info header fields.
		</t>
		<t>
			The indication of Info Packages can take place
during the dialog establishment, and later as part of a target refresh. 
			A UA can only indicate a set of Info Packages
for which it is willing to receive INFO requests by using the SIP
methods 
			(and their responses) listed in <xref
target="S.Nego"/>. There are no "offer/answer" rules for Info Package
indication. 
			For example, a UA can include a set of Info
Packages in the INVITE request, and a new set in the ACK request.
Likewise,
			a UA can included a set of Info Packages in a
reliable response, and a new set in another reliable response for the
			same transaction. However, in order to avoid
race conditions, and due to the fact that UAs might indicate other 
			capablities based on the Info Package set, it is
RECOMMENDED that UAs do not not sent a list of Info Packages more than
			once per SIP transaction.
		</t>
		<t>
			If a UA is not willing to receive INFO requests
for any Info Packages, during dialog establishment or later during the
invite dialog usage, 
			the UA MUST indicate this by including a
Recv-Info header field with a 'nil' value. This informs other UAs that
the UA still
			supports the Info Package mechanism.
		</t>
		<t>
			Example: If a UA has previously indicated Info
Packages 'foo' and 'bar', and the UA during the lifetime of the invite
dialog usage wants to indicate 
			that it does not want to receive INFO requests
for any Info Packages anymore, the UA sends a target refresh request
with a Recv-Info header field 
			with a header value of 'nil'.
		</t>			
		<t>
			Once a UA has sent a list of Info Packages, the
list is valid until the UA sends a new list, or a Recv-Info header field
with a 'nil' value.
		</t>
		<t>
			Once a UA has indicated that it is willing to
receive INFO requests for a specific Info Package, and a dialog has been

			established, the UA MUST be prepared to receive
INFO request associated with that Info Package.
		</t>
		<t>
			For a specific dialog, a UA MUST NOT send an
INFO request associated with an Info Package until it has 
                 	received an indication that the remote UA is
willing to receive INFO requests for that Info Package.
		</t>
		<t>
			If a UA indicates multiple Info Packages, which
provide similar functionality, it is not possible to indicate 
			a priority order of the Info Packages, or that
that the UA wishes to only receive INFO request for one of the Info
Packages. 
			It is up to the application logic associated
with the Info Packages, and specific Info Package specifications, to
describe 
			application behavior in such cases.
		</t>
		<t>
			For backward compatibility purpose, even if a UA
indicates support of the Info Package mechanism, it is still allowed to 
			enable legacy INFO usages <xref
target="S.Leg"/>.
		</t>
		<t>
			This document does not define a SIP option tag
<xref target="RFC3261"/> for the Info Package mechanism. However, an 
			Info Package specification can define an
option-tag associated with the specific Info Package, as described 
			in  <xref target="S.Package.Tag"/>.
		</t>
		<t>
			For backward compatibility, if a UA indicates
support of the INFO method using the Allow header 
			field <xref target="RFC3261"/>, it does not
implicitly indicate support of the Info Package mechanism.
			A UA MUST use the Recv-Info header field in
order to indicate that it supports the Info Package mechanism. Likewise,

			even if a UA uses the Recv-Info header field to
indicate that it supports the Info Package mechanism, in addition 
			the UA still indicates support of the INFO
method using the Allow header.
		</t>
	</section>

----

>>>>>It should never hurt to send an R-I in the context of a response to
a reinvite.
>>>>The draft says that you don't send a list unless you know that the
other party - 
>>>>for that dialog - supports the mechanism.
>>>>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
>>>There are lots of ways to do it, depending on the goals of the case. 
>>>So maybe yes, maybe no.
>>>So, if D does NOT support I-P, I guess B would have to include 
>>>R-I:nil in the re-INVITE to A.
>>That means it won't work correctly unless B itself has an 
>>understanding of info packages. It would be better if that were not a
requirement.
>> 
>>But, how is this different from any other extension/capability 
>>(non-SDP) that A and C may previously have agreed upon, and D doesn't
support?
>The same issues can arise. But a 3pcc controller can try to be lenient
in its processing of messages, only messing 
>with things it understands, and relaying headers it doesn't understand.

Sure, but how do you know that D is going to indicate all its
capabilities (option-tags etc) in the re-INVITE response, so that A
finds out about them?

>We raise the bar if we require the 3pcc controller to do something
*active* in order to make things work in this case.

It just looks strange that we would mandate Recv-Info in re-INVITE
responses, but otherwise there are no rules.

And, wouldn't we then also need to mandate A to send his list in the
ACK? How will D otherwise know what A is willing to receive?

I am not against making sure it works for 3pcc, but to me it starts to
look more and more like offer/answer :)

Regards,

Christer

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 7 Nov 2009 15:37:12 +0100

I am fine with the text we now have on this in -03pre with the following exceptions.

For REGISTER, I guess I can live with this, but the text now specifying it is tantamount to saying using it this way is pretty useless and there are other mechanisms that should be used. Is anybody trying to defend an existing usage, or can we just take it out.

For ACK and PRACK, I'd like to understand the 3PCC issue better. Does anyone have a message flow with the use of the Recv-Info header field shown. 

What I seem to be seeing is an indication that the ACK is needed to return a Recv-Info if one gets a new indication in the 200 (OK) to a reinvite. 

But what I currently read from the text is that once I have indicated a set of Info Packages in a Recv-Info header field, I do not need to do it again unless I wish to change that set. There is no presumption that the indication from a remote user means I should send my set sagain.

Does the 3pcc discussion mean that I should now have text in the document that says if I receive a new set of Info-Package names in a Recv-Info header within a dialog, I SHOULD return a new set of Recv-Info values even if they have not changed, as the remote user may no longer be the same remote user.

Otherwise I see no justification in the document for the ACK usage (or the PRACK usage) based on the current requirement text.

regards

Keith

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: Monday, November 02, 2009 8:32 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> Subject: Re: [sipcore] Info Even Open Issue: Method types and 
> offer/answer for Recv-Info
> 
> 
> Hi, 
> 
> 18x, 
> want to receive. Then you just ignore it, or send a 469, and 
> go on about your business.
> >
> generalize. Consider the specific case of DTMF. A UA may be 
> trying to decide how to set itself up to send DTMF, choosing 
> from among the 
> removing a DTMF info package, then it may have to change 
> other things as well, such as adding or removing 
> telephone-events from its 
> >media types.
> >
> Maybe we could recommend against updating the list more than 
> once per transaction, especially if the list could have 
> impacts on other exchanged information (SDP etc).
> 
> >>>so will assume its unchanged from what it had from C. And when it 
> understanding
> But, how is this different from any other 
> extension/capability (non-SDP) that A and C may previously 
> have agreed upon, and D doesn't support?
> 
> Regards,
> 
> Christer
>