Subject: [Sip] draft-ietf-sip-info-events-00 using RFC 3265 instead

From: "Nasir Khan" <[email-masked]>
Date: Wed, 29 Oct 2008 13:06:18 -0400

[Per Keith's suggestion starting a new thread, copied from last one]

Yes Paul, that is what I was trying to get at.
Sorry if all this was already discussed and closed.
Do we have a comaparitive between the two approaches from past?

The reason I brought it out was that there are several similarities in where
we are going with info events and 3265.

 I hope we do not undermine the usage of SIP events.
As an example if one comes up with a brand new application that has some
small data to be transferred between UAs and the session is INVITE based
then which approach should one take? Will we have clear guidelines or leave
it open?
IMHO overlapping semantics is also not very good for interoperability.

Is the legacy (mis)use of INFO the most compelling reason for this approach
of bringing it into proper framework?

again apologies for repetition.

regards
nasir

-------------------------------
I'm not certain I understand the point you are making.
Is it that we don't need info events because we could accomplish the same
thing using subscriptions to suitable event packages?

If that is your point, we have been down that path already. Many of us have
taken that position in the past (and may still believe it today), but there
were many arguments that that approach is to heavy weight. Evidence of that
is the continued use of info for DTMF even though we have an event package
for that.

       Paul

Nasir Khan wrote:

Maybe it warrants a separate thread but I would like to discuss section
7.1.3 of this draft where 3265 is talked about as an alternative.
Since we are talking about the notion of well defined info packages and the
INFO messages
will carry information as a result of an event like an ISUP event or DTMF
event (the name of the draft itself has "event" in it), then the two User
Agents can very well subscribe to these events and use the notifications for
the information exchange.
This will automatically inherit all the good work done around notification
framework and will lay to rest lot of questions and perhaps save some
re-invention.
 Regards
Nasir

-- 
Get the most comprehensive open source SIP application testing framework at
http://sipper.agnity.com
_______________________________________________
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: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Oct 2008 13:56:40 -0400

I will try to summarize the essence of the arguments:

Establishing the subscription requires more messages to be exchanged.

The subscription then requires state to be maintained, and it must be 
refreshed periodically.

The desired uses of info are often things that *might* be exchanged on 
any call, but often (usually?) are not. So paying a lot of cost for the 
possibility is thought to be a bad deal.

	Thanks,
	Paul

Nasir Khan wrote:
> The reason I brought it out was that there are several similarities in 
> where we are going with info events and 3265.
>  
> then which approach should one take? Will we have clear guidelines or 
> leave it open?
> Is the legacy (mis)use of INFO the most compelling reason for this 
> approach of bringing it into proper framework?
>  
> Is it that we don't need info events because we could accomplish the 
> same thing using subscriptions to suitable event packages?
> 
> If that is your point, we have been down that path already. Many of us 
> have taken that position in the past (and may still believe it today), 
> but there were many arguments that that approach is to heavy weight. 
> Evidence of that is the continued use of info for DTMF even though we 
> have an event package for that.
> 
>        Paul
> 
> Nasir Khan wrote:
> 
> Since we are talking about the notion of well defined info packages and 
> the INFO messages
> will carry information as a result of an event like an ISUP event or 
> DTMF event (the name of the draft itself has "event" in it), then the 
> two User Agents can very well subscribe to these events and use the 
> notifications for the information exchange.
> This will automatically inherit all the good work done around 
> notification framework and will lay to rest lot of questions and perhaps 
> save some re-invention.
>  Regards
> Nasir
> 
> -- 
> Get the most comprehensive open source SIP application testing framework 
> at http://sipper.agnity.com <http://sipper.agnity.com/>
> 
> 
> ------------------------------------------------------------------------
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Oct 2008 13:25:39 -0500

So, draft-burger-sip-info-02 went over some of the comparisons between 
3265 and INFO packages. Perhaps we can head off future confusion by 
merging even more 3265-related text from that document into the 
info-packages document.

To address Nasir's comments on a more practical level: currently, INFO 
is so underspecified that every additional use causes harm to the entire 
SIP protocol by introducing new incompatibilities. We can either 
deprecate the use of INFO (and be soundly ignored by implementors all 
over the world), or we can try to reform INFO to be a (somewhat) 
upstanding member of the SIP method pantheon.

And until we do so, we're going to burn unwarranted quantities of time 
arguing about the open festering sore that is INFO.

/a

On 10/29/08 12:56 PM, Paul Kyzivat wrote:
> any call, but often (usually?) are not. So paying a lot of cost for 
> the possibility is thought to be a bad deal.
>
>     Thanks,
>     Paul
>
> Nasir Khan wrote:
>> The reason I brought it out was that there are several similarities 
>> in where we are going with info events and 3265.
>>  
>> As an example if one comes up with a brand new application that has 
>> some small data to be transferred between UAs and the session is 
>> INVITE based then which approach should one take? Will we have clear 
>> guidelines or leave it open?
>> If that is your point, we have been down that path already. Many of 
>> us have taken that position in the past (and may still believe it 
>> today), but there were many arguments that that approach is to heavy 
>> weight. Evidence of that is the continued use of info for DTMF even 
>> though we have an event package for that.
>>
>>        Paul
>>
>> Nasir Khan wrote:
>>
>> Maybe it warrants a separate thread but I would like to discuss 
>> section 7.1.3 of this draft where 3265 is talked about as an 
>> alternative.
>> Since we are talking about the notion of well defined info packages 
>> and the INFO messages
>> notification framework and will lay to rest lot of questions and 
>> perhaps save some re-invention.
>>  Regards
>> Nasir
>>
>> -- 
>> Get the most comprehensive open source SIP application testing 
>> framework at http://sipper.agnity.com <http://sipper.agnity.com/>
>>
>>