Subject: [Sip] Re: AW: [Sipping] comments on draft-burger-sip-info-00

From: Eric Burger <[email-masked]>
Date: Fri, 20 Jul 2007 16:46:11 -0400

[Moved to SIP by chair request]

MUMBLEBRATZ for UA-to-UA communication will always work if you own the
endpoints.  Might as well use INFO for MUMBLEBRATZ.

If one wants interoperable communication or if you want to deploy equipment
from more than one vendor, or at least not having to specify exact behavior
(i.e., creating your own proprietary protocol), INFO doesn't work, as
already documented.

For that matter, we can save a ton of messages if we drop all the pesky
negotiation in SIP.  Why bother if we just "know" what the endpoints will
accept.  We just need to start sending RTP and things will just work :-)

On 7/18/07 10:10 AM, "Jesske, R" <[email-masked]> wrote:

> Dear all,
> I'm concerned about the discussion here and the aim of the draft to restrict
> the use of INFO only to SIP-T and Q-SIG.
> 
> If you now change restrict the RFC2976 you will tear down each implementation
> already done based on RFC2976. Like for DTMF that is broadly used within the
> world. So you are against backward compatibility?
> 
> The draft is claiming that INFO has to be routed over each proxy where the
> INVITE is routed to. I do not know what's the problem with that. A proxy
> forwards and the question is how much load will this cause. UA's can sent
> re-INVITES or REGISTER, RE-REGISTER a couple of times and nobody claims that.
> INFO is used for UA to UA communication so is this not proper enough that at
> least the UA's will know what to do with the MIME?
> INFO is ideal to sent information that has to correlate with the Dialog using
> other mechanisms like an 2nd stream like http or a MESSAGE or a other control
> protocol can not fulfil this. Even it could be get lost when you want to
> traverse several SIP domains or if you interwork with the PSTN/ISDN.
> 
> The Example of DTMF for INFO can only be done at mid dialog.
> 
> Using KPML --> We have minimum 4 more Messages. No additional Load?
> 
> 
> 
> Best Regards
> 
> Roland
> 
> 
> 
>> -----Ursprüngliche Nachricht-----
>> Von: Christer Holmberg (JO/LMF)
>> [mailto:[email-masked]]
>> Gesendet: Mittwoch, 18. Juli 2007 12:18
>> An: Dean Willis
>> Cc: IETF Sipping List
>> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00
>> 
>> 
>> 
>> Hi, 
>> 
>>>>>> - I disagree with the statement in chapter 1 regarding
>> the "context 
>>>>>> for interpreting". The context is associated with the
>> content type.
>>>>>> 
>>>>> 
>>>>> Content type is, as I have repeatedly argued, completely
>> insufficient
>> 
>>>>> for interpretation of context in the general case. What,
>> for example,
>> 
>>>>> does it mean when an INFO shows up with a wav file
>> attached? Play it?
>>>>> Record it? Parse it using speech recognition and pass it
>> to a command
>> 
>>>>> processor?
>>>> 
>>>> The dialog (you can't send INFOs out-of-dialog, as far as I
>> know) will
>> 
>>>> be associated with an application, and if the application
>> doesn't know
>> 
>>>> what to do with it, it can promt the user: "You have now received a
>>>> file. What do you want to do with it? Save it? Play it? Display it?
>>>> Delete it?".
>>> 
>>> And how does the receiver know what the sender intended?
>>> 
>>> Assume you're taking to my "phone" application. You send digits.
>>> Should those be rendered to me, or fed into the user
>>> interface of a phone-based game we happen to be playing?
>> 
>> How do you solve it with 2833?
>> 
>> How do you solve it with KPML?
>> 
>> You could even have the same problem with normal voice, e.g.
>> if the game
>> is controlled using voice recognition. Shall the received voice be fed
>> to the speaker, or fed to the game application?
>> 
>> In some cases it may not matter if the data is fed to multiple
>> applications. But, if you do need to dispatch data so specific
>> applications you either need some kind of application
>> reference, or you
>> handle the dispatching locally in your device (the game
>> application can
>> tell it wants DTMFs, and/or the device chooses - either
>> automatically or
>> manually - which application will get the data etc). Or you use
>> different SIP sessions.
>> 
>> In other cases you will not have the problem. For example,
>> videoControl
>> messages would normally be fed to a video control application, and
>> nowhere else.
>> 
>> Regards,
>> 
>> Christer
>> 
>> 
>> 
>> _______________________________________________
>> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
>> This list is for NEW development of the application of SIP
>> Use [email-masked] for questions on current sip
>> Use [email-masked] for new developments of core SIP
>> 
> 
> 
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

_______________________________________________
Sip mailing list  https://www1.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 (JO/LMF)" <[email-masked]>
Date: Sat, 21 Jul 2007 20:51:39 +0200

Hi,
 
>MUMBLEBRATZ for UA-to-UA communication will always work if 
>you own the endpoints.  Might as well use INFO for MUMBLEBRATZ.
> 
>If one wants interoperable communication or if you want to 
>deploy equipment from more than one vendor, or at least not 
>having to specify exact behavior (i.e., creating your own 
>proprietary protocol), INFO doesn't work, as already documented.

If you are going to use INFO to carry videoControl messages, of course those messages, and the meaning of those, must be defined and documented - in order to make them non-proprietary.

It's the same with ISUP. You use INFO to carry SPECIFIED ISUP messages, and endpoints supporting ISUP know the procedures how to deal with the messages, because it is defined in standard documentation.
 
>For that matter, we can save a ton of messages if we drop all 
>the pesky negotiation in SIP.  Why bother if we just "know" 
>what the endpoints will accept.  We just need to start 
>sending RTP and things will just work :-)

Please show me message you save by not using INFO. The negotiation can in most cases be "encapsulated" in SIP messages you are going to send anyway.

But, if you use an event based mechanism, you actually WILL get more SIP messages, because you need to send the NOTIFY request(s).

Regards,

Christer

> > I'm concerned about the discussion here and the aim of the draft to 
> > restrict the use of INFO only to SIP-T and Q-SIG.
> > 
> > If you now change restrict the RFC2976 you will tear down each 
> > implementation already done based on RFC2976. Like for DTMF that is 
> > broadly used within the world. So you are against backward 
> compatibility?
> > 
> > The draft is claiming that INFO has to be routed over each 
> proxy where 
> > the INVITE is routed to. I do not know what's the problem 
> with that. A 
> > proxy forwards and the question is how much load will this 
> cause. UA's 
> > can sent re-INVITES or REGISTER, RE-REGISTER a couple of 
> times and nobody claims that.
> > INFO is used for UA to UA communication so is this not 
> proper enough 
> > that at least the UA's will know what to do with the MIME?
> > INFO is ideal to sent information that has to correlate with the 
> > Dialog using other mechanisms like an 2nd stream like http or a 
> > MESSAGE or a other control protocol can not fulfil this. 
> Even it could 
> > be get lost when you want to traverse several SIP domains 
> or if you interwork with the PSTN/ISDN.
> > 
> interface of a 
> >>> phone-based game we happen to be playing?
> >> 
> >> is controlled using voice recognition. Shall the received voice be 
> >> fed to the speaker, or fed to the game application?
> >> 
> reference, or 
> >> you handle the dispatching locally in your device (the game 
> >> application can tell it wants DTMFs, and/or the device chooses - 
> >> either automatically or manually - which application will get the 
> >> data etc). Or you use different SIP sessions.
> >> 
> >> videoControl messages would normally be fed to a video control 
> >> application, and nowhere else.
> >> 
> >> Regards,
> >> 
> >> Christer
> >> 
> >> 
> >> 
> >> Sipping mailing list  
> https://www1.ietf.org/mailman/listinfo/sipping
> >> This list is for NEW development of the application of SIP Use 
> >> [email-masked] for questions on current sip Use 
> >> [email-masked] for new developments of core SIP
> >> 
> > 
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> 
> 
> Notice:  This email message, together with any attachments, 
> may contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  affiliated entities,  that may be 
> confidential,  proprietary,  copyrighted  and/or legally 
> privileged, and is intended solely for the use of the 
> individual or entity named in this message. If you are not 
> the intended recipient, and have received this message in 
> error, please immediately return this by email and then delete it.
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Eric Burger <[email-masked]>
Date: Sat, 21 Jul 2007 21:40:01 -0400

No, the point is you almost always use more messages by NOT using INFO.
However, fewer messages and not interoperable is not as good as more
messages and interoperable.

On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)"
<[email-masked]> wrote:

> If you are going to use INFO to carry videoControl messages, of course those
> messages, and the meaning of those, must be defined and documented - in order
> to make them non-proprietary.
> 
> It's the same with ISUP. You use INFO to carry SPECIFIED ISUP messages, and
> endpoints supporting ISUP know the procedures how to deal with the messages,
> because it is defined in standard documentation.
> 
> Please show me message you save by not using INFO. The negotiation can in most
> cases be "encapsulated" in SIP messages you are going to send anyway.
> 
> But, if you use an event based mechanism, you actually WILL get more SIP
> messages, because you need to send the NOTIFY request(s).
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
>> 
>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Sun, 22 Jul 2007 09:05:45 +0200

Hi, 

>No, the point is you almost always use more messages by NOT using INFO.

I think issues like that should also be documented in your draft.

>However, fewer messages and not interoperable is not as good 
>as more messages and interoperable.

Well, the initeroperability issue is still under discussion.

Regards,

Christer

> >> MUMBLEBRATZ for UA-to-UA communication will always work if you own 
> >> the endpoints.  Might as well use INFO for MUMBLEBRATZ.
> >> 
> >> If one wants interoperable communication or if you want to deploy 
> >> equipment from more than one vendor, or at least not having to 
> >> specify exact behavior (i.e., creating your own proprietary 
> >> protocol), INFO doesn't work, as already documented.
> > 
> > If you are going to use INFO to carry videoControl 
> messages, of course 
> > those messages, and the meaning of those, must be defined and 
> > documented - in order to make them non-proprietary.
> > 
> > It's the same with ISUP. You use INFO to carry SPECIFIED ISUP 
> > messages, and endpoints supporting ISUP know the procedures how to 
> > deal with the messages, because it is defined in standard 
> documentation.
> > 
> >> For that matter, we can save a ton of messages if we drop all the 
> >> pesky negotiation in SIP.  Why bother if we just "know"
> >> what the endpoints will accept.  We just need to start sending RTP 
> >> and things will just work :-)
> > 
> > Please show me message you save by not using INFO. The 
> negotiation can 
> > in most cases be "encapsulated" in SIP messages you are 
> going to send anyway.
> > 
> > But, if you use an event based mechanism, you actually WILL 
> get more 
> > SIP messages, because you need to send the NOTIFY request(s).
> > 
> > Regards,
> > 
> > Christer
> > 
> > 
> > 
> > 
> > 
> > 
> >> 
> >> 
> >> Notice:  This email message, together with any attachments, may 
> >> contain information  of  BEA Systems,  Inc.,  its 
> subsidiaries  and  
> >> affiliated entities,  that may be confidential,  proprietary,  
> >> copyrighted  and/or legally privileged, and is intended solely for 
> >> the use of the individual or entity named in this message. 
> If you are 
> >> not the intended recipient, and have received this message 
> in error, 
> >> please immediately return this by email and then delete it.
> >> 
> >> 
> >> [email-masked] for new developments on the application of sip
> >> 
> > 
> 
> 
>