[Freeswitch-dev] Dialog events

Beeton, Carolyn (Carolyn) cbeeton at avaya.com
Wed Oct 13 12:46:56 PDT 2010 

I've attached a patch which shows what I am thinking of.  It adds two columns into the sip_dialogs table, to track to_tag and from_tag.  Since one of the tags is sometimes not known when the dialog is created, it is updated on the 200 response (there is probably a better place to do this).  Then when a NOTIFY(dialog) is being crafted, the call_id and tags and the remote contact uri are used.  These fields and the remote target uri are important because they allow an INVITE with REPLACES to be crafted.

I am still not sure I understand the role of the sip_registrations table when crafting dialog events.  I have reworked the query in a way which seems to me to match what the rfc describes.

Please let me know what you think of this patch.  Is there a set of presence tests that can be run to ensure that existing behaviour is not adversely affected?  I know the contents of the <dialog> element are still not 100% correct (for example, in the case where the call has come in from another domain, the remote identity uses the wrong domain.  This doesn't cause me a problem but really it should be correct).

Thanks,
Carolyn

> -----Original Message-----
> From: freeswitch-dev-bounces at lists.freeswitch.org
> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
> Behalf Of Anthony Minessale
> Sent: Tuesday, October 12, 2010 2:28 PM
> To: freeswitch-dev at lists.freeswitch.org
> Subject: Re: [Freeswitch-dev] Dialog events
>
> in this case you could possibly branch off with a 2nd sql
> stmt when so configured in the presence_probe handler to do
> exactly what you want and select all the same columns
>
> On Tue, Oct 12, 2010 at 1:05 PM, Beeton, Carolyn (Carolyn)
> <cbeeton at avaya.com> wrote:
> > I have enabled at least some of the debug.  I will check to
> see if it is at level 10.
> >
> > Our application SUBECRIBEs for dialog events only when it
> is interested in them, with a very short timeout (ideally 0,
> but this does not work for some endpoints).  We expect a
> NOTIFY back giving the current status.  We don't want status
> events continually, just a single update when we ask for it.
> It seems like the code is very close to supporting this.
> >
> > Carolyn
> >
> >> -----Original Message-----
> >> From: freeswitch-dev-bounces at lists.freeswitch.org
> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On Behalf Of
> >> Anthony Minessale
> >> Sent: Tuesday, October 12, 2010 1:47 PM
> >> To: freeswitch-dev at lists.freeswitch.org
> >> Subject: Re: [Freeswitch-dev] Dialog events
> >>
> >> The presence probe statement you are following is executed when a
> >> subscription happens to get the first event.  its a way to
> make all
> >> entities fire a presence event.
> >>
> >> The real presence sql stmt is the one at 698 which does
> not involve
> >> registration and is triggered by presence_in events which will be
> >> fired when you set the presence_id.  If you don't have the domains
> >> the same and the presence_hosts field set to cover the
> variants you
> >> may get nothing.
> >>
> >> The only real problem I can imagine you are having is getting that
> >> first required notify after a subscribe, instead you would
> not get it
> >> until you placed a call.  It would require just blindly accepting
> >> subscriptions to everything to do what you want.
> >>
> >> have you enabled debug-presence set to 10 in
> >> conf/autoload_configs/sofia.conf.xml ?
> >>
> >> This will show the SQL STMTS ad they are being run and
> could help you
> >> to see what you are missing.
> >>
> >>
> >>
> >>
> >> On Tue, Oct 12, 2010 at 12:10 PM, Beeton, Carolyn (Carolyn)
> >> <cbeeton at avaya.com> wrote:
> >> > I am still only getting the partial dialog-info element,
> >> not the full dialog contents that I expect when I subscribe for
> >> dialog events.  I get this:
> >> >
> >> > <dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\"
> >> > version=\"1\" state=\"partial\" entity=\"sip:44 at cbeeton.com\">
> >> > </dialog-info>
> >> >
> >> > But not the per-dialog element containing details about
> >> active dialogs, e.g.:
> >> >
> >> > <dialog-info xmlns=\"urn:ietf:params:xml:ns:dialog-info\"
> >> > version=\"1\" state=\"full\"
> entity=\"sip:44 at cbeeton.com\"> <dialog
> >> > id=\"d3d433ce-2324c33e at 10.10.10.116\"
> >> > call-id=\"d3d433ce-2324c33e at 10.10.10.116\"
> >> local-tag=\"KQcQB9v3rmgpp\"
> >> > remote-tag=\"1516c6aa-e5e6365a\" direction=\"initiator\">
> >> > <state>confirmed</state> <local> <identity
> >> > display=\"44\">sip:44 at 10.10.10.158</identity>
> >> > <target uri=\"sip:44 at 10.10.10.158\"> <param
> >> > pname=\"+sip.rendering\" pvalue=\"yes\"/> </target> </local>
> >> > <remote> <identity
> >> display=\"201-116\">sip:201 at 10.10.10.158</identity>
> >> > <target uri=\"sip:201 at 10.10.10.116;transport=udp\"/>
> >> > </remote>
> >> > </dialog>
> >> > </dialog-info>
> >> >
> >> > This is what I am looking for, but the details are blocked
> >> because the query looks in sip_registrations first and there are
> >> none.  As you say below, "the only way to really know what state a
> >> phone is in, is to check if it's involved in a call or is
> registered"
> >> - but the query is doing effectively "AND is registered"
> >> >
> >> > Setting presence_id did not make a difference that I could see.
> >> >
> >> > Carolyn
> >> >
> >> >> -----Original Message-----
> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org
> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
> Behalf Of
> >> >> Anthony Minessale
> >> >> Sent: Tuesday, October 12, 2010 11:28 AM
> >> >> To: freeswitch-dev at lists.freeswitch.org
> >> >> Subject: Re: [Freeswitch-dev] Dialog events
> >> >>
> >> >> Try this:
> >> >>
> >> >>  <extension name="44">
> >> >>    <condition field="destination_number" expression="^44$">
> >> >>      <action application="set"
> data="presence_id=44@$${domain}"/>
> >> >>      <action application="answer"/>
> >> >>      <action application="sleep" data="1000"/>
> >> >>      <action application="playback" data="/music/default.wav"/>
> >> >>    </condition>
> >> >>  </extension>
> >> >>
> >> >> change $${domain} to some other value if you have a manually
> >> >> configured domain.
> >> >>
> >> >> if you don't set presence_id, you will never see any presence
> >> >> messages for that call.
> >> >>
> >> >> Setting presence id is critical to get your call to broadcast
> >> >> presence events.
> >> >> The reason we care about registered phones is when you
> >> subscribe to
> >> >> an extension, it's assumed to represent a phone and the
> >> only way to
> >> >> really know what state a phone is in, is to check if it's
> >> involved in
> >> >> a call or is registered, anything else means you have
> no idea and
> >> >> could not report proper presence.
> >> >>
> >> >> The sip_dialogs table is not part of the dialog-info
> stuff so RFC
> >> >> quotes would not be appropriate in this case.  This table
> >> is just a
> >> >> toll FS uses in many instances to track extra info about a
> >> sip call
> >> >> for various features including sometimes the dialog-info events.
> >> >>
> >> >>
> >> >> On Tue, Oct 12, 2010 at 10:09 AM, Beeton, Carolyn (Carolyn)
> >> >> <cbeeton at avaya.com> wrote:
> >> >> > OK.  I have configured the freeswitch dialplan to answer
> >> >> extension 44 and invoke the playback application:
> >> >> >
> >> >> >   <extension name="44">
> >> >> >    <condition field="destination_number" expression="^44$">
> >> >> >      <action application="answer"/>
> >> >> >      <action application="sleep" data="1000"/>
> >> >> >      <action application="playback"
> data="/music/default.wav"/>
> >> >> >    </condition>
> >> >> >  </extension>
> >> >> >
> >> >> > Now I want to be able to subscribe to 44@<fs ip:port> to
> >> >> see what calls are being handled there (this is just a
> first step
> >> >> towards monitoring the calls that FS is handling for us).
> >> >> >
> >> >> > PRESENCE_PROBE does not sound like quite the right thing,
> >> >> then.  But that is what is being triggered by a
> >> >> SUBSCRIBE(dialog) to that extension.  >From RFC4235:
> >> >> >
> >> >> > "The dialog package allows users to subscribe to another
> >> >> >   user and to receive notification of the changes in state
> >> >> of INVITE-
> >> >> >   initiated dialog usages in which the subscribed-to user
> >> >> is involved."
> >> >> >
> >> >> > Nothing in there about being registered or not.
> >> >> >
> >> >> > Carolyn
> >> >> >
> >> >> >> -----Original Message-----
> >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org
> >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
> >> Behalf Of
> >> >> >> Anthony Minessale
> >> >> >> Sent: Tuesday, October 12, 2010 10:30 AM
> >> >> >> To: freeswitch-dev at lists.freeswitch.org
> >> >> >> Subject: Re: [Freeswitch-dev] Dialog events
> >> >> >>
> >> >> >> The reason for this is because we don't care about any
> >> >> calls who are
> >> >> >> not registered to us.
> >> >> >> The sip_dialogs table are purely for in-call presence
> >> >> information of
> >> >> >> authenticated users.
> >> >> >>
> >> >> >> PRESENCE_PROBE is, in essence a query to see who is
> currently
> >> >> >> registered.
> >> >> >>
> >> >> >> Maybe if you describe your paradigm to me that does not
> >> >> involve any
> >> >> >> registrations, I can come up with a better answer.
> >> >> >>
> >> >> >>
> >> >> >> On Tue, Oct 12, 2010 at 9:15 AM, Beeton, Carolyn (Carolyn)
> >> >> >> <cbeeton at avaya.com> wrote:
> >> >> >> > Most of my changes are a pretty straight-forward extension
> >> >> >> to add the call-id, local-tag and remote-tag into
> the <dialog>
> >> >> >> element.  But I am blocked by the sql query in
> >> >> >> actual_sofia_presence_event_handler which pulls out the
> >> >> rows to work
> >> >> >> on in the first place (in the
> >> SWITCH_EVENT_PRESENCE_PROBE case),
> >> >> >> because it uses the sip_registrations table as the
> >> >> "master" and does
> >> >> >> a left join on sip_dialogs and sip_presence to get more
> >> >> data.  In my
> >> >> >> case, there is nothing in sip_registrations, so I get no
> >> >> matches to
> >> >> >> work on.  I realize that changing this query (or any of
> >> >> this stuff)
> >> >> >> is a risky thing  - at this point I am just feeling
> >> around to see
> >> >> >> what might be possible.
> >> >> >> >
> >> >> >> > So my main question right now is:
> >> >> >> > - is it correct to build dialog event content primarily
> >> >> >> based on the sip_registrations table?  Could the query be
> >> >> rejigged so
> >> >> >> that sip_dialogs is the master and sip_registrations is
> >> >> joined where
> >> >> >> there is a match? To me, this would seem to be correct,
> >> as dialog
> >> >> >> event contents should have little to do with registrations
> >> >> and should
> >> >> >> not be primarly driven by them.
> >> >> >> >
> >> >> >> > Carolyn
> >> >> >> >
> >> >> >> >> -----Original Message-----
> >> >> >> >> From: freeswitch-dev-bounces at lists.freeswitch.org
> >> >> >> >> [mailto:freeswitch-dev-bounces at lists.freeswitch.org] On
> >> >> Behalf Of
> >> >> >> >> Anthony Minessale
> >> >> >> >> Sent: Friday, October 08, 2010 5:32 PM
> >> >> >> >> To: freeswitch-dev at lists.freeswitch.org
> >> >> >> >> Subject: Re: [Freeswitch-dev] Dialog events
> >> >> >> >>
> >> >> >> >> anything can be accepted that keeps things working
> >> the way they
> >> >> >> >> already do work and more.
> >> >> >> >> we can probably add those other things to the dialog table
> >> >> >> as long as
> >> >> >> >> nothing breaks in the process.
> >> >> >> >>
> >> >> >> >> I am just trying to warn you that this is heavily
> >> >> >> depended-upon code
> >> >> >> >> by many and it's a critical change to manipulate it
> >> and changes
> >> >> >> >> should be discussed in detail.
> >> >> >> >>
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > FreeSWITCH-dev mailing list
> >> >> >> > FreeSWITCH-dev at lists.freeswitch.org
> >> >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> >> >> >
> >> >> >>
> >> >>
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> >> >> v
> >> >> >> > http://www.freeswitch.org
> >> >> >> >
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Anthony Minessale II
> >> >> >>
> >> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon
> >> >> http://www.cluecon.com/
> >> >> >> Twitter: http://twitter.com/FreeSWITCH_wire
> >> >> >>
> >> >> >> AIM: anthm
> >> >> >> MSN:anthony_minessale at hotmail.com
> >> >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> >> >> >> IRC: irc.freenode.net #freeswitch
> >> >> >>
> >> >> >> FreeSWITCH Developer Conference
> >> >> >> sip:888 at conference.freeswitch.org
> >> >> >> googletalk:conf+888 at conference.freeswitch.org
> >> >> >> pstn:+19193869900
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> FreeSWITCH-dev mailing list
> >> >> >> FreeSWITCH-dev at lists.freeswitch.org
> >> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> >> >>
> >> >>
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> >> >> v
> >> >> >> http://www.freeswitch.org
> >> >> >>
> >> >> > _______________________________________________
> >> >> > FreeSWITCH-dev mailing list
> >> >> > FreeSWITCH-dev at lists.freeswitch.org
> >> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> >> >
> >> >>
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> >> v
> >> >> > http://www.freeswitch.org
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Anthony Minessale II
> >> >>
> >> >> FreeSWITCH http://www.freeswitch.org/ ClueCon
> >> http://www.cluecon.com/
> >> >> Twitter: http://twitter.com/FreeSWITCH_wire
> >> >>
> >> >> AIM: anthm
> >> >> MSN:anthony_minessale at hotmail.com
> >> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> >> >> IRC: irc.freenode.net #freeswitch
> >> >>
> >> >> FreeSWITCH Developer Conference
> >> >> sip:888 at conference.freeswitch.org
> >> >> googletalk:conf+888 at conference.freeswitch.org
> >> >> pstn:+19193869900
> >> >>
> >> >> _______________________________________________
> >> >> FreeSWITCH-dev mailing list
> >> >> FreeSWITCH-dev at lists.freeswitch.org
> >> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> >>
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> >> v
> >> >> http://www.freeswitch.org
> >> >>
> >> > _______________________________________________
> >> > FreeSWITCH-dev mailing list
> >> > FreeSWITCH-dev at lists.freeswitch.org
> >> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >> >
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> v
> >> > http://www.freeswitch.org
> >> >
> >>
> >>
> >>
> >> --
> >> Anthony Minessale II
> >>
> >> FreeSWITCH http://www.freeswitch.org/ ClueCon
> http://www.cluecon.com/
> >> Twitter: http://twitter.com/FreeSWITCH_wire
> >>
> >> AIM: anthm
> >> MSN:anthony_minessale at hotmail.com
> >> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> >> IRC: irc.freenode.net #freeswitch
> >>
> >> FreeSWITCH Developer Conference
> >> sip:888 at conference.freeswitch.org
> >> googletalk:conf+888 at conference.freeswitch.org
> >> pstn:+19193869900
> >>
> >> _______________________________________________
> >> FreeSWITCH-dev mailing list
> >> FreeSWITCH-dev at lists.freeswitch.org
> >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >>
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-de
> >> v
> >> http://www.freeswitch.org
> >>
> > _______________________________________________
> > FreeSWITCH-dev mailing list
> > FreeSWITCH-dev at lists.freeswitch.org
> > http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> >
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> > http://www.freeswitch.org
> >
>
>
>
> --
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
> Twitter: http://twitter.com/FreeSWITCH_wire
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com
> IRC: irc.freenode.net #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org
> googletalk:conf+888 at conference.freeswitch.org
> pstn:+19193869900
>
> _______________________________________________
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Improve-support-of-Dialog-events.patch
Type: application/octet-stream
Size: 16434 bytes
Desc: 0001-Improve-support-of-Dialog-events.patch
Url : http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20101013/f438096e/attachment-0001.obj

More information about the FreeSWITCH-dev mailing list