Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-26 Thread Anthony Minessale 
depending on your dialplan every time you bridge to a channel it changes the
display to match who you are talking to.  if you tried to set it with the
variable then you call someone that is going to cause this.  Take away the
display app and/or any special variables and let it naturally work.


On Mon, Oct 26, 2009 at 10:51 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Anthony,
>
> sorry for making you dizzy ... bun in fact in my point of view I have
> two different problems.
>
> 1.
> One concerns the way using send_display in pre_answer mode. Simply to
> send error texts to caller's display. This works again with latest trunk.
>
>
> 2.
> The other one (this thread) concerns the (in my eyes newly introduced)
> two INFO messages which FS sends to callee after callee picked up his
> phone. The first INFO switches callee's display to a name set in
> "originaton_callee_id_name" (a) and immediately after that the second
> INFO switches it back to callee's real name (b). You can see this in
> display only if (a) and (b) are not the same.
>
> I used Snom 370 phones with FW 8.2.16 as caller and callee. I did an
> internal call (sip to sip).
>
>
> Maybe this is the same code problem, but on my level they are two
> different problems, so sorry for confusing you. I hope this clears
> things up.
>
>
> On 26.10.2009 15:41, Anthony Minessale wrote:
> > Could you maybe consolidate all of your problems into 1 thread.  I am
> > getting dizzy.  You have 2 on the same subject and you say it works on
> > one and does not on the other.
> >
> > Last week we tested all of this with latest trunk and there is no longer
> > any problems of any sort with the display related stuff.
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFK5cVz4tZeNddg3dwRAt2+AJsEQuRTEhE74+XvciTXOC0+kr0tbwCfRzUf
> fgVIZwAV/IthjWwvXzRO3TA=
> =n7Sr
> -END PGP SIGNATURE-
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-26 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anthony,

sorry for making you dizzy ... bun in fact in my point of view I have
two different problems.

1.
One concerns the way using send_display in pre_answer mode. Simply to
send error texts to caller's display. This works again with latest trunk.


2.
The other one (this thread) concerns the (in my eyes newly introduced)
two INFO messages which FS sends to callee after callee picked up his
phone. The first INFO switches callee's display to a name set in
"originaton_callee_id_name" (a) and immediately after that the second
INFO switches it back to callee's real name (b). You can see this in
display only if (a) and (b) are not the same.

I used Snom 370 phones with FW 8.2.16 as caller and callee. I did an
internal call (sip to sip).


Maybe this is the same code problem, but on my level they are two
different problems, so sorry for confusing you. I hope this clears
things up.


On 26.10.2009 15:41, Anthony Minessale wrote:
> Could you maybe consolidate all of your problems into 1 thread.  I am
> getting dizzy.  You have 2 on the same subject and you say it works on
> one and does not on the other.
> 
> Last week we tested all of this with latest trunk and there is no longer
> any problems of any sort with the display related stuff.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK5cVz4tZeNddg3dwRAt2+AJsEQuRTEhE74+XvciTXOC0+kr0tbwCfRzUf
fgVIZwAV/IthjWwvXzRO3TA=
=n7Sr
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-26 Thread Anthony Minessale 
Could you maybe consolidate all of your problems into 1 thread.  I am
getting dizzy.  You have 2 on the same subject and you say it works on one
and does not on the other.

Last week we tested all of this with latest trunk and there is no longer any
problems of any sort with the display related stuff.


On Mon, Oct 26, 2009 at 6:00 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Anthony,
>
> hm, no not really. There is no change in this behaviour in "FreeSWITCH
> Version 1.0.trunk (15225M)"
>
>
> There is still a caller name change in callee's display.
>
> I'm not sure who is wrong here. Either FS or Snom ...
>
>
> regards
> Helmut
>
>
> On 23.10.2009 17:51, Anthony Minessale wrote:
> > should be even better in 15210
> >
> >
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFK5YE94tZeNddg3dwRAigrAJ0chk/kiDQo2Z6yFbjpJovmPor46ACfValq
> u9RajDfF0rNdzkaUOVjULmk=
> =697e
> -END PGP SIGNATURE-
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-26 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anthony,

hm, no not really. There is no change in this behaviour in "FreeSWITCH
Version 1.0.trunk (15225M)"


There is still a caller name change in callee's display.

I'm not sure who is wrong here. Either FS or Snom ...


regards
Helmut


On 23.10.2009 17:51, Anthony Minessale wrote:
> should be even better in 15210
> 
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK5YE94tZeNddg3dwRAigrAJ0chk/kiDQo2Z6yFbjpJovmPor46ACfValq
u9RajDfF0rNdzkaUOVjULmk=
=697e
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-23 Thread Anthony Minessale 
should be even better in 15210


On Fri, Oct 23, 2009 at 6:35 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Anthony,
>
> thanks! The "unknown" thing is gone as long as you don't use
> "originate_callee_id_name"
>
>
> The "originate_callee_id_name" chvar causes caller's AND callee's
> display ("caller name" line)to be updated with the content of that chvar
> as soon as you set it.
>
> Let's say you use "hubu" as originate_callee_id_name. As soon as callee
> has picked up the phone it's display ("caller name" line) is updated
> with "hubu" and right after that with caller's name. The caller's
> display ("callee name" line) is updated to "hubu" (as expected).
>
> So it's still not nice to see a name switch in callee's display for
> caller's name after picking up.
>
> In the following you see the SIP flows from
>
> a) caller to FS
> b) FS to callee
>
>
> The more interesting one is b) I guess
>
>
>
>
> ###
> This is the sip flow from caller to FS, which is OK:
>
>
>
> INVITE sip:1...@85.16.246.12:5061;user=phone SIP/2.0
> 23/Oct/2009-13:26:44.730
>
> INVITE sip:1...@85.16.246.12:5061;user=phone SIP/2.0
> Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport
> From: "1001 an PBX1" ;tag=724ehd063s
> To: 
> Call-ID: 3c32462e758f-y19kuulwdknf
> CSeq: 1 INVITE
> Max-Forwards: 70
> Contact: ;reg-id=1
> X-Serialnumber: 0004134002CB
> P-Key-Flags: resolution="31x13", keys="4"
> User-Agent: snom820/8.2.16
> Accept: application/sdp
> Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
> PRACK, MESSAGE, INFO, UPDATE
> Allow-Events: talk, hold, refer, call-info
> Supported: timer, 100rel, replaces, from-change
> Session-Expires: 3600;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 734
>
> v=0
> o=root 1420196469 1420196469 IN IP4 85.16.245.206
> s=call
> c=IN IP4 85.16.245.206
> t=0 0
> m=audio 51286 RTP/SAVP 0 8 9 99 3 18 4 101
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:CjdPN1m2iLKAyXrQ2pWkQfCMtiISlF94ItTdsDis
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> a=sendrecv
> m=audio 51286 RTP/AVP 0 8 9 99 3 18 4 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-ev
>
> SIP/2.0 100 Trying
> 23/Oct/2009-13:26:44.731
>
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
> From: "1001 an PBX1" ;tag=724ehd063s
> To: 
> Call-ID: 3c32462e758f-y19kuulwdknf
> CSeq: 1 INVITE
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
> Content-Length: 0
>
>
> SIP/2.0 180 Ringing
> 23/Oct/2009-13:26:45.3
>
> SIP/2.0 180 Ringing
> Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
> From: "1001 an PBX1" ;tag=724ehd063s
> To: ;tag=QD9eD62NH0gQj
> Call-ID: 3c32462e758f-y19kuulwdknf
> CSeq: 1 INVITE
> Contact: 
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
> Accept: application/sdp
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
> REFER, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Allow-Events: talk, presence, dialog, call-info, sla,
> include-session-description, presence.winfo, message-summary, refer
> Content-Length: 0
> X-FS-Display-Name: hubu
> X-FS-Display-Number:
> X-FS-Support: update_display
>
>
> SIP/2.0 200 OK
> 23/Oct/2009-13:26:47.367
>
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
> From: "1001 an PBX1" ;tag=724ehd063s
> To: ;tag=QD9eD62NH0gQj
> Call-ID: 3c32462e758f-y19kuulwdknf
> CSeq: 1 INVITE
> Contact: 
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
> REFER, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Allow-Events: talk, presence, dialog, call-info, sla,
> include-session-description, presence.winfo, message-summary, refer
> Session-Expires: 3600;refresher=uas
> Min-SE: 120
> Content-Type: application/sdp
> Content-Disposition: session
> Content-Length: 354
> X-FS-Display-Name: hubu
> X-FS-Display-Number:
> X-FS-Support: update_display
>
> v=0
> o=FreeSWITCH 1256285701 1256285702 IN IP4 85.16.246.12
> s=FreeSWITCH
> c=IN IP4 85.16.246.12
> t=0 0
> m=audio 11506 RTP/SAVP 8 101
> a=rtpmap:8 pcma/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> a=ptime:20
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:/BFm/LUmDBuao0wqg6MS/l4acfzOHoHRFQr3N0R9
> m=audio 0 RTP/AVP 19
>
> ACK sip:1...@85.16.246.12:5061;transport=udp SIP/2.0
> 23/Oct/2009-13:26:47.392
>
> ACK sip:1...@85.16.246.12:5061;transport=udp SIP/2.0
> Via: SIP/2.0/UDP 85.16.245.206:1024;b

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-23 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anthony,

thanks! The "unknown" thing is gone as long as you don't use
"originate_callee_id_name"


The "originate_callee_id_name" chvar causes caller's AND callee's
display ("caller name" line)to be updated with the content of that chvar
as soon as you set it.

Let's say you use "hubu" as originate_callee_id_name. As soon as callee
has picked up the phone it's display ("caller name" line) is updated
with "hubu" and right after that with caller's name. The caller's
display ("callee name" line) is updated to "hubu" (as expected).

So it's still not nice to see a name switch in callee's display for
caller's name after picking up.

In the following you see the SIP flows from

a) caller to FS
b) FS to callee


The more interesting one is b) I guess




###
This is the sip flow from caller to FS, which is OK:



INVITE sip:1...@85.16.246.12:5061;user=phone SIP/2.0
23/Oct/2009-13:26:44.730

INVITE sip:1...@85.16.246.12:5061;user=phone SIP/2.0
Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport
From: "1001 an PBX1" ;tag=724ehd063s
To: 
Call-ID: 3c32462e758f-y19kuulwdknf
CSeq: 1 INVITE
Max-Forwards: 70
Contact: ;reg-id=1
X-Serialnumber: 0004134002CB
P-Key-Flags: resolution="31x13", keys="4"
User-Agent: snom820/8.2.16
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600;refresher=uas
Min-SE: 90
Content-Type: application/sdp
Content-Length: 734

v=0
o=root 1420196469 1420196469 IN IP4 85.16.245.206
s=call
c=IN IP4 85.16.245.206
t=0 0
m=audio 51286 RTP/SAVP 0 8 9 99 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:CjdPN1m2iLKAyXrQ2pWkQfCMtiISlF94ItTdsDis
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
m=audio 51286 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-ev

SIP/2.0 100 Trying
23/Oct/2009-13:26:44.731

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
From: "1001 an PBX1" ;tag=724ehd063s
To: 
Call-ID: 3c32462e758f-y19kuulwdknf
CSeq: 1 INVITE
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
Content-Length: 0


SIP/2.0 180 Ringing
23/Oct/2009-13:26:45.3

SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
From: "1001 an PBX1" ;tag=724ehd063s
To: ;tag=QD9eD62NH0gQj
Call-ID: 3c32462e758f-y19kuulwdknf
CSeq: 1 INVITE
Contact: 
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Content-Length: 0
X-FS-Display-Name: hubu
X-FS-Display-Number:
X-FS-Support: update_display


SIP/2.0 200 OK
23/Oct/2009-13:26:47.367

SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-zdcpisfjx11n;rport=1024
From: "1001 an PBX1" ;tag=724ehd063s
To: ;tag=QD9eD62NH0gQj
Call-ID: 3c32462e758f-y19kuulwdknf
CSeq: 1 INVITE
Contact: 
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15203M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Allow-Events: talk, presence, dialog, call-info, sla,
include-session-description, presence.winfo, message-summary, refer
Session-Expires: 3600;refresher=uas
Min-SE: 120
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 354
X-FS-Display-Name: hubu
X-FS-Display-Number:
X-FS-Support: update_display

v=0
o=FreeSWITCH 1256285701 1256285702 IN IP4 85.16.246.12
s=FreeSWITCH
c=IN IP4 85.16.246.12
t=0 0
m=audio 11506 RTP/SAVP 8 101
a=rtpmap:8 pcma/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:/BFm/LUmDBuao0wqg6MS/l4acfzOHoHRFQr3N0R9
m=audio 0 RTP/AVP 19

ACK sip:1...@85.16.246.12:5061;transport=udp SIP/2.0
23/Oct/2009-13:26:47.392

ACK sip:1...@85.16.246.12:5061;transport=udp SIP/2.0
Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-d474to81d7gh;rport
From: "1001 an PBX1" ;tag=724ehd063s
To: ;tag=QD9eD62NH0gQj
Call-ID: 3c32462e758f-y19kuulwdknf
CSeq: 1 ACK
Max-Forwards: 70
Contact: ;reg-id=1
Content-Length: 0


INFO sip:1...@85.16.245.206:1024;line=eg3wp69a SIP/2.0
23/Oct/2009-13:26:47.416

INFO sip:1...@85.16.245.206:1024;line=eg3wp69a SIP/2.0
Via: SIP/2.0/UDP 85.16.246.12:5061;rport;branch=z9hG4bKB244eKZ08Uj3

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-22 Thread Anthony Minessale 
I'm sure that problem is gone in svn trunk.


On Thu, Oct 22, 2009 at 11:25 AM, Brian West  wrote:

> I can't get what exactly you re talking about. Can you clarify ? Also
> please include the packets of interest only not the full trace if its
> not relevant to the bug.
>
> /b
>
> On Oct 22, 2009, at 10:44 AM, Helmut Kuper wrote:
>
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Hi Mike,
> >
> > here it is:
> >
> >
> > Dialplan:
> >
> >
> >
> >  
> >
> >
> >
> >
> > > data="user/${dialed_extensi...@${domain_name}"/>
> >  
> >
> >
>
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-22 Thread Brian West 
I can't get what exactly you re talking about. Can you clarify ? Also  
please include the packets of interest only not the full trace if its  
not relevant to the bug.

/b

On Oct 22, 2009, at 10:44 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Mike,
>
> here it is:
>
>
> Dialplan:
>
>
>
>  
>
>
>
>
> data="user/${dialed_extensi...@${domain_name}"/>
>  
>
>


___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-22 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Mike,

here it is:


Dialplan:



  





  







Debug-Log:


recv 1521 bytes from udp/[85.16.245.206]:1024 at 15:41:02.405834:
   
   INVITE sip:1...@85.16.246.12:5061;user=phone SIP/2.0
   Via: SIP/2.0/UDP 85.16.245.206:1024;branch=z9hG4bK-i48n75d62qts;rport
   From: "1001 an PBX1" ;tag=7xpim4o1go
   To: 
   Call-ID: 3c31304b7a80-no9xsnjj0bol
   CSeq: 1 INVITE
   Max-Forwards: 70
   Contact: ;reg-id=1
   X-Serialnumber: 0004134002CB
   P-Key-Flags: resolution="31x13", keys="4"
   User-Agent: snom820/8.2.16
   Accept: application/sdp
   Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE,
PRACK, MESSAGE, INFO, UPDATE
   Allow-Events: talk, hold, refer, call-info
   Supported: timer, 100rel, replaces, from-change
   Session-Expires: 3600;refresher=uas
   Min-SE: 90
   Content-Type: application/sdp
   Content-Length: 732

   v=0
   o=root 411395140 411395140 IN IP4 85.16.245.206
   s=call
   c=IN IP4 85.16.245.206
   t=0 0
   m=audio 49852 RTP/SAVP 0 8 9 99 3 18 4 101
   a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:Um06txYC7vwXdZDohXJ15te5hZ/iWmPd4voRbdby
   a=rtpmap:0 pcmu/8000
   a=rtpmap:8 pcma/8000
   a=rtpmap:9 g722/8000
   a=rtpmap:99 g726-32/8000
   a=rtpmap:3 gsm/8000
   a=rtpmap:18 g729/8000
   a=rtpmap:4 g723/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:20
   a=sendrecv
   m=audio 49852 RTP/AVP 0 8 9 99 3 18 4 101
   a=rtpmap:0 pcmu/8000
   a=rtpmap:8 pcma/8000
   a=rtpmap:9 g722/8000
   a=rtpmap:99 g726-32/8000
   a=rtpmap:3 gsm/8000
   a=rtpmap:18 g729/8000
   a=rtpmap:4 g723/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:20
   a=sendrecv
   
send 331 bytes to udp/[85.16.245.206]:1024 at 15:41:02.406500:
   
   SIP/2.0 100 Trying
   Via: SIP/2.0/UDP
85.16.245.206:1024;branch=z9hG4bK-i48n75d62qts;rport=1024
   From: "1001 an PBX1" ;tag=7xpim4o1go
   To: 
   Call-ID: 3c31304b7a80-no9xsnjj0bol
   CSeq: 1 INVITE
   User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15180M
   Content-Length: 0

   
2009-10-22 17:41:02.406509 [DEBUG] sofia.c:4907 IP 85.16.245.206
Approved by acl "clients[]". Access Granted.
2009-10-22 17:41:02.406509 [NOTICE] switch_channel.c:613 New Channel
sofia/internal/1...@85.16.246.12:5061 [4d941750-bf21-11de-9c3f-adfc1789590a]
2009-10-22 17:41:02.407509 [DEBUG] sofia.c:3493 Channel
sofia/internal/1...@85.16.246.12:5061 entering state [received][100]
2009-10-22 17:41:02.407509 [DEBUG] sofia.c:3500 Remote SDP:
v=0
o=root 411395140 411395140 IN IP4 85.16.245.206
s=call
c=IN IP4 85.16.245.206
t=0 0
m=audio 49852 RTP/SAVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:Um06txYC7vwXdZDohXJ15te5hZ/iWmPd4voRbdby
a=ptime:20
m=audio 49852 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

2009-10-22 17:41:02.407509 [DEBUG] sofia.c:3621
(sofia/internal/1...@85.16.246.12:5061) State Change CS_NEW -> CS_INIT
2009-10-22 17:41:02.407509 [DEBUG] switch_core_session.c:977 Send signal
sofia/internal/1...@85.16.246.12:5061 [BREAK]
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:306
(sofia/internal/1...@85.16.246.12:5061) Running State Change CS_INIT
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:330
(sofia/internal/1...@85.16.246.12:5061) State INIT
2009-10-22 17:41:02.407509 [DEBUG] mod_sofia.c:83
sofia/internal/1...@85.16.246.12:5061 SOFIA INIT
2009-10-22 17:41:02.407509 [DEBUG] mod_sofia.c:111
(sofia/internal/1...@85.16.246.12:5061) State Change CS_INIT -> CS_ROUTING
2009-10-22 17:41:02.407509 [DEBUG] switch_core_session.c:977 Send signal
sofia/internal/1...@85.16.246.12:5061 [BREAK]
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:330
(sofia/internal/1...@85.16.246.12:5061) State INIT going to sleep
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:306
(sofia/internal/1...@85.16.246.12:5061) Running State Change CS_ROUTING
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:333
(sofia/internal/1...@85.16.246.12:5061) State ROUTING
2009-10-22 17:41:02.407509 [DEBUG] mod_sofia.c:130
sofia/internal/1...@85.16.246.12:5061 SOFIA ROUTING
2009-10-22 17:41:02.407509 [DEBUG] switch_core_state_machine.c:78
sofia/internal/1...@85.16.246.12:5061 Standard ROUTING
2009-10-22 17:41:02.407509 [INFO]

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-21 Thread Michael Collins 
On Wed, Oct 21, 2009 at 10:43 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Mike,
>
> just updated my prod system. The "1/a/" problem is solved with Anthony's
> "originate_callee_id_name" chvar.
>
> thanks alot :)
>
> So, last thing of this thread is still the "unknown" thing on callee's
> display, which is (by now) NOT affected by the new chvars.
>
Okay, you are able to reproduce that "unknown" thing? Can you pastebin a
fresh debug log w/ SIP trace on, plus and relevant dp changes from the
default dialplan?
Thanks,
MC
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-21 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Mike,

just updated my prod system. The "1/a/" problem is solved with Anthony's
"originate_callee_id_name" chvar.

thanks alot :)

So, last thing of this thread is still the "unknown" thing on callee's
display, which is (by now) NOT affected by the new chvars.

regards
Helmut


On 19.10.2009 23:35, Michael Collins wrote:
> 
> 
> On Mon, Oct 19, 2009 at 1:07 PM, Anthony Minessale
> mailto:anthony.miness...@gmail.com>> wrote:
> 
> please update and test trunk
> 
> 1) I changed the core to remove the excess data by default in your
> scenario
> 2) I added variables you can use to control it
> origination_callee_id_name origination_callee_id_number which belong
> in {} in the dial string eg
> {origination_callee_id_number=1234}openzap/1/a/1234
> 
> 
> After you test, please confirm the behavior and then we'll update the
> wiki on these two new chan vars.
> -MC
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK30g74tZeNddg3dwRAjaGAKDDNnxPPg+lmlCSs33MCw/V191q3ACdFlpv
Alf3NeoCA8Qbm2PZ1k2HHOg=
=hzVn
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-21 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Brian, hi Mike,

On 20.10.2009 18:41, Brian West wrote:
> Or just set the var to what you want it to say?

Yes, understood and it works so far. This means that I must enhance my
dialplan to set this new variable to preserve old behaviour. No big
deal, but at least I have to know it.

> 
> /b
> 
> On Oct 20, 2009, at 11:19 AM, Michael Collins wrote:
> 
>>
>> Under what conditions did you see "unknown"? I'm wondering if the  
>> user can just pick a default other than "unknown" if he wants  
>> something else to be displayed.

I get it for internal calls from Snom to Snom. It seems to be the
default configuration. The sip flow shows two INFO messages sent from FS
to caller after callee picked up. The first INFO messages set the
callee's name to "unknown" on caller's side. The second changed it back
to callee's number.

Maybe there is a plan behind it ... by now it is simply increasing the
sip signalling load.

Any ideas for what the first INFO message is?

regards
helmut
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK3sXF4tZeNddg3dwRAshzAJ99Jsp/RNtndeulae80pvHPqC9YHACghFxT
y0JZzsSKrGyPXTnPypy+qqQ=
=jNtK
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-20 Thread Brian West 
Or just set the var to what you want it to say?

/b

On Oct 20, 2009, at 11:19 AM, Michael Collins wrote:

>
> Under what conditions did you see "unknown"? I'm wondering if the  
> user can just pick a default other than "unknown" if he wants  
> something else to be displayed.
>
> Thoughts?
> -MC


___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-20 Thread Michael Collins 
On Tue, Oct 20, 2009 at 12:25 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Anthony,
>
>
> On 19.10.2009 22:07, Anthony Minessale wrote:
> > please update and test trunk
> >
> > 1) I changed the core to remove the excess data by default in your
> scenario
> > 2) I added variables you can use to control it
> > origination_callee_id_name origination_callee_id_number which belong in
> > {} in the dial string eg
> {origination_callee_id_number=1234}openzap/1/a/1234
>
> updated and testet for SIP calls. "origination_callee_id_number=1234"
> works within the dial string and via using "export" application but not
> via "set" application. Didn't test it for openzap, yet but I guess it
> will work, too.
>

Thanks for testing. BTW, according to Tony's instructions the user needs to
put the variable definition inside the {} of the dialstring. This means that
the vars are designed for the new leg, not the local leg, which means that
"export" would work but "set" would not. (Remember, "set" is to set a chan
var on the local channel, "export" will set a chan var locally *and* on the
other call leg. See also the "nolocal" option of export.)

>
> What left is that "unknown" thing on callee's display (SIP phones only I
> guess) ... I would suggest to make sending "unknown" INFO message
> optional, but to be honest, I have no idea for what it was invented, so
> maybe my suggestion is nonsens.
>
>
Under what conditions did you see "unknown"? I'm wondering if the user can
just pick a default other than "unknown" if he wants something else to be
displayed.

Thoughts?
-MC
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-20 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Anthony,


On 19.10.2009 22:07, Anthony Minessale wrote:
> please update and test trunk
> 
> 1) I changed the core to remove the excess data by default in your scenario
> 2) I added variables you can use to control it
> origination_callee_id_name origination_callee_id_number which belong in
> {} in the dial string eg {origination_callee_id_number=1234}openzap/1/a/1234

updated and testet for SIP calls. "origination_callee_id_number=1234"
works within the dial string and via using "export" application but not
via "set" application. Didn't test it for openzap, yet but I guess it
will work, too.

What left is that "unknown" thing on callee's display (SIP phones only I
guess) ... I would suggest to make sending "unknown" INFO message
optional, but to be honest, I have no idea for what it was invented, so
maybe my suggestion is nonsens.


regards
Helmut
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK3WXZ4tZeNddg3dwRAs9eAJ4+ZtjNYmt/U9fK3o2LnsO7Ztf/ygCgp+c4
eZWafXUZn3LjC07q/1IcsvM=
=7N8O
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Michael Collins 
On Mon, Oct 19, 2009 at 1:07 PM, Anthony Minessale <
anthony.miness...@gmail.com> wrote:

> please update and test trunk
>
> 1) I changed the core to remove the excess data by default in your scenario
> 2) I added variables you can use to control it origination_callee_id_name
> origination_callee_id_number which belong in {} in the dial string eg
> {origination_callee_id_number=1234}openzap/1/a/1234
>
>
> After you test, please confirm the behavior and then we'll update the wiki
on these two new chan vars.
-MC
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Anthony Minessale 
please update and test trunk

1) I changed the core to remove the excess data by default in your scenario
2) I added variables you can use to control it origination_callee_id_name
origination_callee_id_number which belong in {} in the dial string eg
{origination_callee_id_number=1234}openzap/1/a/1234


On Mon, Oct 19, 2009 at 10:53 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi Anthony,
>
> just to make it clear: my goal is to avoid to see something (newly
> introduced since 1 or 2 weeks) like "1/a/890327" for outgoing in the
> caller's display after answering the call (for openzap calls). I want
> simply e.g. "89327". I don't want to put the call into "answer" state
> before the called side demands it. So I'm not sure if sip_callee_* is
> the right way to follow as long as it needs the answer state.
>
> regards
> helmut
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFK3Itu4tZeNddg3dwRAvREAKCrZcRM+TnypdVOczpe2+q26b3BYQCfadrY
> tdA2XIc/hpuIv/916eu4GFo=
> =y6Md
> -END PGP SIGNATURE-
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Anthony,

just to make it clear: my goal is to avoid to see something (newly
introduced since 1 or 2 weeks) like "1/a/890327" for outgoing in the
caller's display after answering the call (for openzap calls). I want
simply e.g. "89327". I don't want to put the call into "answer" state
before the called side demands it. So I'm not sure if sip_callee_* is
the right way to follow as long as it needs the answer state.

regards
helmut


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK3Itu4tZeNddg3dwRAvREAKCrZcRM+TnypdVOczpe2+q26b3BYQCfadrY
tdA2XIc/hpuIv/916eu4GFo=
=y6Md
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

well, when I add "answer" before I bridge, there is a small change:
There is no INFO message with "unknown" send to callee.

The caller's display isn't affected by "sip_callee_*" chvars.



On 19.10.2009 17:00, Anthony Minessale wrote:
> you only need to "set" it on the inbound leg and you must answer and
> bridge it somewhere.

My current dialplan is this:


  















  




Here is the complete debug log:



2009-10-19 17:27:20.559060 [DEBUG] sofia.c:4906 IP 85.16.245.206
Approved by acl "clients[]". Access Granted.
2009-10-19 17:27:20.560087 [NOTICE] switch_channel.c:613 New Channel
sofia/internal/1...@85.16.246.12:5061 [e47af3a6-bcc3-11de-9f91-c9cd82739033]
2009-10-19 17:27:20.560087 [DEBUG] sofia.c:3492 Channel
sofia/internal/1...@85.16.246.12:5061 entering state [received][100]
2009-10-19 17:27:20.560087 [DEBUG] sofia.c:3499 Remote SDP:
v=0
o=root 90206 90206 IN IP4 85.16.245.206
s=call
c=IN IP4 85.16.245.206
t=0 0
m=audio 54598 RTP/SAVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:zS0VqvwW7z/dnmeWvtZS0AwhJ1ru1J1tuHJO2JRD
a=ptime:20
m=audio 54598 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20

2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:306
(sofia/internal/1...@85.16.246.12:5061) Running State Change CS_NEW
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:312
(sofia/internal/1...@85.16.246.12:5061) State NEW
2009-10-19 17:27:20.560087 [DEBUG] sofia.c:3620
(sofia/internal/1...@85.16.246.12:5061) State Change CS_NEW -> CS_INIT
2009-10-19 17:27:20.560087 [DEBUG] switch_core_session.c:969 Send signal
sofia/internal/1...@85.16.246.12:5061 [BREAK]
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:306
(sofia/internal/1...@85.16.246.12:5061) Running State Change CS_INIT
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:330
(sofia/internal/1...@85.16.246.12:5061) State INIT
2009-10-19 17:27:20.560087 [DEBUG] mod_sofia.c:83
sofia/internal/1...@85.16.246.12:5061 SOFIA INIT
2009-10-19 17:27:20.560087 [DEBUG] mod_sofia.c:111
(sofia/internal/1...@85.16.246.12:5061) State Change CS_INIT -> CS_ROUTING
2009-10-19 17:27:20.560087 [DEBUG] switch_core_session.c:969 Send signal
sofia/internal/1...@85.16.246.12:5061 [BREAK]
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:330
(sofia/internal/1...@85.16.246.12:5061) State INIT going to sleep
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:306
(sofia/internal/1...@85.16.246.12:5061) Running State Change CS_ROUTING
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:333
(sofia/internal/1...@85.16.246.12:5061) State ROUTING
2009-10-19 17:27:20.560087 [DEBUG] mod_sofia.c:130
sofia/internal/1...@85.16.246.12:5061 SOFIA ROUTING
2009-10-19 17:27:20.560087 [DEBUG] switch_core_state_machine.c:78
sofia/internal/1...@85.16.246.12:5061 Standard ROUTING
2009-10-19 17:27:20.560087 [INFO] mod_dialplan_xml.c:391 Processing 1001
an PBX1->1000 in context default
Dialplan: sofia/internal/1...@85.16.246.12:5061 parsing
[default->anonymous] continue=true
Dialplan: sofia/internal/1...@85.16.246.12:5061 Regex (FAIL) [anonymous]
destination_number(1000) =~ /^\*31([0-9]+)$/ break=never
Dialplan: sofia/internal/1...@85.16.246.12:5061 ANTI-Action
set(dialed_extension=${destination_number})
Dialplan: sofia/internal/1...@85.16.246.12:5061 parsing
[default->is_local] continue=true
Dialplan: sofia/internal/1...@85.16.246.12:5061 Regex (FAIL) [is_local]
${ET_is_local}() =~ /(true|false)/ break=on-true
Dialplan: sofia/internal/1...@85.16.246.12:5061 ANTI-Action
lua(ET_is_local.lua)
Dialplan: sofia/internal/1...@85.16.246.12:5061 ANTI-Action
transfer(${destination_number} XML default)
Dialplan: sofia/internal/1...@85.16.246.12:5061 parsing
[default->set_domain] continue=true
Dialplan: sofia/internal/1...@85.16.246.12:5061 Regex (PASS)
[set_domain] destination_number(1000) =~ /^.*$/ break=on-false
Dialplan: sofia/internal/1...@85.16.246.12:5061 Action
set(domain_name=85.16.246.12)
Dialplan: sofia/internal/1...@85.16.246.12:5061 parsing
[default->302_zero_problem] continue=true
Dialplan: sofia/internal/1...@85.16.246.12:5061 Regex (FAIL)
[302_zero_problem] ${sip_looped_call}() =~ /true/ break=on-false
Dialplan: sofia/internal/1...@85.16.246.12:5061 parsing
[default->fakeTrisko-Servicenumber as callerid] continue=true
Dialplan: sofia/internal/1...@85.16.246.12:5061 Regex (FAIL)
[fakeTrisko-Servicenumber as callerid] calle

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Anthony Minessale 
you only need to "set" it on the inbound leg and you must answer and bridge
it somewhere.


On Mon, Oct 19, 2009 at 9:47 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello Anthony,
>
> I updated and restarted my test FS to "FreeSWITCH Version 1.0.trunk
> (15174M)". Callee's experience didn't change:
>
> > 1. Phone rings: caller's displayname
> > 2. Callee picks up: switching from dislayname to unknown
> > 3. Switching from unknown to displayname
>
> I used the two chvars you mentioned, set them via "set" and as well via
> "export" but no change (neither on caller's nor in callee's display nor
> in SIP INFO messages)
>
>
> My dialplan portion for this is:
>
>  
> data="dialed_extension=${destination_number}"/>
>
>
>
>
>
> [...]
>
>
> Here is the output of the info app after setting those chvars:
>
> [INFO] mod_dptools.c:961 CHANNEL_DATA:
> Channel-State: [CS_EXECUTE]
> Channel-State-Number: [4]
> Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
> Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
> Call-Direction: [inbound]
> Presence-Call-Direction: [inbound]
> Answer-State: [ringing]
> Caller-Username: [1001]
> Caller-Dialplan: [XML]
> Caller-Caller-ID-Name: [1001 an PBX1]
> Caller-Caller-ID-Number: [1001]
> Caller-Network-Addr: [85.16.245.206]
> Caller-Destination-Number: [1000]
> Caller-Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
> Caller-Source: [mod_sofia]
> Caller-Context: [default]
> Caller-RDNIS: [1000]
> Caller-Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
> Caller-Profile-Index: [2]
> Caller-Profile-Created-Time: [1255963206242587]
> Caller-Channel-Created-Time: [1255963206214959]
> Caller-Channel-Answered-Time: [0]
> Caller-Channel-Progress-Time: [0]
> Caller-Channel-Progress-Media-Time: [0]
> Caller-Channel-Hangup-Time: [0]
> Caller-Channel-Transfer-Time: [0]
> Caller-Screen-Bit: [true]
> Caller-Privacy-Hide-Name: [false]
> Caller-Privacy-Hide-Number: [false]
> variable_sip_received_ip: [85.16.245.206]
> variable_sip_received_port: [1024]
> variable_sip_via_protocol: [udp]
> variable_sip_authorized: [true]
> variable_sip_from_user: [1001]
> variable_sip_from_port: [5061]
> variable_sip_from_uri: [1...@85.16.246.12:5061]
> variable_sip_from_host: [85.16.246.12]
> variable_sip_from_user_stripped: [1001]
> variable_sip_from_tag: [snfuiue6ga]
> variable_sofia_profile_name: [internal]
> variable_sip_req_params: [user=phone]
> variable_sip_req_user: [1000]
> variable_sip_req_port: [5061]
> variable_sip_req_uri: [1...@85.16.246.12:5061]
> variable_sip_req_host: [85.16.246.12]
> variable_sip_to_params: [user=phone]
> variable_sip_to_user: [1000]
> variable_sip_to_port: [5061]
> variable_sip_to_uri: [1...@85.16.246.12:5061]
> variable_sip_to_host: [85.16.246.12]
> variable_sip_contact_params: [line=eg3wp69a]
> variable_sip_contact_user: [1001]
> variable_sip_contact_port: [1024]
> variable_sip_contact_uri: [1...@85.16.245.206:1024]
> variable_sip_contact_host: [85.16.245.206]
> variable_channel_name: [sofia/internal/1...@85.16.246.12:5061]
> variable_sip_call_id: [3c2d2d8f9a49-edzr2i2iezjp]
> variable_sip_user_agent: [snom820/8.2.16]
> variable_sip_via_host: [85.16.245.206]
> variable_sip_via_port: [1024]
> variable_sip_via_rport: [1024]
> variable_presence_id: [1...@85.16.246.12]
> variable_sip_h_X-Serialnumber: [0004134002CB]
> variable_sip_h_P-Key-Flags: [resolution="31x13", keys="4"]
> variable_switch_r_sdp: [v=0
> o=root 1331667919 1331667919 IN IP4 85.16.245.206
> s=call
> c=IN IP4 85.16.245.206
> t=0 0
> m=audio 62882 RTP/SAVP 0 8 9 99 3 18 4 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:m6fas/KsLF57r9RnU7X0WEWeJw9Y6+a66YUIf9Dc
> a=ptime:20
> m=audio 62882 RTP/AVP 0 8 9 99 3 18 4 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> ]
> variable_ep_codec_string: [g...@8000h@20i,p...@8000h@20i]
> variable_endpoint_disposition: [DELAYED NEGOTIATION]
> variable_ET_is_local: [true]
> variable_max_forwards: [69]
> variable_domain_name: [85.16.246.12]
> variable_dialed_extension: [1000]
> variable_sip_callee_id_number: []
> variable_sip_callee_id_name: [hubu]
> variable_export_vars: [sip_callee_id_number,sip_callee_id_name]
> variable_current_application: [info]
>
>
> On 16.10.2009 18:18, Anthony Minessale wrote:
> > 1) you should update again there were a few issues.
> > 2) you can set the variable sip_callee_id_name and sip_callee_id number
> > on the inbound leg before you answer to control what it says.
>
> regards
> Helmut
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Tristan Mahé 
Hi Helmut,

Just to add my 2 cents to the discussion, I have the same behaviour there...

Regards,

Gled.

Helmut Kuper a écrit :
> Hello Anthony,
>
> I updated and restarted my test FS to "FreeSWITCH Version 1.0.trunk
> (15174M)". Callee's experience didn't change:
>
> > 1. Phone rings: caller's displayname
> > 2. Callee picks up: switching from dislayname to unknown
> > 3. Switching from unknown to displayname
>
> I used the two chvars you mentioned, set them via "set" and as well via
> "export" but no change (neither on caller's nor in callee's display nor
> in SIP INFO messages)
>
>
> My dialplan portion for this is:
> 
>   
>  data="dialed_extension=${destination_number}"/>
> 
> 
> 
> 
> 
> [...]
>
>
> Here is the output of the info app after setting those chvars:
>
> [INFO] mod_dptools.c:961 CHANNEL_DATA:
> Channel-State: [CS_EXECUTE]
> Channel-State-Number: [4]
> Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
> Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
> Call-Direction: [inbound]
> Presence-Call-Direction: [inbound]
> Answer-State: [ringing]
> Caller-Username: [1001]
> Caller-Dialplan: [XML]
> Caller-Caller-ID-Name: [1001 an PBX1]
> Caller-Caller-ID-Number: [1001]
> Caller-Network-Addr: [85.16.245.206]
> Caller-Destination-Number: [1000]
> Caller-Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
> Caller-Source: [mod_sofia]
> Caller-Context: [default]
> Caller-RDNIS: [1000]
> Caller-Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
> Caller-Profile-Index: [2]
> Caller-Profile-Created-Time: [1255963206242587]
> Caller-Channel-Created-Time: [1255963206214959]
> Caller-Channel-Answered-Time: [0]
> Caller-Channel-Progress-Time: [0]
> Caller-Channel-Progress-Media-Time: [0]
> Caller-Channel-Hangup-Time: [0]
> Caller-Channel-Transfer-Time: [0]
> Caller-Screen-Bit: [true]
> Caller-Privacy-Hide-Name: [false]
> Caller-Privacy-Hide-Number: [false]
> variable_sip_received_ip: [85.16.245.206]
> variable_sip_received_port: [1024]
> variable_sip_via_protocol: [udp]
> variable_sip_authorized: [true]
> variable_sip_from_user: [1001]
> variable_sip_from_port: [5061]
> variable_sip_from_uri: [1...@85.16.246.12:5061]
> variable_sip_from_host: [85.16.246.12]
> variable_sip_from_user_stripped: [1001]
> variable_sip_from_tag: [snfuiue6ga]
> variable_sofia_profile_name: [internal]
> variable_sip_req_params: [user=phone]
> variable_sip_req_user: [1000]
> variable_sip_req_port: [5061]
> variable_sip_req_uri: [1...@85.16.246.12:5061]
> variable_sip_req_host: [85.16.246.12]
> variable_sip_to_params: [user=phone]
> variable_sip_to_user: [1000]
> variable_sip_to_port: [5061]
> variable_sip_to_uri: [1...@85.16.246.12:5061]
> variable_sip_to_host: [85.16.246.12]
> variable_sip_contact_params: [line=eg3wp69a]
> variable_sip_contact_user: [1001]
> variable_sip_contact_port: [1024]
> variable_sip_contact_uri: [1...@85.16.245.206:1024]
> variable_sip_contact_host: [85.16.245.206]
> variable_channel_name: [sofia/internal/1...@85.16.246.12:5061]
> variable_sip_call_id: [3c2d2d8f9a49-edzr2i2iezjp]
> variable_sip_user_agent: [snom820/8.2.16]
> variable_sip_via_host: [85.16.245.206]
> variable_sip_via_port: [1024]
> variable_sip_via_rport: [1024]
> variable_presence_id: [1...@85.16.246.12]
> variable_sip_h_X-Serialnumber: [0004134002CB]
> variable_sip_h_P-Key-Flags: [resolution="31x13", keys="4"]
> variable_switch_r_sdp: [v=0
> o=root 1331667919 1331667919 IN IP4 85.16.245.206
> s=call
> c=IN IP4 85.16.245.206
> t=0 0
> m=audio 62882 RTP/SAVP 0 8 9 99 3 18 4 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=crypto:1 AES_CM_128_HMAC_SHA1_32
> inline:m6fas/KsLF57r9RnU7X0WEWeJw9Y6+a66YUIf9Dc
> a=ptime:20
> m=audio 62882 RTP/AVP 0 8 9 99 3 18 4 101
> a=rtpmap:0 pcmu/8000
> a=rtpmap:8 pcma/8000
> a=rtpmap:9 g722/8000
> a=rtpmap:99 g726-32/8000
> a=rtpmap:3 gsm/8000
> a=rtpmap:18 g729/8000
> a=rtpmap:4 g723/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=ptime:20
> ]
> variable_ep_codec_string: [g...@8000h@20i,p...@8000h@20i]
> variable_endpoint_disposition: [DELAYED NEGOTIATION]
> variable_ET_is_local: [true]
> variable_max_forwards: [69]
> variable_domain_name: [85.16.246.12]
> variable_dialed_extension: [1000]
> variable_sip_callee_id_number: []
> variable_sip_callee_id_name: [hubu]
> variable_export_vars: [sip_callee_id_number,sip_callee_id_name]
> variable_current_application: [info]
>
>
> On 16.10.2009 18:18, Anthony Minessale wrote:
> > 1) you should update again there were a few issues.
> > 2) you can set the variable sip_callee_id_name and sip_callee_id number
> > on the inbound leg before you answer to control what it says.
>
> regards
> Helmut

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://li

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-19 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Anthony,

I updated and restarted my test FS to "FreeSWITCH Version 1.0.trunk
(15174M)". Callee's experience didn't change:

> 1. Phone rings: caller's displayname
> 2. Callee picks up: switching from dislayname to unknown
> 3. Switching from unknown to displayname

I used the two chvars you mentioned, set them via "set" and as well via
"export" but no change (neither on caller's nor in callee's display nor
in SIP INFO messages)


My dialplan portion for this is:

  






[...]


Here is the output of the info app after setting those chvars:

[INFO] mod_dptools.c:961 CHANNEL_DATA:
Channel-State: [CS_EXECUTE]
Channel-State-Number: [4]
Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
Call-Direction: [inbound]
Presence-Call-Direction: [inbound]
Answer-State: [ringing]
Caller-Username: [1001]
Caller-Dialplan: [XML]
Caller-Caller-ID-Name: [1001 an PBX1]
Caller-Caller-ID-Number: [1001]
Caller-Network-Addr: [85.16.245.206]
Caller-Destination-Number: [1000]
Caller-Unique-ID: [4b143750-bcbd-11de-9f91-c9cd82739033]
Caller-Source: [mod_sofia]
Caller-Context: [default]
Caller-RDNIS: [1000]
Caller-Channel-Name: [sofia/internal/1...@85.16.246.12:5061]
Caller-Profile-Index: [2]
Caller-Profile-Created-Time: [1255963206242587]
Caller-Channel-Created-Time: [1255963206214959]
Caller-Channel-Answered-Time: [0]
Caller-Channel-Progress-Time: [0]
Caller-Channel-Progress-Media-Time: [0]
Caller-Channel-Hangup-Time: [0]
Caller-Channel-Transfer-Time: [0]
Caller-Screen-Bit: [true]
Caller-Privacy-Hide-Name: [false]
Caller-Privacy-Hide-Number: [false]
variable_sip_received_ip: [85.16.245.206]
variable_sip_received_port: [1024]
variable_sip_via_protocol: [udp]
variable_sip_authorized: [true]
variable_sip_from_user: [1001]
variable_sip_from_port: [5061]
variable_sip_from_uri: [1...@85.16.246.12:5061]
variable_sip_from_host: [85.16.246.12]
variable_sip_from_user_stripped: [1001]
variable_sip_from_tag: [snfuiue6ga]
variable_sofia_profile_name: [internal]
variable_sip_req_params: [user=phone]
variable_sip_req_user: [1000]
variable_sip_req_port: [5061]
variable_sip_req_uri: [1...@85.16.246.12:5061]
variable_sip_req_host: [85.16.246.12]
variable_sip_to_params: [user=phone]
variable_sip_to_user: [1000]
variable_sip_to_port: [5061]
variable_sip_to_uri: [1...@85.16.246.12:5061]
variable_sip_to_host: [85.16.246.12]
variable_sip_contact_params: [line=eg3wp69a]
variable_sip_contact_user: [1001]
variable_sip_contact_port: [1024]
variable_sip_contact_uri: [1...@85.16.245.206:1024]
variable_sip_contact_host: [85.16.245.206]
variable_channel_name: [sofia/internal/1...@85.16.246.12:5061]
variable_sip_call_id: [3c2d2d8f9a49-edzr2i2iezjp]
variable_sip_user_agent: [snom820/8.2.16]
variable_sip_via_host: [85.16.245.206]
variable_sip_via_port: [1024]
variable_sip_via_rport: [1024]
variable_presence_id: [1...@85.16.246.12]
variable_sip_h_X-Serialnumber: [0004134002CB]
variable_sip_h_P-Key-Flags: [resolution="31x13", keys="4"]
variable_switch_r_sdp: [v=0
o=root 1331667919 1331667919 IN IP4 85.16.245.206
s=call
c=IN IP4 85.16.245.206
t=0 0
m=audio 62882 RTP/SAVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=crypto:1 AES_CM_128_HMAC_SHA1_32
inline:m6fas/KsLF57r9RnU7X0WEWeJw9Y6+a66YUIf9Dc
a=ptime:20
m=audio 62882 RTP/AVP 0 8 9 99 3 18 4 101
a=rtpmap:0 pcmu/8000
a=rtpmap:8 pcma/8000
a=rtpmap:9 g722/8000
a=rtpmap:99 g726-32/8000
a=rtpmap:3 gsm/8000
a=rtpmap:18 g729/8000
a=rtpmap:4 g723/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
]
variable_ep_codec_string: [g...@8000h@20i,p...@8000h@20i]
variable_endpoint_disposition: [DELAYED NEGOTIATION]
variable_ET_is_local: [true]
variable_max_forwards: [69]
variable_domain_name: [85.16.246.12]
variable_dialed_extension: [1000]
variable_sip_callee_id_number: []
variable_sip_callee_id_name: [hubu]
variable_export_vars: [sip_callee_id_number,sip_callee_id_name]
variable_current_application: [info]


On 16.10.2009 18:18, Anthony Minessale wrote:
> 1) you should update again there were a few issues.
> 2) you can set the variable sip_callee_id_name and sip_callee_id number
> on the inbound leg before you answer to control what it says.

regards
Helmut
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK3HwJ4tZeNddg3dwRAieqAKDCn47dzctaYpweRGzovbMPcKD5KQCgjNx+
nNTz4r7+N7mI3Wj4GayFdTk=
=MYOb
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-16 Thread Michael Collins 
On Fri, Oct 16, 2009 at 9:18 AM, Anthony Minessale <
anthony.miness...@gmail.com> wrote:

> 1) you should update again there were a few issues.
> 2) you can set the variable sip_callee_id_name and sip_callee_id number on
> the inbound leg before you answer to control what it says.
>
>
> Thanks for the heads up. I added these two vars to the wiki on the chan
vars page, SIP-related vars section.
-MC
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

Re: [Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-16 Thread Anthony Minessale 
1) you should update again there were a few issues.
2) you can set the variable sip_callee_id_name and sip_callee_id number on
the inbound leg before you answer to control what it says.


On Fri, Oct 16, 2009 at 6:31 AM, Helmut Kuper wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello,
>
> after updating FS to trunk a few days ago I found that callee's display
> is updated serveral times to caller's name after callee picked up. The
> first two equal INFO messages looks like this:
>
> INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
> Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bKU4803UHXaKD2r
> Max-Forwards: 70
> From: "Snom1 an PBX" 
> >;tag=ccc4B2F9SD2rm
> To: ;tag=zbrirvg9ow
> Call-ID: 97a0e683-34e6-122d-8db2-00144fe6e330
> CSeq: 121727215 INFO
> Contact: 
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
> REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Content-Type: message/sipfrag
> Content-Length: 27
>
> From:
> To: "unknown" 2850
>
>
> The third one is this:
>
> INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
> Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bK0H7vc35evZvZj
> Max-Forwards: 70
> From: "Snom1 an PBX" 
> >;tag=ccc4B2F9SD2rm
> To: ;tag=zbrirvg9ow
> Call-ID: 97a0e683-34e6-122d-8db2-00144fe6e330
> CSeq: 121727216 INFO
> Contact: 
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
> REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Content-Type: message/sipfrag
> Content-Length: 32
>
> From:
> To: "Snom1 an PBX" 4918
>
>
> What calle sees is this:
> 1. Phone rings: caller's displayname
> 2. Callee picks up: switching from dislayname to unknown
> 3. Switching from unknown to displayname
>
> After callee has picked up caller's display is also updated with
> callee's name (this is a copy of callee's number rather than callee's
> name) and number.
>
> First Question:
> Can this behaviour be disabled? Or can it be modified by dialplan, so
> that there is no "unknown"?
>
>
>
>
> Unfortunately when you do an outgoing call via openzap and callee picks
> up the phone caller's display is updated with two equal INFO message
> like this:
>
> INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
> Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bK7jFa9Ztg39UUr
> Max-Forwards: 70
> From: 
> ;user=phone>;tag=9QZamXtmUyXvm
> To: "Helmut Kuper" 
> >;tag=5lf2e0q1on
> Call-ID: 3c2a2539a966-0m3i9s85my46
> CSeq: 121727707 INFO
> Contact: 
> User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
> REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Content-Type: message/sipfrag
> Content-Length: 36
>
> From:
> To: "1/a/890327" 1/a/890327
>
>
> Second Question:
> Can I change the name and number via dialplan, so that the correkt name
> and number is viewed to caller?
>
>
> regards
> helmut
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.7 (MingW32)
>
> iD8DBQFK2Fmk4tZeNddg3dwRApPUAKCQLBEi/l6mwf1c55r5mlnEqvLLowCgoP9t
> VSQFKUCWpsxVm3evyfWQT/Y=
> =FGsp
> -END PGP SIGNATURE-
>
> ___
> FreeSWITCH-users mailing list
> FreeSWITCH-users@lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> 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_miness...@hotmail.com 
GTALK/JABBER/PAYPAL:anthony.miness...@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:8...@conference.freeswitch.org 
iax:gu...@conference.freeswitch.org/888
googletalk:conf+...@conference.freeswitch.org
pstn:213-799-1400
___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[Freeswitch-users] Qustion about INFO messages after Connect/Answer

2009-10-16 Thread Helmut Kuper 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

after updating FS to trunk a few days ago I found that callee's display
is updated serveral times to caller's name after callee picked up. The
first two equal INFO messages looks like this:

INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bKU4803UHXaKD2r
Max-Forwards: 70
From: "Snom1 an PBX" ;tag=ccc4B2F9SD2rm
To: ;tag=zbrirvg9ow
Call-ID: 97a0e683-34e6-122d-8db2-00144fe6e330
CSeq: 121727215 INFO
Contact: 
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Type: message/sipfrag
Content-Length: 27

From:
To: "unknown" 2850


The third one is this:

INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bK0H7vc35evZvZj
Max-Forwards: 70
From: "Snom1 an PBX" ;tag=ccc4B2F9SD2rm
To: ;tag=zbrirvg9ow
Call-ID: 97a0e683-34e6-122d-8db2-00144fe6e330
CSeq: 121727216 INFO
Contact: 
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Type: message/sipfrag
Content-Length: 32

From:
To: "Snom1 an PBX" 4918


What calle sees is this:
1. Phone rings: caller's displayname
2. Callee picks up: switching from dislayname to unknown
3. Switching from unknown to displayname

After callee has picked up caller's display is also updated with
callee's name (this is a copy of callee's number rather than callee's
name) and number.

First Question:
Can this behaviour be disabled? Or can it be modified by dialplan, so
that there is no "unknown"?




Unfortunately when you do an outgoing call via openzap and callee picks
up the phone caller's display is updated with two equal INFO message
like this:

INFO sip:2...@85.16.245.213:1040;line=367hfn9i SIP/2.0
Via: SIP/2.0/UDP 85.16.246.6;rport;branch=z9hG4bK7jFa9Ztg39UUr
Max-Forwards: 70
From: ;tag=9QZamXtmUyXvm
To: "Helmut Kuper" ;tag=5lf2e0q1on
Call-ID: 3c2a2539a966-0m3i9s85my46
CSeq: 121727707 INFO
Contact: 
User-Agent: FreeSWITCH-mod_sofia/1.0.trunk-15137M
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, REGISTER,
REFER, UPDATE, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, precondition, path, replaces
Content-Type: message/sipfrag
Content-Length: 36

From:
To: "1/a/890327" 1/a/890327


Second Question:
Can I change the name and number via dialplan, so that the correkt name
and number is viewed to caller?


regards
helmut
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)

iD8DBQFK2Fmk4tZeNddg3dwRApPUAKCQLBEi/l6mwf1c55r5mlnEqvLLowCgoP9t
VSQFKUCWpsxVm3evyfWQT/Y=
=FGsp
-END PGP SIGNATURE-

___
FreeSWITCH-users mailing list
FreeSWITCH-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org