On Tue, 2011-09-27 at 11:49 -0400, John A. Sullivan III wrote:
> On Tue, 2011-09-27 at 11:42 -0400, Rafaël Carré wrote:
> > On Mon, 2011-09-26 at 21:54 -0400, John A. Sullivan III wrote:
> > > On Mon, 2011-09-26 at 17:57 -0400, Rafaël Carré wrote:
> > > > On Mon, 2011-09-26 at 16:54 -0400, John A. Sullivan III wrote:
> > > > > On Tue, 2011-09-13 at 01:42 -0400, John A. Sullivan III wrote:
> > > > > > On Tue, 2011-09-13 at 00:56 -0400, John A. Sullivan III wrote:
> > > > > > > Hmm . . . now that I finally have my Debian Squeeze SFLPhone
> > > > > > > 0.9.13
> > > > > > > installation and have successfully registered to Asterisk, I am
> > > > > > > unable
> > > > > > > to place a call. All the key strokes are misinterpreted and
> > > > > > > every call
> > > > > > > says that is not a valid extension. I would not think this is a
> > > > > > > DTMF
> > > > > > > issue but I did set it to both SIP and RTP.
> > > > > > >
> > > > > > > When I dial from a different phone and observe the Asterisk
> > > > > > > console, I
> > > > > > > see Execute and the extension I've dialed. When SFLPhone dials,
> > > > > > > I see
> > > > > > > Execut and just an "s". I see no information on stdout or stderr
> > > > > > > for
> > > > > > > SFLPhone and there does not seem to be much logging. Any idea
> > > > > > > what I've
> > > > > > > done wrong? Thanks - John
> > > > > > <snip>
> > > > > > I backleveled to 0.9.9 and have the same problem. I did not have
> > > > > > this
> > > > > > problem in 0.9.8. Thanks - John
> > > > > <snip>
> > > > > With Rafael's help, I was able to build debs for 0.9.14 for Squeeze.
> > > > > However, I still have the same problem. The digits are not being sent
> > > > > to our Asterisk PBX. For example, we have an echo test at extension
> > > > > 213. Here is what happens when I dial 213 (either by number or by
> > > > > clicking on the phone pad in the application):
> > > > >
> > > > > == Extension Changed 312[a100] new state InUse for Notify User
> > > > > othersip
> > > > > -- Executing [s@a100:1] Answer("SIP/mysip-0000021c", "0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:2] Playback("SIP/mysip-0000021c",
> > > > > "im-sorry") in new stack
> > > > > -- <SIP/mysip-0000021c> Playing 'im-sorry.slin' (language 'en')
> > > > > [Sep 26 15:40:57] NOTICE[9967]: channel.c:3137 __ast_read: Dropping
> > > > > incompatible voice frame on SIP/mysip-0000021c of format g722 since
> > > > > our native format has changed to 0x200 (speex)
> > > > > -- Executing [s@a100:3] Wait("SIP/mysip-0000021c", "0.0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:4] Playback("SIP/mysip-0000021c",
> > > > > "you-dialed-wrong-number") in new stack
> > > > > -- <SIP/mysip-0000021c> Playing 'you-dialed-wrong-number.slin'
> > > > > (language 'en')
> > > > > -- Executing [s@a100:5] Wait("SIP/mysip-0000021c", "0.4") in new
> > > > > stack
> > > > > -- Executing [s@a100:6] Playback("SIP/mysip-0000021c",
> > > > > "vm-goodbye") in new stack
> > > > >
> > > > > Notice that it has dialed "s", i.e., it has fallen through the dial
> > > > > plan. I have tried DTMF via RTP (as we normally do) and via SIP. I
> > > > > did
> > > > > notice the g722 error which I thought was strange because the account
> > > > > is
> > > > > set to use speex first. So, I thought there might be a bug where it
> > > > > was
> > > > > using g722 anyway and disabled g722. Then I got:
> > > > >
> > > > > == Extension Changed 312[a100] new state InUse for Notify User
> > > > > othersip
> > > > > -- Executing [s@a100:1] Answer("SIP/mysip-00000222", "0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:2] Playback("SIP/mysip-00000222",
> > > > > "im-sorry") in new stack
> > > > > -- <SIP/mysip-00000222> Playing 'im-sorry.slin' (language 'en')
> > > > > [Sep 26 15:44:24] NOTICE[9976]: channel.c:3137 __ast_read: Dropping
> > > > > incompatible voice frame on SIP/mysip-00000222 of format ulaw since
> > > > > our native format has changed to 0x200 (speex)
> > > > > -- Executing [s@a100:3] Wait("SIP/mysip-00000222", "0.0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:4] Playback("SIP/mysip-00000222",
> > > > > "you-dialed-wrong-number") in new stack
> > > > >
> > > > > So I disabled everything but speex but still have the same problem of
> > > > > not passing the number dialed and falling through the dial plan:
> > > > >
> > > > > == Extension Changed 312[a100] new state InUse for Notify User
> > > > > othersip
> > > > > -- Executing [s@a100:1] Answer("SIP/mysip-00000223", "0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:2] Playback("SIP/mysip-00000223",
> > > > > "im-sorry") in new stack
> > > > > -- <SIP/mysip-00000223> Playing 'im-sorry.slin' (language 'en')
> > > > > -- Executing [s@a100:3] Wait("SIP/mysip-00000223", "0.0.5") in
> > > > > new stack
> > > > > -- Executing [s@a100:4] Playback("SIP/mysip-00000223",
> > > > > "you-dialed-wrong-number") in new stack
> > > > > -- <SIP/mysip-00000223> Playing 'you-dialed-wrong-number.slin'
> > > > > (language 'en')
> > > > > == Spawn extension (a100, s, 4) exited non-zero on
> > > > > 'SIP/mysip-00000223'
> > > > > -- Executing [h@a100:1] Hangup("SIP/mysip-00000223", "") in new
> > > > > stack
> > > > > == Spawn extension (a100, h, 1) exited non-zero on
> > > > > 'SIP/mysip-00000223'
> > > > >
> > > > > This is using the very latest git - pulled today just before building.
> > > > > What do we do next? Thanks - John
> > > >
> > > > Try a network capture on the computer running sflphone, with wireshark
> > > >
> > > Hello, Rafael. I think I see it. I will send you the traces privately
> > > and securely via our PassIT service. However, in comparing a successful
> > > Snom phone with SFLPhone, when the Snom sends the authorization in the
> > > final INVITE, it sets uri=sip:213@<ip address> however SFLPhone sets it
> > > to uri=sip:<ip address>. In the Snom trace I will send, it is packet
> > > 11. In the two SFLPhone traces I will send, they are packet 4. Thanks
> >
> > I see the difference in the uri= field of Authorization, however I can
> > not reproduce the problem here: my sflphone completes the field
> > correctly with sip:extension@ip
> >
> > The SIP RFC says the extension@ is optional, though in this case it
> > should probably be here.
> >
> >
> >
> > Also the authorization step succeeds anyway:
> > -> sflphone sends an invite
> > <- asterix refuses it with code 401 Unauthorized
> > -> sflphone sends an invite with Authorization field set
> > <- asterix accepts it, send a code 100 Trying
> > <- asterix establishes the connection by sending code 200 OK, with a
> > complete SDP file.
> >
> But notice the difference in the 100 trying response. In the Snom case,
> Asterisk responds with 213@<PBX> whereas in the SFLphone case, it
> responds with s@<PBX>, in other words it fell through the dial plan
> because it did not have the 213 (or so I am guessing).
Noted
> > Can you send the complete log of sflphone daemon?
> I've got to run out for a while and can get to it when I return if you
> think it is still necessary after looking at the Asterisk response I
> mentioned above. Thanks - John
Please do it because I still don't know why the uri field is not set
like it is for me.
Could you send me your ~/.config/sflphone/sflphone.yml so I can check
the SIP settings for your account? (send that in private and mask out
the password)
> >
> > kill all sflphone processes and run sflphone daemon in a terminal with:
> > /usr/lib/sflphone/sflphoned -c -d
> >
> > then start the client
_______________________________________________
SFLphone mailing list
[email protected]
http://lists.savoirfairelinux.net/mailman/listinfo/sflphone
