[Freeswitch-dev] Dialog events

Beeton, Carolyn (Carolyn) cbeeton at avaya.com
Tue Oct 12 10:10:35 PDT 2010


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


More information about the FreeSWITCH-dev mailing list