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

[Eric Burger]

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

On Oct 31, 2008, at 9:16 AM, Christer Holmberg wrote:

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

Hi,

A UA can support both legacy usages and INFO packages.


UA which supports the new stuff will still have to support the old
stuff.

Regards,

Christer

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

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Eric Burger
Sent: 30. lokakuuta 2008 19:07
To: Christer Holmberg
Cc: SIP IETF; Paul Kyzivat
Subject: Re: [Sip] draft-ietf-sip-info-events-00: package negotiation

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.

On Oct 22, 2008, at 5:36 AM, Christer Holmberg wrote:

Hi,

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

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

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?

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.

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.

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

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip