Re: draft-ietf-sip-info-events-00: package negotiation

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.

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

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

_______________________________________________
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