Hi Pascal,

----- Original Message -----
> From: "Pascal Potvin" <[email protected]>
> To: [email protected]
> Cc: "Martin Larente" <[email protected]>, "Maxime Clerk-Lamalice" 
> <[email protected]>
> Sent: Monday, June 2, 2014 1:55:53 PM
> Subject: [SFLphone] daemon: dbus connection is lost after     
> invite/cancel/invite
> 
> Hi,
> 
> We are a Montreal based business that installs bedside terminals in
> hospitals. These terminals are used for entertainment and clinical
> related work. In our next iteration, these terminals will be used to
> make phone calls.
> 
> We use the sflphone daemon to make phone calls. Calls are handled
> with
> the IP2IP account.
> 
> One of the production sites where our system is deployed has a UAS
> that
> use the following sip sequence to provide CNAM information when it's
> possible:
> 
> 
>   INVITE ----------> (no CNAM)
>      100 <----------
>      180 <----------
>   CANCEL ---------->
>      200 <----------
>      487 <----------
>      ACK ---------->
>             [5ms]
>   INVITE ----------> (w/ CNAM)
>      100 <----------
>      180 <----------
>      200 <----------
>      ACK ---------->
>             [...]
>      BYE ---------->
>      200 <----------
> 
> You can see one example of it in the `sip-capture.pcapng` file.
> 
> When the second invite is received and both 100 and 180 replies are
> sent, the daemon is kicked out of the dbus session-bus. Once kicked
> out
> of the bus, sflphoned is not able to close itself properly and we
> have
> to kill it. However, sflphoned continues to answer to sip requests
> properly.
> 
> We have gathered a `dbus-monitor` log of that behaviour. You can read
> it
> in the `dbus-monitor.log` file. In this file, :1.14 represents the
> sflphone daemon and :1.13 is our software.
> 
> We've started sflphoned with the debug option, but no error is shown
> on
> screen. We have been able to reproduce this problem with sflphone
> 1.2.3
> and 1.3.0.
> 
> Have you seen this behaviour before? Do you know what we should do to
> debug this properly?

I have not seen that behaviour, I would suggest stepping through the daemon 
with gdb
and providing a backtrace when the daemon gets kicked from the session.

Best,
Tristan

> 
> Thank you for your help,
> 
> Pascal Potvin
> Software Developer
> [email protected]
> 
> Extenway Solutions Inc.
> 514-694-1916 x290
> 
> _______________________________________________
> SFLphone mailing list
> [email protected]
> http://lists.savoirfairelinux.net/mailman/listinfo/sflphone
> 

-- 

Tristan Matthews
Développeur de logiciels libres
[email protected]
Ligne directe: 514-276-5468 poste 190

Fax : 514-276-5465
7275 Saint Urbain
Bureau 200
Montréal, QC, H2R 2Y5

_______________________________________________
SFLphone mailing list
[email protected]
http://lists.savoirfairelinux.net/mailman/listinfo/sflphone

Reply via email to