Subject: RE: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update

From: Manpreet Singh <[email-masked]>
Date: Thu, 18 Oct 2007 14:32:20 -0400

RFC 2833 on the SIP side can be easily converted to h245 out of band
signaling on H323 side for dtmf. I believe some vendors do it. Its pretty
much out of band in media plane to out of band in signaling plane.

Thanks  

-----Original Message-----
From: Eric Burger [mailto:[email-masked]] 
Sent: Thursday, October 18, 2007 2:23 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update

Correct, but only really for the purposes of signaling. Remember, in the
context of SIP, it is H.323 on the other side. If it cannot take RFC2833 on
the SIP side, it is a boat anchor.

--
Sent from my wireless e-mail device. Sorry if terse.  We all need lemonade:
see <http://www.standardstrack.com/ietf/lemonade> for what lemonade is.

----- Original Message -----
From: Paul Kyzivat <[email-masked]>
To: Eric Burger
Cc: IETF SIP List <[email-masked]>
Sent: Thu Oct 18 11:11:52 2007
Subject: Re: [Sip] Unsolicited NOTIFY/INFO versus Solicited State Update

Eric Burger wrote:
> Is it the gateway is doing DTMF -> H.245 mapping, or is it just for 
> doing compressed codec transport?

I know next to nothing about H.323. My understanding is that it thinks DTMF
must travel in the signaling path for H.323, and I gather that means using
H.245.

	Paul

> On 10/15/07 8:24 AM, "Paul Kyzivat" <[email-masked]> wrote:
> 
> 
> 
> 
>     Eric Burger wrote:
>     >  A few times I have seen a comment stating the endpoint interested
in
>     >  potentially receiving DTMF notifications may not know whether or
>     not it
>     >  needs DTMF. As such, the endpoint would be forced to always issue a
>     >  SUBSCRIBE, even if it will not be interested in DTMF.
>     >
>     >  Could someone please describe a scenario in which the endpoint
>     does NOT
>     >  KNOW, a'priori, it will be interested in DTMF?
>     >
>     >  All the ones I can think of, like supplemental dial digits, ACD,
>     register
>     >  recall, and return to application are all known to the AS or Proxy
>     driving
>     >  the interaction.
>     >
>     >  What else is out there?
> 
>     I think I have heard that SIP-H.323 GWs fall into this category.
> 
>     (As well as gateways to some other more proprietary protocols that
shall
>     remain unnamed here.)
> 
>             Paul
> 
>     >  On 10/10/07 12:20 PM, "Christer Holmberg"
>     <[email-masked]>
>     >  wrote:
>     >
>     > > Hi,
>     > >
>     > >>> Ignorning the reason why people are using INFO is not going
>     > >>> to make things better either...
>     > >>>
>     > >>> I think most people are aware of KPML etc - we don't need to
>     > >>> tell them that.
>     > >> I seriously don't think people are using INFO because they think
>     it's
>     > >> better than KPML.
>     > >> I think peopled use to use INFO because (a) they implemented it
>     before
>     > >> RFC 2833, and (b) because it was difficult for them to implement
>     > >> RFC 2833 when it got implemented and (c) KPML didn't exist at
>     that time.
>     > > (d) they think it's a waste of resources to establish multiple
>     additional
>     > > subscription dialogs (there may be other type of data than DTMF
>     they are
>     > > willing to receive) which in many cases may not even be used
>     during the call
>     > > (it can not be assumed that the one sending the subscription
>     always knows
>     > > exactly when it will receive events). Maybe DTMF is not the best
>     example in
>     > > the world (my fault - I should have been more generic), but I am
>     sure there
>     > > could be events which would not be used in a very high percentage
>     of all
>     > > calls, but still the additional subscription dialog(s) would have
>     to be
>     > > established - just in case.
>     > >
>     > > I still strongly think it would be much better to describe the
>     > > issues/advantages/disadvantages with BOTH INFO and events, and
>     study what
>     > > possible needs to defined related to negotiation etc, instead of
>     just ignoring
>     > > the real world and providing flexibility to people using SIP for
>     their
>     > > applications...
>     > >
>     > > Regards,
>     > >
>     > > Christer
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > >
>     > > I believe at this point, this is an imaginary issue.
>     > >
>     > >
>     > >
>     > > _______________________________________________
>     > > 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
>     >
>     >
>     >  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
>     >
> 
> 
> 
> 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.

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