Eric Burger wrote:
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.
I'm out of my element here, but its my *impression* that it can come to
a decision whether the gw must terminate the media or not. If it can use
out of band dtmf on the sip side, and map it to H.245 on the other side,
then it may be able to avoid terminating the media, which could save
resources for other purposes.
Paul
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 PROTECTED]>
To: Eric Burger
Cc: IETF SIP List <sip@ietf.org>
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 PROTECTED]> 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 PROTECTED]>
> 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 PROTECTED] for questions on current sip
> > Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
