Subject: [Sip] draft-ietf-sip-info-events-00: package negotiation

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Oct 2008 10:51:23 -0400

General issues with the negotiation mechanism:

What happens if the initial INVITE by a UAC includes only Send-Info or 
Recv-Info? Does that indicate a "half-legacy" device??? Or does it delay 
negotiation for one but not the other? Or does the presence of one mean 
the absence of the other is equivalent to an empty one?

As I think about it, I don't think its really necessary to treat the 
absence of these headers as meaning "legacy". Treating the absence of 
these headers as equivalent to their presence without any packages is 
sufficient to get the proper legacy behavior. The tricky part is 
figuring out out when their absence *doesn't* mean that, which is 
significant only in the non-legacy case. In particular, when they aren't 
present in INVITE it means deferral of the "offer" to the UAS. And 
possibly absence in an UPDATE means "don't renegotiate"???

I'm confused by the three way negotiation of info packages in 
INVITE/2xx/ACK. Its allowed when the Send-Info/Recv-Info are in the 
INVITE, but not when they are deferred to the INVITE response, or when 
they are conveyed in UPDATE and its response. If the three way handshake 
is needed to seal the deal, then those other options should be off the 
table. But the "deferred offer" of these is really needed, so it can't 
be off the table. Or is this just an extra benefit that can be exploited 
when possible?

Also, I don't see any provision for additional round(s) of negotiation 
before 2xx via PRACK and UPDATE, though there is provision for 
additional "half-negotiations" via provisional responses and the final 
response. Given the parallels with O/A, I'd prefer to see them more 
aligned in this regard, though I can be talked out of that with a good 
argument.

I'd also like to take advantage of the lessons that have been learned 
with O/A and nail down more of the semantics now. One issue that leaps 
to mind in that regard is what happens if we start to negotiate info 
packages in a reINVITE and then the reINVITE fails?

IMO what is needed is a state model for this stuff, added to the state 
for an invite-dialog-usage. This state should determine which packages 
may be sent, and which should be received without error. We should be 
very clear about exactly which events cause changes to this state.

Even then there are race conditions that need to be clarified. For 
instance: Suppose, as a result of an INVITE/1xx exchange between Alice 
and Bob, that packages P & Q are allowed to be sent from Alice to Bob. 
Alice then sends an INFO with package Q, and at the same time Bob sends 
a 2xx that only allows the receipt of package P. Then Bob receives the 
INFO with package Q. What should happen?

Another issue is that if the Send-Info/Recv-Info contents change in 
subsequent 1xx responses to the same INVITE, the UAS has no guarantee 
that they are received. So any reduction in what can be received cannot 
be counted upon until the 2xx/ACK.

	Thanks,
	Paul
_______________________________________________
Sip mailing list  https://www.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: Wed, 22 Oct 2008 11:36:26 +0200

Hi, 

Recv-Info? Does that indicate a "half-legacy" device??? Or does it delay
negotiation for one but not the other? Or does 
>the presence of one mean the absence of the other is equivalent to an
empty one?
absence of these headers as meaning "legacy". Treating the absence of
these headers as equivalent to their presence without 
>any packages is sufficient to get the proper legacy behavior. The
tricky part is figuring out out when their absence *doesn't* mean that,
which is significant only in the non-legacy case. In 
>particular, when they aren't present in INVITE it means deferral of the
"offer" to the UAS. And possibly absence in an UPDATE means "don't
renegotiate"???

I don't think the presence, or absence, of the S/R-Info headers should
in any way be connected to legacy in any way. A UA can be legacy no
matter if the headers are present, or not present, but that is all done
based on "configuration", as described in the draft.

So, if a UAC only included Send-Info, it means that it only supports
sending of Info packages. Then, it may, or may not, also support legacy
INFO usages, but that is completely separated.

INVITE/2xx/ACK. Its allowed when the Send-Info/Recv-Info are in the
INVITE, but not when they are deferred to the INVITE response, 
>or when they are conveyed in UPDATE and its response. If the three way
handshake is needed to seal the deal, then those other options should be
off the table. But the "deferred offer" of these 
>is really needed, so it can't be off the table. Or is this just an
extra benefit that can be exploited when possible?
before 2xx via PRACK and UPDATE, though there is provision for
additional "half-negotiations" via provisional responses 
>and the final response. Given the parallels with O/A, I'd prefer to see
them more aligned in this regard, though I can be talked out of that
with a good argument.

I agree (I think :). The negotiation whould be 2-way. Then, based on
what the UAC gets from the UAS, it may send a PRACK/UPDATE/re-INVITE
with a new set of supported Info packages, but that is a new 2-way
negotiation transaction.

with O/A and nail down more of the semantics now. One issue that leaps
to mind in that regard is what happens if we start 
>to negotiate info packages in a reINVITE and then the reINVITE fails?

That's a good point.

I think we should use the same rule as for offer/answer. Because, assume
I send you a new set of packages in a re-INVITE, and you send me back a
set in a 18x. Then we may start using info packages based on that
negotiation long before the re-INVITE is rejected.

for an invite-dialog-usage. This state should determine which packages
may be sent, and which should be received without 
>error. We should be very clear about exactly which events cause changes
to this state.
subsequent 1xx responses to the same INVITE, the UAS has no guarantee
that they are received. So any reduction in what can be 
>received cannot be counted upon until the 2xx/ACK.

True. But, I wonder whether this will really be a real-life problem.

And, we could a response code (4xx Info package not supported), which is
used by the UAS if it receives an info package which it doesn't support.
Then the UAC knows.

Regards.

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Oct 2008 10:54:30 +0100

I can't help wondering whether treating this like offer-answer is the
wrong approach. With offer-answer, an offer has a different semantic
meaning to an answer, particularly when it comes to more advanced
features such as SDP capability negotiation. Since offers and answers
are not explicitly indicated as such (unfortunately), we have to have
very precise rules for which messages contain offers and which contain
answers, so that there is no confusion.

I don't think Send-Info and Recv-Info have quite the same
characteristics. What problems would be introduced if we just said that
any request or any response can contain Send-Info and/or Recv-Info, and
that the latest one you send or receive is the one that applies? There
might be some scope for getting out of step, but I am having difficult
identifying really convincing concerns. It seems a lot cleaner than
introducing a whole lot of new state machinery similar to offer-answer.

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Christer Holmberg
> Sent: 22 October 2008 10:36
> To: Paul Kyzivat; SIP IETF; Eric Burger
> Subject: Re: [Sip] draft-ietf-sip-info-events-00: package negotiation
> 
> 
> Hi, 
>

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Oct 2008 13:07:18 -0400

I would offer the likelihood of a UAC only half implementing Info  
Packages is about 00.000% (five zeros, anyone?).  I cannot imagine  
anyone expending the effort to implement Info Packages but not use them.

If the UAS is a legacy device, the UAC will detect it from the absence  
of Send/Recv-Info headers.

If the UAC is a legacy device, the UAS will detect it from the absence  
of Send/Recv-Info headers.

Since I will soon make it clear a conforming UAC can send a legacy  
INFO, half negotiation is a non-issue.

For example, let's say it's two weeks from now and I've published the  
update to RFC 3398 to use Info Packages. Either the implementor will  
implement the full ISUP package, or not. It just does not make sense  
to do half the job, since 90% of the job gets done when one does the  
first half. If one side does not do Info Packages, then presumably, in  
the interests of legacy interoperability (and often because the code  
is already written), the device falls back to legacy INFO/RFC 3398.

3pcc? By the time you can list one header (Send or Recv), you can list  
both.

Therefore, I would offer it is an implementation failure to list only  
a Send-Info or Recv-Info header.

---

From: "Christer Holmberg" <[email-masked]>
Date: Fri, 31 Oct 2008 14:16:44 +0100

Hi,

A UA can support both legacy usages and INFO packages.

For example, ISUP transport may have been implemented in a network years
ago, and now some new fancy Info package stuff starts to come around. A
UA which supports the new stuff will still have to support the old
stuff.

Regards,

Christer

> Behalf Of Eric Burger
> Sent: 30. lokakuuta 2008 19:07
> To: Christer Holmberg
> Cc: SIP IETF; Paul Kyzivat
> I would offer the likelihood of a UAC only half implementing 
> Info Packages is about 00.000% (five zeros, anyone?).  I 
> cannot imagine anyone expending the effort to implement Info 
> Packages but not use them.
> 
> If the UAS is a legacy device, the UAC will detect it from 
> the absence of Send/Recv-Info headers.
> 
> If the UAC is a legacy device, the UAS will detect it from 
> the absence of Send/Recv-Info headers.
> 
> Since I will soon make it clear a conforming UAC can send a 
> legacy INFO, half negotiation is a non-issue.
> 
> For example, let's say it's two weeks from now and I've 
> published the update to RFC 3398 to use Info Packages. Either 
> the implementor will implement the full ISUP package, or not. 
> It just does not make sense to do half the job, since 90% of 
> the job gets done when one does the first half. If one side 
> does not do Info Packages, then presumably, in the interests 
> of legacy interoperability (and often because the code is 
> already written), the device falls back to legacy INFO/RFC 3398.
> 
> 3pcc? By the time you can list one header (Send or Recv), you 
> can list both.
> 
> Therefore, I would offer it is an implementation failure to 
> list only a Send-Info or Recv-Info header.
> 
> >> What happens if the initial INVITE by a UAC includes only 
> Send-Info 
> >> or
> > Recv-Info? Does that indicate a "half-legacy" device??? Or does it 
> > delay negotiation for one but not the other? Or does
> > tricky part is figuring out out when their absence *doesn't* mean 
> > that, which is significant only in the non-legacy case. In
> >> particular, when they aren't present in INVITE it means 
> deferral of 
> >> the
> > matter if the headers are present, or not present, but that is all 
> > done based on "configuration", as described in the draft.
> >
> > sending of Info packages. Then, it may, or may not, also support 
> > legacy INFO usages, but that is completely separated.
> >
> >
> >> or when they are conveyed in UPDATE and its response. If 
> the three  
> >> way
> >> and the final response. Given the parallels with O/A, I'd 
> prefer to  
> >> see

---

From: Eric Burger <[email-masked]>
Date: Fri, 31 Oct 2008 11:26:54 -0400

Agreed.  I would offer that just about 100% of the implementations in  
the next 18 months that do New ISUP will support Old ISUP, AND...

If a UA supports new ISUP transport, the likelihood of that UA only  
supporting sending New INFO, but only receiving Old INFO, is zero.