Hi,
>No. For subscribe/notify interaction, it is trivial: whomever issues
the subscribe gets the notify. Easy for the stack to figure out. For
INFO
>interaction, everything goes to call control. That works if your model
is pure softswitch/feature server, but not many folks are doing that
anymore.
Assume two applications are interested of the same event, so they both
subscribe to it. Now, how does the SENDER know to which subscription to
use for a specific application?
Regards,
Christer
Hi,
As I have said before: you have similar problems with
other mechanisms.
Regards,
Christer
> -----Original Message-----
> From: Eric Burger [mailto:[EMAIL PROTECTED]
> Sent: 12. lokakuuta 2007 12:45
> To: Christer Holmberg
> Cc: [email protected]
> Subject: Re: [Sip] INFO
>
> Routing of the message once it gets to the device
> (application), not route to the device (transport).
>
> --
> Sent from my wireless e-mail device. Sorry if terse.
We all
> need lemonade: see
> <http://www.standardstrack.com/ietf/lemonade>
<http://www.standardstrack.com/ietf/lemonade> for what lemonade is.
>
> ----- Original Message -----
> From: Christer Holmberg
<[EMAIL PROTECTED]>
> To: Eric Burger; Hadriel Kaplan
<[EMAIL PROTECTED]>
> Cc: sip <[email protected]>
> Sent: Thu Oct 11 19:38:06 2007
> Subject: RE: [Sip] INFO
>
>
> Hi Eric,
>
> I am not sure I understand what you mean, but INFOs
are
> routed according to the route set of the invite dialog
they
> are sent within.
>
> If you want to transport information using some other
path
> you can of course not send the information within the
invite dialog.
>
> Regards,
>
> Christer
>
>
> > -----Original Message-----
> > From: Eric Burger [mailto:[EMAIL PROTECTED]
> > Sent: 12. lokakuuta 2007 0:35
> > To: Christer Holmberg; Hadriel Kaplan
> > Cc: sip
> > Subject: Re: [Sip] INFO
> >
> > Right: "DTMF may not be the only information users
want to send to
> > each other during a session." This is why one MUST
> establish multiple
> > subscription dialogs. How else would one keep track
of the
> different
> > elements / local routing decisions? If you are
proposing
> application
> > routing a'la P-Asserted-Service...
> >
> >
> > On 9/11/07 2:30 AM, "Christer Holmberg (JO/LMF)"
> > <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > > Hi,
> > >
> > > Let's also keep in mind that DTMF may not be the
only information
> > > users want to send to each other during a session.
So, you
> > will need
> > > to establish subscription dialogs for every type
of event
> that the
> > > users may want to send during the session...
> > >
> > > Regards,
> > >
> > > Christer
> > >
> > >> -----Original Message-----
> > >> From: Christer Holmberg (JO/LMF)
> > >> [mailto:[EMAIL PROTECTED]
> > >> Sent: 11. syyskuuta 2007 12:27
> > >> To: Hadriel Kaplan; Eric Burger
> > >> Cc: sip
> > >> Subject: RE: [Sip] INFO
> > >>
> > >>
> > >> Hi,
> > >>
> > >>>> Consider a PSTN call. The call goes from the
gateway to
> > >> softswitch /
> > >>>> Proxy. Proxy routes to VM App Server. INFO
has to
> pass through
> > >>>> softswitch / Proxy.
> > >>>> In KPML-land, VM App Server *directly*
subscribes to UAC
> > key press
> > >> state, bypassing the softswitch.
> > >>
> > >> [Christer] As I've said before, there are
environments
> where some
> > >> proxies must (for whatever reason) be passed
through. I guess an
> > >> outbound proxy is a good example.
> > >>
> > >>>> KPML and INFO have the same number of messages
for a
> > SINGLE digit;
> > >> KPML wins
> > >>>> hands-down for multiple digits or reports.
> > >>>
> > >>> Not exactly - for a single digit, KPML would
generate a
> > >>> Subscribe/200/Notify/200 before the single DTMF
was even
> > pressed -
> > >>> before the actual Notify with the digits in it.
> > >>> And of course there is now also a subscribe
dialog involved.
> > >>> Assuming a one-shot single digit type, then,
we're
> talking 6 SIP
> > >>> messages for KPML vs. 2 for Info.
> > >>
> > >> [Christer] And, in cases where you need to send
DTMFs
> (or whatever
> > >> information) in both directions you actually need
2 subscription
> > >> dialogs
> > >> - one in each direction, and maintaining dialog
state also
> > consumes
> > >> resources. And, in some cases you may not even
know
> > whether you will
> > >> ever have to use the dialog.
> > >>
> > >>
> > >>>> More importantly, let's take a Call Management
(CM)
> > >> application that
> > >>>> calls a VM application when they cannot find
the
> > >> subscriber. INFO has
> > >>
> > >>>> to pass through the softswitch / Proxy to the
CM
> > >> application. Cool -
> > >>>> it is a proxy, so it knows to relay. But OOPS!
The CM
> > application
> > >>>> has to proxy the INFOs to the VM application.
Yes - you
> > could be a
> > >>>> good programmer and remember to do that
EVERYWHERE you
> place an
> > >>>> outbound call, but it is really easy to get
wrong.
> > >>>
> > >>> I'm not sure I understand the scenario. The VM
learned
> > about this
> > >>> call how?
> > >>> By being in the signaling path, no? So why
wouldn't the
> > CM forward
> > >>> INFO along the path? (I mean it is in the same
dialog,
> > after all)
> > >>> Now I don't doubt it could screw that up, and
eat the
> > info thinking
> > >>> it was for itself, but lots of things can get
screwed up
> > - my guess
> > >>> is KPML will not be impervious to screw ups.
> > >>
> > >> [Christer] I also have problems understanding the
> > scenario. INFO is
> > >> routed to wherever the INVITE that initiated the
dialog
> > was routed...
> > >>
> > >> Regards,
> > >>
> > >> Christer
> > >>
> > >>
> > >> _______________________________________________
> > >> 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.
>
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
