Khushil Dep invites you to their network on Ecademy
Connect with me on Ecademy Hi I've added you as one of my contacts on Ecademy where successful business people grow their business. Click here to connect with me: http://www.ecademy.com/account.php?op=signup&xref=310185 Thank you, Khushil Dep khushil.dep@gmail.com This email was sent to freeswitch-users@lists.freeswitch.org To avoid receiving these emails in the future send an email from that address to invite-unsubscribe@ecademy.com or go to http://www.ecademy.com/blockinvites.php?e=freeswitch-users@lists.freeswitch.... Email:support@ecademy.com Company Registration:3651083 VAT:718 0377 36
We’re almost done testing the (initial) interoperability between Freeswitch and the Exchange 2007 Unified-Messaging server. I’ll be happy to share our conclusions once we’re done. I have a couple of questions in this regards: I’ve noticed the FS RFC2833 DTMF doesn’t work. It does work once the call placed in either bypass_media or pass-rfc2833. I’ve found the difference between the two scenarios was in the “RFC 2833 RTP Event” payload: Working scenario: Event Duration starts from 0 Non-working scenario: Event Duration starts from 160. Is that by design or a bug? If by design, how do I change that so the FS will start from 0? I’ve also found the Volume setting’s different: on FS it’s hardcoded 7 (/src/switch_rtp.c, line 1047: “rtp_session->dtmf_data.out_digit_packet[1] = 7”). Other devices usually use 10. Any reason for that number? Just curious. Cheers, UV No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1522 - Release Date: 27/06/2008 08:27
It is an rfc violation to start at 0. Thats a bug in your other device. In regards to the volume, it should not matter, we set it based on what we had seen on a lot of other devices, we should probably make that pass through in the same way we do duration. I doubt either of these is the problem. Take a closer look at the pt used for 2833 compared to what we negotiated, see if anything is amiss there. We have had people successfully interop with exchange before, if they could chime in, also, check the wiki as there is a page there. Mike On Jun 28, 2008, at 3:19 PM, UV wrote:
We’re almost done testing the (initial) interoperability between Freeswitch and the Exchange 2007 Unified-Messaging server. I’ll be happy to share our conclusions once we’re done.
I have a couple of questions in this regards: I’ve noticed the FS RFC2833 DTMF doesn’t work. It does work once the call placed in either bypass_media or pass-rfc2833. I’ve found the difference between the two scenarios was in the “RFC 2833 RTP Event” payload: Working scenario: Event Duration starts from 0 Non-working scenario: Event Duration starts from 160. Is that by design or a bug? If by design, how do I change that so the FS will start from 0?
I’ve also found the Volume setting’s different: on FS it’s hardcoded 7 (/src/switch_rtp.c, line 1047: “rtp_session-
dtmf_data.out_digit_packet[1] = 7”). Other devices usually use 10. Any reason for that number? Just curious.
Cheers, UV No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1522 - Release Date: 27/06/2008 08:27
_______________________________________________ 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
Starting at zero means forever doesn't it? /b On Jun 28, 2008, at 2:32 PM, Michael Jerris wrote:
It is an rfc violation to start at 0. Thats a bug in your other device. In regards to the volume, it should not matter, we set it based on what we had seen on a lot of other devices, we should probably make that pass through in the same way we do duration. I doubt either of these is the problem. Take a closer look at the pt used for 2833 compared to what we negotiated, see if anything is amiss there. We have had people successfully interop with exchange before, if they could chime in, also, check the wiki as there is a page there.
Mike
On Jun 28, 2008, at 3:19 PM, UV wrote:
We’re almost done testing the (initial) interoperability between Freeswitch and the Exchange 2007 Unified-Messaging server. I’ll be happy to share our conclusions once we’re done.
I have a couple of questions in this regards: I’ve noticed the FS RFC2833 DTMF doesn’t work. It does work once the call placed in either bypass_media or pass-rfc2833. I’ve found the difference between the two scenarios was in the “RFC 2833 RTP Event” payload: Working scenario: Event Duration starts from 0 Non-working scenario: Event Duration starts from 160. Is that by design or a bug? If by design, how do I change that so the FS will start from 0?
I’ve also found the Volume setting’s different: on FS it’s hardcoded 7 (/src/switch_rtp.c, line 1047: “rtp_session-
dtmf_data.out_digit_packet[1] = 7”). Other devices usually use 10. Any reason for that number? Just curious.
Cheers, UV No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1522 - Release Date: 27/06/2008 08:27
_______________________________________________ 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 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
The only page I found on UM is http://wiki.freeswitch.org/wiki/Exchange_2007_UM and even there it’s stated “bypass_media_true was used because DTMF was not interpreted by FreeSWITCH (bug ?)” so I guess they couldn’t make it work as well. In a working scenario (using SJPhone) the Event Duration starts from 0 (in the first packet) and then 160, 320, 480 and so forth until three identical packets of 2280. In the non-working scenario (no pass though), it’s exactly the same but without the first packet of Event Duration 0. _____ From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Brian West Sent: Sunday, June 29, 2008 6:02 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Starting at zero means forever doesn't it? /b On Jun 28, 2008, at 2:32 PM, Michael Jerris wrote: It is an rfc violation to start at 0. Thats a bug in your other device. In regards to the volume, it should not matter, we set it based on what we had seen on a lot of other devices, we should probably make that pass through in the same way we do duration. I doubt either of these is the problem. Take a closer look at the pt used for 2833 compared to what we negotiated, see if anything is amiss there. We have had people successfully interop with exchange before, if they could chime in, also, check the wiki as there is a page there. Mike On Jun 28, 2008, at 3:19 PM, UV wrote: We’re almost done testing the (initial) interoperability between Freeswitch and the Exchange 2007 Unified-Messaging server. I’ll be happy to share our conclusions once we’re done. I have a couple of questions in this regards: I’ve noticed the FS RFC2833 DTMF doesn’t work. It does work once the call placed in either bypass_media or pass-rfc2833. I’ve found the difference between the two scenarios was in the “RFC 2833 RTP Event” payload: Working scenario: Event Duration starts from 0 Non-working scenario: Event Duration starts from 160. Is that by design or a bug? If by design, how do I change that so the FS will start from 0? I’ve also found the Volume setting’s different: on FS it’s hardcoded 7 (/src/switch_rtp.c, line 1047: “rtp_session->dtmf_data.out_digit_packet[1] = 7”). Other devices usually use 10. Any reason for that number? Just curious. Cheers, UV No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.1/1522 - Release Date: 27/06/2008 08:27 _______________________________________________ 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 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 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.2/1523 - Release Date: 28/06/2008 07:00
So if you can tell me where this is wrong as per 2833 and the clarification via 4733 ? rfc4733 obsoletes rfc2833 and says this: The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state. /b PS: http://www.rfc-editor.org/rfc/rfc4733.txt On Jun 28, 2008, at 11:10 PM, UV wrote:
The only page I found on UM is http://wiki.freeswitch.org/wiki/Exchange_2007_UM and even there it’s stated “bypass_media_true was used because DTMF was not interpreted by FreeSWITCH (bug ?)” so I guess they couldn’t make it work as well.
In a working scenario (using SJPhone) the Event Duration starts from 0 (in the first packet) and then 160, 320, 480 and so forth until three identical packets of 2280. In the non-working scenario (no pass though), it’s exactly the same but without the first packet of Event Duration 0.
Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this: The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state. /b PS: http://www.rfc-editor.org/rfc/rfc4733.txt
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve
Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others. Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem Hi, Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this: The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state. /b PS: http://www.rfc-editor.org/rfc/rfc4733.txt
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400. What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive. Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases. In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated. Regards, Steve _______________________________________________ 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 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1524 - Release Date: 28/06/2008 19:42 No virus found in this outgoing message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1524 - Release Date: 28/06/2008 19:42
Steve, I'm pretty sure we don't drop anything. We more or less try to SEND with a policy as close to the RFC we can. on RECV, we pretty much allow for as many mistakes as possible within reason. The big issue tends to come from situations where we are being a b2bua and passing through audio and dtmf. We have various settings in the system to choose to pass the RFCXXXX packets transparently or to parse them as they are encountered depending on the situation. Also setting proxy_media=true will turn on full transparent proxy mode which will most likely work as well. UV, Matt, (hmmhesays on irc) was doing a lot of playing around with this so he would be a good guy to ask. On Sun, Jun 29, 2008 at 4:44 AM, UV <uv@talknet.com.au> wrote:
Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others.
Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance.
-----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Steve Underwood Sent: Sunday, June 29, 2008 3:42 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem
Hi,
Brian West wrote:
So if you can tell me where this is wrong as per 2833 and the clarification via 4733 ?
rfc4733 obsoletes rfc2833 and says this: The special duration value of zero is reserved to indicate that the event lasts "forever", i.e., is a state and is considered to be effective until updated. A sender MUST NOT transmit a zero duration for events other than those defined as states. The receiver SHOULD ignore an event report with zero duration if the event is not a state. /b PS: http://www.rfc-editor.org/rfc/rfc4733.txt
As well as that definition in RFC4733, they also have an example working in the way the text describes. They send DTMF with a packet rate of one every 50ms. The first packet of the DTMF sequence contains a duration of 400.
What does FS actually do when a sequence starts at 0? Does it just drop the first packet, or the whole sequence? If it just drops the first packet, and the far end cares, that's seriously broken on their part. It means a single lost packet screws up the whole sequence. Not good. If FS drops the whole sequence, that might be a little too aggressive.
Some will argue that a gateway should be totally transparent in these situations, but total transparency is only workable in simplistic cases.
In the end, if MS are doing this you can be sure it will not be fixed, and must be tolerated.
Regards, Steve
_______________________________________________ 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 No virus found in this incoming message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1524 - Release Date: 28/06/2008 19:42
No virus found in this outgoing message. Checked by AVG. Version: 8.0.101 / Virus Database: 270.4.3/1524 - Release Date: 28/06/2008 19:42
_______________________________________________ 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/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Sat, Jun 28, 2008 at 11:44 PM, UV <uv@talknet.com.au> wrote:
Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others.
Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance.
Yuval, Did you ever get the DTMF working 100%...we are noticing about a 30% failure rate over here. It seems like when it is not working, it won't work for the entire call. -Matt
Yes I did, but you might not even need that. Try adding <param name="pass-rfc2833" value="true"/> in your external SIP profile and see if it solves the problem. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Matt Darnell Sent: Saturday, July 26, 2008 11:59 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem On Sat, Jun 28, 2008 at 11:44 PM, UV <uv@talknet.com.au> wrote:
Apparently, not only MS do not comply with RFC4733 but also SJphone, Xlite (eyebeam) and Cisco (Call manager, IP phones, etc) amongst others.
Is there anyway I can make FS's Duration to start from 0? I'm happy to change the code myself with a little guidance.
Yuval, Did you ever get the DTMF working 100%...we are noticing about a 30% failure rate over here. It seems like when it is not working, it won't work for the entire call. -Matt _______________________________________________ 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 No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.6/1574 - Release Date: 25/07/2008 16:27 No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.138 / Virus Database: 270.5.6/1574 - Release Date: 25/07/2008 16:27
On Fri, Jul 25, 2008 at 8:51 PM, UV <uv@talknet.com.au> wrote:
Yes I did, but you might not even need that. Try adding <param name="pass-rfc2833" value="true"/> in your external SIP profile and see if it solves the problem.
Yuval, That really makes a big difference...thanks for the tip. -Matt
On Fri, Jul 25, 2008 at 8:51 PM, UV <uv@talknet.com.au> wrote:
Yes I did, but you might not even need that. Try adding <param name="pass-rfc2833" value="true"/> in your external SIP profile and see if it solves the problem.
I am still trying to get the DTMF 100%, I added the value but get this message in the debug log: [WARNING] mod_sofia.c:787 sofia_receive_message() Cannot pass 2833 on a transcoded call It does not appear that any transcoding is happening from the SIP setup messages. I found this, but it doesn't give any clue. case SWITCH_MESSAGE_INDICATE_TRANSCODING_NECESSARY: if (tech_pvt->rtp_session && switch_rtp_test_flag(tech_pvt->rtp_session, SWITCH_RTP_FLAG_PASS_RFC2833)) { switch_log_printf(SWITCH_CHANNEL_LOG, SWITCH_LOG_WARNING, "Cannot pass 2833 on a transcoded call.\n"); switch_rtp_clear_flag(tech_pvt->rtp_session, SWITCH_RTP_FLAG_PASS_RFC2833); } break; -Matt
On Wed, Sep 17, 2008 at 10:14 AM, Matt Darnell <mattdarnell@gmail.com> wrote:
On Fri, Jul 25, 2008 at 8:51 PM, UV <uv@talknet.com.au> wrote:
Yes I did, but you might not even need that. Try adding <param name="pass-rfc2833" value="true"/> in your external SIP profile and see if it solves the problem.
I am still trying to get the DTMF 100%, I added the value but get this message in the debug log: [WARNING] mod_sofia.c:787 sofia_receive_message() Cannot pass 2833 on a transcoded call
It does not appear that any transcoding is happening from the SIP setup messages.
Steve, Thanks for the response, here is the architecture: SIP Provider <-> SIP UDP <-> Internet <-> Freeswitch <-> LAN <-> SIP TCP <-> Exch 2007 It appears to be G711 throughout the entire call, is it transcoded just because Freeswitch is bridging the call? -Matt
post a trace of FS after pressing f8 from the cli detailing the entire call and we can have a look. On Fri, Sep 19, 2008 at 6:29 PM, Matt Darnell <mattdarnell@gmail.com> wrote:
On Wed, Sep 17, 2008 at 10:14 AM, Matt Darnell <mattdarnell@gmail.com> wrote:
On Fri, Jul 25, 2008 at 8:51 PM, UV <uv@talknet.com.au> wrote:
Yes I did, but you might not even need that. Try adding <param name="pass-rfc2833" value="true"/> in your external SIP profile and see if it solves the problem.
I am still trying to get the DTMF 100%, I added the value but get this message in the debug log: [WARNING] mod_sofia.c:787 sofia_receive_message() Cannot pass 2833 on a transcoded call
It does not appear that any transcoding is happening from the SIP setup messages.
Steve,
Thanks for the response, here is the architecture:
SIP Provider <-> SIP UDP <-> Internet <-> Freeswitch <-> LAN <-> SIP TCP <-> Exch 2007
It appears to be G711 throughout the entire call, is it transcoded just because Freeswitch is bridging the call?
-Matt
_______________________________________________ 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/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
On Fri, Sep 19, 2008 at 3:05 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
post a trace of FS after pressing f8 from the cli detailing the entire call and we can have a look.
Anthony, Please find the trace in the email and attached. ------------------------------------------------------------------------ recv 1149 bytes from udp/[213.192.59.75]:5060 at 00:56:29.545782: ------------------------------------------------------------------------ INVITE sip:8084473453@vm.akamaitel.com SIP/2.0 Record-Route: <sip:213.192.59.75;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK6a9e.7e574dc5.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-a30c554e5236171f-1---d8754z- Max-Forwards: 16 Contact: <sip:matthewdarnell@66.8.218.137:51604;transport=TCP> To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com> From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 INVITE Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO Content-Type: application/sdp User-Agent: X-Lite release 1100l stamp 47546 Content-Length: 202 P-hint: outbound P-RTP-Proxy: YES v=0 o=- 7 2 IN IP4 66.8.218.137 s=CounterPath X-Lite 3.0 c=IN IP4 213.192.59.91 t=0 0 m=audio 52402 RTP/AVP 0 101 a=fmtp:101 0-15 a=rtpmap:101 telephone-event/8000 a=sendrecv a=nortpproxy:yes ------------------------------------------------------------------------ send 688 bytes to udp/[213.192.59.75]:5060 at 00:56:29.546994: ------------------------------------------------------------------------ SIP/2.0 100 Trying Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK6a9e.7e574dc5.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-a30c554e5236171f-1---d8754z- Record-Route: <sip:213.192.59.75;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com> Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 INVITE User-Agent: FreeSWITCH-mod_sofia/1.0.1-exported Content-Length: 0 ------------------------------------------------------------------------ 2008-09-20 14:56:29 [NOTICE] switch_channel.c:534 switch_channel_set_name() New Channel sofia/external/matthewdarnell@iptel.org [63a6e8bf-46dd-4e66-9ebe-7b38df5e64cb] 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/external/matthewdarnell@iptel.org entering state [received] 2008-09-20 14:56:29 [DEBUG] sofia.c:2133 sofia_handle_sip_i_state() Remote SDP: v=0 o=- 7 2 IN IP4 66.8.218.137 s=CounterPath X-Lite 3.0 c=IN IP4 213.192.59.91 t=0 0 m=audio 52402 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=nortpproxy:yes 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2280 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[G722:9:8000] 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2243 sofia_glue_negotiate_sdp() Set 2833 dtmf payload to 101 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2280 sofia_glue_negotiate_sdp() Audio Codec Compare [telephone-event:101:8000]/[G722:9:8000] 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2280 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMU:0:8000]/[PCMU:0:8000] 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:1530 sofia_glue_tech_set_codec() Set Codec sofia/external/matthewdarnell@iptel.org PCMU/8000 20 ms 160 samples 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/external/matthewdarnell@iptel.org Running State Change CS_NEW 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:369 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State NEW 2008-09-20 14:56:29 [DEBUG] sofia.c:2270 sofia_handle_sip_i_state() sofia/external/matthewdarnell@iptel.org State Change CS_NEW -> CS_INIT 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/external/matthewdarnell@iptel.org Running State Change CS_INIT 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:415 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State INIT 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:80 sofia_on_init() sofia/external/matthewdarnell@iptel.org SOFIA INIT 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:107 sofia_on_init() sofia/external/matthewdarnell@iptel.org State Change CS_INIT -> CS_ROUTING 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:415 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State INIT going to sleep 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/external/matthewdarnell@iptel.org Running State Change CS_ROUTING 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:420 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State ROUTING 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:119 sofia_on_routing() sofia/external/matthewdarnell@iptel.org SOFIA ROUTING 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:64 switch_core_standard_on_routing() Standard ROUTING sofia/external/matthewdarnell@iptel.org 2008-09-20 14:56:29 [INFO] mod_dialplan_xml.c:222 dialplan_hunt() Processing matthewdarnell->8084473453@public 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions desination-number() =~ /3451/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions ${sip_referred_by_user}() =~ /8084473451/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions ${sip_referred_by_user}() =~ /8084473452/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions ${sip_referred_by_user}() =~ /8084473453/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(8084473453) =~ /8085353111/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(8084473453) =~ /8085353112/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions destination_number(8084473453) =~ /8087695297/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions ${sip_to_user}(8084473453) =~ /8084473451/ 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:109 parse_exten() Regex mismatch 2008-09-20 14:56:29 [DEBUG] mod_dialplan_xml.c:107 parse_exten() test conditions ${sip_to_user}(8084473453) =~ /8084473453/ 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:97 switch_core_standard_on_routing() sofia/external/matthewdarnell@iptel.org State Change CS_ROUTING -> CS_EXECUTE 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:420 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State ROUTING going to sleep 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/external/matthewdarnell@iptel.org Running State Change CS_EXECUTE 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:430 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State EXECUTE 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:156 sofia_on_execute() sofia/external/matthewdarnell@iptel.org SOFIA EXECUTE 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:129 switch_core_standard_on_execute() Standard EXECUTE 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:140 switch_core_standard_on_execute() sofia/external/matthewdarnell@iptel.org Execute info() 2008-09-20 14:56:29 [INFO] mod_dptools.c:876 info_function() CHANNEL_DATA: Channel-State: [CS_EXECUTE] Channel-State-Number: [4] Channel-Name: [sofia/external/matthewdarnell@iptel.org] Unique-ID: [63a6e8bf-46dd-4e66-9ebe-7b38df5e64cb] Call-Direction: [inbound] Answer-State: [ringing] Channel-Read-Codec-Name: [PCMU] Channel-Read-Codec-Rate: [8000] Channel-Write-Codec-Name: [PCMU] Channel-Write-Codec-Rate: [8000] Caller-Username: [matthewdarnell] Caller-Dialplan: [XML] Caller-Caller-ID-Name: [matthewdarnell] Caller-Caller-ID-Number: [matthewdarnell] Caller-Network-Addr: [213.192.59.75] Caller-Destination-Number: [8084473453] Caller-Unique-ID: [63a6e8bf-46dd-4e66-9ebe-7b38df5e64cb] Caller-Source: [mod_sofia] Caller-Context: [public] Caller-Channel-Name: [sofia/external/matthewdarnell@iptel.org] Caller-Profile-Index: [1] Caller-Channel-Created-Time: [1221958589547402] Caller-Channel-Answered-Time: [0] Caller-Channel-Hangup-Time: [0] Caller-Channel-Transfer-Time: [0] Caller-Screen-Bit: [yes] Caller-Privacy-Hide-Name: [no] Caller-Privacy-Hide-Number: [no] variable_sip_received_ip: [213.192.59.75] variable_sip_received_port: [5060] variable_sip_from_user: [matthewdarnell] variable_sip_from_uri: [matthewdarnell@iptel.org] variable_sip_from_host: [iptel.org] variable_sip_from_user_stripped: [matthewdarnell] variable_sip_from_tag: [8a095b76] variable_sofia_profile_name: [external] variable_sofia_profile_domain_name: [external] variable_sip_req_user: [8084473453] variable_sip_req_uri: [8084473453@vm.akamaitel.com] variable_sip_req_host: [vm.akamaitel.com] variable_sip_to_user: [8084473453] variable_sip_to_uri: [8084473453@vm.akamaitel.com] variable_sip_to_host: [vm.akamaitel.com] variable_sip_contact_params: [transport=TCP] variable_sip_contact_user: [matthewdarnell] variable_sip_contact_port: [51604] variable_sip_contact_uri: [matthewdarnell@66.8.218.137:51604] variable_sip_contact_host: [66.8.218.137] variable_channel_name: [sofia/external/matthewdarnell@iptel.org] variable_sip_call_id: [MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY.] variable_sip_user_agent: [X-Lite release 1100l stamp 47546] variable_sip_via_host: [213.192.59.75] variable_max_forwards: [16] variable_sip_h_P-hint: [outbound] variable_sip_h_P-RTP-Proxy: [YES] variable_switch_r_sdp: [v=0 o=- 7 2 IN IP4 66.8.218.137 s=CounterPath X-Lite 3.0 c=IN IP4 213.192.59.91 t=0 0 m=audio 52402 RTP/AVP 0 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=nortpproxy:yes ] variable_remote_media_ip: [213.192.59.91] variable_remote_media_port: [52402] variable_read_codec: [PCMU] variable_read_rate: [8000] variable_write_codec: [PCMU] variable_write_rate: [8000] variable_endpoint_disposition: [RECEIVED] variable_current_application: [info] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:140 switch_core_standard_on_execute() sofia/external/matthewdarnell@iptel.org Execute export(sip_h_Diversion=3453) 2008-09-20 14:56:29 [DEBUG] mod_dptools.c:816 export_function() EXPORT [sip_h_Diversion]=[3453] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:140 switch_core_standard_on_execute() sofia/external/matthewdarnell@iptel.org Execute bridge({absolute_codec_string=PCMA}sofia/gateway/exch.akamaitel.com/3453) 2008-09-20 14:56:29 [DEBUG] switch_ivr_originate.c:652 switch_ivr_originate() variable string 0 = [absolute_codec_string=PCMA] 2008-09-20 14:56:29 [NOTICE] switch_channel.c:534 switch_channel_set_name() New Channel sofia/internal/3453 [ccc144e0-3c8a-4097-8a39-7d8f2e07018c] 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:2001 sofia_outgoing_channel() sofia/internal/3453 State Change CS_NEW -> CS_INIT 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/internal/3453 Running State Change CS_INIT 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:415 switch_core_session_run() (sofia/internal/3453) State INIT 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:80 sofia_on_init() sofia/internal/3453 SOFIA INIT 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:107 sofia_on_init() sofia/internal/3453 State Change CS_INIT -> CS_ROUTING 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:415 switch_core_session_run() (sofia/internal/3453) State INIT going to sleep 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/internal/3453 Running State Change CS_ROUTING 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:420 switch_core_session_run() (sofia/internal/3453) State ROUTING 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:119 sofia_on_routing() sofia/internal/3453 SOFIA ROUTING 2008-09-20 14:56:29 [DEBUG] switch_ivr_originate.c:57 originate_on_routing() sofia/internal/3453 State Change CS_ROUTING -> CS_CONSUME_MEDIA 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:420 switch_core_session_run() (sofia/internal/3453) State ROUTING going to sleep 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/internal/3453 Running State Change CS_CONSUME_MEDIA 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:442 switch_core_session_run() (sofia/internal/3453) State CONSUME_MEDIA 2008-09-20 14:56:29 [DEBUG] sofia.c:197 sofia_event_callback() event [nua_i_state] status [0][INVITE sent] session: sofia/internal/3453 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/internal/3453 entering state [calling] 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/internal/3453 entering state [calling] 2008-09-20 14:56:29 [DEBUG] sofia.c:197 sofia_event_callback() event [nua_r_invite] status [180][Ringing] session: sofia/internal/3453 2008-09-20 14:56:29 [DEBUG] sofia.c:197 sofia_event_callback() event [nua_i_state] status [180][Ringing] session: sofia/internal/3453 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/internal/3453 entering state [proceeding] 2008-09-20 14:56:29 [NOTICE] sofia.c:2167 sofia_handle_sip_i_state() Ring-Ready sofia/internal/3453! 2008-09-20 14:56:29 [NOTICE] mod_sofia.c:1058 sofia_receive_message() Ring-Ready sofia/external/matthewdarnell@iptel.org! 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [NOTICE] switch_ivr_originate.c:1148 switch_ivr_originate() Ring Ready sofia/external/matthewdarnell@iptel.org! 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/external/matthewdarnell@iptel.org [BREAK] send 976 bytes to udp/[213.192.59.75]:5060 at 00:56:29.603515: ------------------------------------------------------------------------ SIP/2.0 180 Ringing Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK6a9e.7e574dc5.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-a30c554e5236171f-1---d8754z- Record-Route: <sip:213.192.59.75;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 To: "8084473453@vm.akamaitel.com" <sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 INVITE Contact: <sip:mod_sofia@64.75.215.160:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.1-exported Accept: application/sdp Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, timer, precondition, path, replaces Allow-Events: talk Content-Length: 0 ------------------------------------------------------------------------ 2008-09-20 14:56:29 [DEBUG] sofia.c:197 sofia_event_callback() event [nua_i_state] status [180][Ringing] session: sofia/external/matthewdarnell@iptel.org 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/external/matthewdarnell@iptel.org entering state [early] 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/internal/3453 entering state [ready] 2008-09-20 14:56:29 [DEBUG] sofia.c:2133 sofia_handle_sip_i_state() Remote SDP: v=0 o=- 0 0 IN IP4 10.10.20.31 s=Microsoft Exchange Speech Engine c=IN IP4 10.10.20.31 t=0 0 m=audio 64000 RTP/AVP 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2280 sofia_glue_negotiate_sdp() Audio Codec Compare [PCMA:8:8000]/[PCMA:8:8000] 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:1530 sofia_glue_tech_set_codec() Set Codec sofia/internal/3453 PCMA/8000 20 ms 160 samples 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:2243 sofia_glue_negotiate_sdp() Set 2833 dtmf payload to 101 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:1739 sofia_glue_activate_rtp() AUDIO RTP [sofia/internal/3453] 10.10.20.50 port 21900 -> 10.10.20.31 port 64000 codec: 8 ms: 20 2008-09-20 14:56:29 [DEBUG] switch_rtp.c:813 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-09-20 14:56:29 [DEBUG] switch_channel.c:1540 switch_channel_perform_mark_answered() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [NOTICE] sofia.c:2491 sofia_handle_sip_i_state() Channel [sofia/internal/3453] has been answered 2008-09-20 14:56:29 [DEBUG] sofia_glue.c:1739 sofia_glue_activate_rtp() AUDIO RTP [sofia/external/matthewdarnell@iptel.org] 64.75.215.160 port 21900 -> 213.192.59.91 port 52402 codec: 0 ms: 20 2008-09-20 14:56:29 [DEBUG] switch_rtp.c:813 switch_rtp_create() Starting timer [soft] 160 bytes per 20000ms 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:430 sofia_answer_channel() Local SDP sofia/external/matthewdarnell@iptel.org: v=0 o=FreeSWITCH 1221936689 1221936690 IN IP4 64.75.215.160 s=FreeSWITCH c=IN IP4 64.75.215.160 t=0 0 a=sendrecv m=audio 21900 RTP/AVP 0 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [NOTICE] switch_ivr_originate.c:1298 switch_ivr_originate() Channel [sofia/external/matthewdarnell@iptel.org] has been answered 2008-09-20 14:56:29 [DEBUG] switch_ivr_originate.c:1336 switch_ivr_originate() Originate Resulted in Success: [sofia/internal/3453] send 1297 bytes to udp/[213.192.59.75]:5060 at 00:56:29.691843: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK6a9e.7e574dc5.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-a30c554e5236171f-1---d8754z- Record-Route: <sip:213.192.59.75;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 To: "8084473453@vm.akamaitel.com" <sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 INVITE Contact: <sip:mod_sofia@64.75.215.160:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.1-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, timer, precondition, path, replaces Allow-Events: talk Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 275 v=0 o=FreeSWITCH 2051309078168030273 270946083756621899 IN IP4 64.75.215.160 s=FreeSWITCH c=IN IP4 64.75.215.160 t=0 0 a=sendrecv m=audio 21900 RTP/AVP 0 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 ------------------------------------------------------------------------ 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_ivr_bridge.c:778 switch_ivr_multi_threaded_bridge() sofia/internal/3453 State Change CS_CONSUME_MEDIA -> CS_EXCHANGE_MEDIA 2008-09-20 14:56:29 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/external/matthewdarnell@iptel.org entering state [completed] 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:442 switch_core_session_run() (sofia/internal/3453) State CONSUME_MEDIA going to sleep 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/internal/3453 Running State Change CS_EXCHANGE_MEDIA 2008-09-20 14:56:29 [DEBUG] switch_core_state_machine.c:433 switch_core_session_run() (sofia/internal/3453) State EXCHANGE_MEDIA 2008-09-20 14:56:29 [DEBUG] mod_sofia.c:356 sofia_on_exchange_media() SOFIA LOOPBACK 2008-09-20 14:56:29 [WARNING] mod_sofia.c:787 sofia_receive_message() Cannot pass 2833 on a transcoded call. 2008-09-20 14:56:29 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/external/matthewdarnell@iptel.org [BREAK] send 1297 bytes to udp/[213.192.59.75]:5060 at 00:56:30.191803: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK6a9e.7e574dc5.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-a30c554e5236171f-1---d8754z- Record-Route: <sip:213.192.59.75;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=FlYDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAA;lr=on> From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 To: "8084473453@vm.akamaitel.com" <sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 INVITE Contact: <sip:mod_sofia@64.75.215.160:5060;transport=udp> User-Agent: FreeSWITCH-mod_sofia/1.0.1-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, timer, precondition, path, replaces Allow-Events: talk Min-SE: 120 Content-Type: application/sdp Content-Disposition: session Content-Length: 275 v=0 o=FreeSWITCH 2051309078168030273 270946083756621899 IN IP4 64.75.215.160 s=FreeSWITCH c=IN IP4 64.75.215.160 t=0 0 a=sendrecv m=audio 21900 RTP/AVP 0 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=rtpmap:13 CN/8000 a=ptime:20 ------------------------------------------------------------------------ 2008-09-20 14:56:30 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/internal/3453 [BREAK] recv 1068 bytes from udp/[213.192.59.75]:5060 at 00:56:30.482170: ------------------------------------------------------------------------ ACK sip:mod_sofia@64.75.215.160:5060;transport=udp SIP/2.0 Record-Route: <sip:213.192.59.75;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Via: SIP/2.0/UDP 213.192.59.75;branch=0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-913ca92e8a3d2e18-1---d8754z- Max-Forwards: 16 Contact: <sip:matthewdarnell@66.8.218.137:51604;transport=TCP> To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 ACK Proxy-Authorization: Digest username="matthewdarnell",realm="iptel.org",nonce="SNWbxEjVm7o6R3qdBfGurqbPhiiBGN51",uri="sip:8084473453@vm.akamaitel.com",response="30b91ac06db13426f1b6be0c3c870768",algorithm=MD5 User-Agent: X-Lite release 1100l stamp 47546 Content-Length: 0 P-hint: rr-enforced ------------------------------------------------------------------------ 2008-09-20 14:56:30 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/external/matthewdarnell@iptel.org entering state [ready] recv 1068 bytes from udp/[213.192.59.75]:5060 at 00:56:30.914214: ------------------------------------------------------------------------ ACK sip:mod_sofia@64.75.215.160:5060;transport=udp SIP/2.0 Record-Route: <sip:213.192.59.75;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Via: SIP/2.0/UDP 213.192.59.75;branch=0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-913ca92e8a3d2e18-1---d8754z- Max-Forwards: 16 Contact: <sip:matthewdarnell@66.8.218.137:51604;transport=TCP> To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 2 ACK Proxy-Authorization: Digest username="matthewdarnell",realm="iptel.org",nonce="SNWbxEjVm7o6R3qdBfGurqbPhiiBGN51",uri="sip:8084473453@vm.akamaitel.com",response="30b91ac06db13426f1b6be0c3c870768",algorithm=MD5 User-Agent: X-Lite release 1100l stamp 47546 Content-Length: 0 P-hint: rr-enforced ------------------------------------------------------------------------ 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [3] ts=2646300 dur=160/160/2000 seq=35151 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=320/320/2000 seq=35152 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=480/480/2000 seq=35153 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=640/640/2000 seq=35154 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=800/800/2000 seq=35155 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=960/960/2000 seq=35156 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1120/1120/2000 seq=35157 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1280/1280/2000 seq=35158 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1440/1440/2000 seq=35159 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1600/1600/2000 seq=35160 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1760/1760/2000 seq=35161 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [3] ts=2646300 dur=1920/1920/2000 seq=35162 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [3] ts=2646300 dur=2080/2080/2000 seq=35163 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [3] ts=2646300 dur=2080/2080/2000 seq=35164 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [3] ts=2646300 dur=2080/2080/2000 seq=35165 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [4] ts=2649020 dur=160/160/2000 seq=35171 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=320/320/2000 seq=35172 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=480/480/2000 seq=35173 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=640/640/2000 seq=35174 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=800/800/2000 seq=35175 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=960/960/2000 seq=35176 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1120/1120/2000 seq=35177 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1280/1280/2000 seq=35178 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1440/1440/2000 seq=35179 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1600/1600/2000 seq=35180 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1760/1760/2000 seq=35181 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [4] ts=2649020 dur=1920/1920/2000 seq=35182 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [4] ts=2649020 dur=2080/2080/2000 seq=35183 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [4] ts=2649020 dur=2080/2080/2000 seq=35184 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [4] ts=2649020 dur=2080/2080/2000 seq=35185 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [5] ts=2651740 dur=160/160/2000 seq=35190 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=320/320/2000 seq=35191 2008-09-20 14:56:31 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=480/480/2000 seq=35192 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=640/640/2000 seq=35193 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=800/800/2000 seq=35194 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=960/960/2000 seq=35195 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1120/1120/2000 seq=35196 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1280/1280/2000 seq=35197 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1440/1440/2000 seq=35198 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1600/1600/2000 seq=35199 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1760/1760/2000 seq=35200 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [5] ts=2651740 dur=1920/1920/2000 seq=35201 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [5] ts=2651740 dur=2080/2080/2000 seq=35202 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [5] ts=2651740 dur=2080/2080/2000 seq=35203 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [5] ts=2651740 dur=2080/2080/2000 seq=35204 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [1] ts=2654460 dur=160/160/2000 seq=35210 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=320/320/2000 seq=35211 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=480/480/2000 seq=35212 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=640/640/2000 seq=35213 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=800/800/2000 seq=35214 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=960/960/2000 seq=35215 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1120/1120/2000 seq=35216 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1280/1280/2000 seq=35217 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1440/1440/2000 seq=35218 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1600/1600/2000 seq=35219 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1760/1760/2000 seq=35220 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send middle packet for [1] ts=2654460 dur=1920/1920/2000 seq=35221 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [1] ts=2654460 dur=2080/2080/2000 seq=35222 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [1] ts=2654460 dur=2080/2080/2000 seq=35223 2008-09-20 14:56:32 [DEBUG] switch_rtp.c:1143 do_2833() Send end packet for [1] ts=2654460 dur=2080/2080/2000 seq=35224 recv 1167 bytes from udp/[213.192.59.75]:5060 at 00:56:33.629938: ------------------------------------------------------------------------ BYE sip:mod_sofia@64.75.215.160:5060;transport=udp SIP/2.0 Record-Route: <sip:213.192.59.75;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Record-Route: <sip:213.192.59.75;transport=tcp;r2=on;avp=8XoDBwBhY2NvdW50AwB5ZXMBBwB1YWNfbmF0AQAAAAEHAHVhY19uYXQBAAAA;lr=on> Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK7a9e.2376fa26.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-065f7a431710dd13-1---d8754z- Max-Forwards: 16 Contact: <sip:matthewdarnell@66.8.218.137:51604;transport=TCP> To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 3 BYE Proxy-Authorization: Digest username="matthewdarnell",realm="iptel.org",nonce="SNWbxEjVm7o6R3qdBfGurqbPhiiBGN51",uri="sip:mod_sofia@64.75.215.160:5060;transport=udp",response="52564ae082d882bef9f77c6521f3a64c",algorithm=MD5 User-Agent: X-Lite release 1100l stamp 47546 Reason: SIP;description="User Hung Up" Content-Length: 0 P-hint: rr-enforced P-RTP-Proxy: UNFORCED ------------------------------------------------------------------------ send 661 bytes to udp/[213.192.59.75]:5060 at 00:56:33.630577: ------------------------------------------------------------------------ SIP/2.0 200 OK Via: SIP/2.0/UDP 213.192.59.75;branch=z9hG4bK7a9e.2376fa26.0;i=d86 Via: SIP/2.0/TCP 192.168.1.47:37440;rport=51604;received=66.8.218.137;branch=z9hG4bK-d8754z-065f7a431710dd13-1---d8754z- From: "matthewdarnell"<sip:matthewdarnell@iptel.org>;tag=8a095b76 To: "8084473453@vm.akamaitel.com"<sip:8084473453@vm.akamaitel.com>;tag=a9gB8pF2KSSca Call-ID: MDFlYTEyOGQyNmE0NWI4MTFlZDhkNGUwM2RjMzMyNjY. CSeq: 3 BYE User-Agent: FreeSWITCH-mod_sofia/1.0.1-exported Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, PRACK, MESSAGE, SUBSCRIBE, NOTIFY, REFER, UPDATE, REGISTER, INFO Supported: 100rel, timer, precondition, path, replaces Content-Length: 0 ------------------------------------------------------------------------ 2008-09-20 14:56:33 [DEBUG] sofia.c:2129 sofia_handle_sip_i_state() Channel sofia/external/matthewdarnell@iptel.org entering state [terminated] 2008-09-20 14:56:33 [NOTICE] sofia.c:2545 sofia_handle_sip_i_state() Hangup sofia/external/matthewdarnell@iptel.org [CS_EXECUTE] [NORMAL_CLEARING] 2008-09-20 14:56:33 [DEBUG] switch_channel.c:1361 switch_channel_perform_hangup() Kill sofia/external/matthewdarnell@iptel.org [KILL] 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:281 audio_bridge_thread() read: sofia/external/matthewdarnell@iptel.org Bad Frame.... Bubye! 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:350 audio_bridge_thread() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:353 audio_bridge_thread() BRIDGE THREAD DONE [sofia/external/matthewdarnell@iptel.org] 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:784 switch_ivr_multi_threaded_bridge() sofia/internal/3453 State Change CS_EXCHANGE_MEDIA -> CS_RESET 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:430 switch_core_session_receive_message() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:350 audio_bridge_thread() Kill sofia/external/matthewdarnell@iptel.org [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_ivr_bridge.c:353 audio_bridge_thread() BRIDGE THREAD DONE [sofia/internal/3453] 2008-09-20 14:56:33 [NOTICE] switch_ivr_bridge.c:382 audio_bridge_on_exchange_media() Hangup sofia/internal/3453 [CS_RESET] [NORMAL_CLEARING] 2008-09-20 14:56:33 [DEBUG] switch_channel.c:1361 switch_channel_perform_hangup() Kill sofia/internal/3453 [KILL] 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:722 switch_core_session_signal_state_change() Kill sofia/internal/3453 [BREAK] 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:433 switch_core_session_run() (sofia/internal/3453) State EXCHANGE_MEDIA going to sleep 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/internal/3453 Running State Change CS_HANGUP 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:393 switch_core_session_run() (sofia/internal/3453) State HANGUP 2008-09-20 14:56:33 [DEBUG] mod_sofia.c:230 sofia_on_hangup() sofia/internal/3453 Overriding SIP cause 480 with 200 from the other leg 2008-09-20 14:56:33 [DEBUG] mod_sofia.c:264 sofia_on_hangup() Channel sofia/internal/3453 hanging up, cause: NORMAL_CLEARING 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:430 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State EXECUTE going to sleep 2008-09-20 14:56:33 [DEBUG] mod_sofia.c:318 sofia_on_hangup() Sending BYE to sofia/internal/3453 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/internal/3453, cause: NORMAL_CLEARING 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:365 switch_core_session_run() sofia/external/matthewdarnell@iptel.org Running State Change CS_HANGUP 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:393 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State HANGUP 2008-09-20 14:56:33 [DEBUG] mod_sofia.c:264 sofia_on_hangup() Channel sofia/external/matthewdarnell@iptel.org hanging up, cause: NORMAL_CLEARING 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:46 switch_core_standard_on_hangup() Standard HANGUP sofia/external/matthewdarnell@iptel.org, cause: NORMAL_CLEARING 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:393 switch_core_session_run() (sofia/external/matthewdarnell@iptel.org) State HANGUP going to sleep 2008-09-20 14:56:33 [DEBUG] switch_core_state_machine.c:393 switch_core_session_run() (sofia/internal/3453) State HANGUP going to sleep 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:789 switch_core_session_thread() Session 7 (sofia/external/matthewdarnell@iptel.org) Locked, Waiting on external entities 2008-09-20 14:56:33 [NOTICE] switch_core_session.c:807 switch_core_session_thread() Session 7 (sofia/external/matthewdarnell@iptel.org) Ended 2008-09-20 14:56:33 [NOTICE] switch_core_session.c:809 switch_core_session_thread() Close Channel sofia/external/matthewdarnell@iptel.org [CS_HANGUP] 2008-09-20 14:56:33 [DEBUG] switch_core_session.c:789 switch_core_session_thread() Session 8 (sofia/internal/3453) Locked, Waiting on external entities 2008-09-20 14:56:33 [NOTICE] switch_core_session.c:807 switch_core_session_thread() Session 8 (sofia/internal/3453) Ended 2008-09-20 14:56:33 [NOTICE] switch_core_session.c:809 switch_core_session_thread() Close Channel sofia/internal/3453 [CS_HANGUP]
That will be interesting for me as well, Anthony. In the meantime, Matt, try applying this non-standard change (it worked for me). Change src/switch_rtp.c (lines 1197-1198) from: rtp_session->dtmf_data.out_digit_sofar = samples; rtp_session->dtmf_data.out_digit_sub_sofar = samples; to: rtp_session->dtmf_data.out_digit_sofar = 0; rtp_session->dtmf_data.out_digit_sub_sofar = 0; Let me know if that fixed your DTMF problem with your UM. -----Original Message----- From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Matt Darnell Sent: Sunday, September 21, 2008 11:04 AM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] Exchange 2007 UM - DTMF problem On Fri, Sep 19, 2008 at 3:05 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote:
post a trace of FS after pressing f8 from the cli detailing the entire call and we can have a look.
Anthony, Please find the trace in the email and attached. No virus found in this outgoing message. Checked by AVG - http://www.avg.com Version: 8.0.169 / Virus Database: 270.7.0/1679 - Release Date: 19/09/2008 15:54
In the meantime, Matt, try applying this non-standard change (it worked for me). Change src/switch_rtp.c (lines 1197-1198) from: rtp_session->dtmf_data.out_digit_sofar = samples; rtp_session->dtmf_data.out_digit_sub_sofar = samples; to: rtp_session->dtmf_data.out_digit_sofar = 0; rtp_session->dtmf_data.out_digit_sub_sofar = 0;
Let me know if that fixed your DTMF problem with your UM.
I made the change, did configure, make clean, make, & make install. I see this in the log now: 2008-09-20 16:54:32 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [3] ts=12560 dur=0/0/2000 seq=15883 Before the duration would start at 160/160/2000. Is that what I should see? It still doesn't solve the issue. It doesn't act like I would expect. The server either 'hears' digits on a call or it doesn't; I would expect it to miss digits every now and then, not either completely pass or completely fail. What type of DTMF failure were you experiencing? I wonder if it is not a Freeswitch issue but an Exchange issue, I will get a SIP/TCP softphone and try to connect directly to the Exchange server. I think SJPhone does SIP/TCP. -Matt
you can see in the trace that the exchange is using alaw. So the complaint about trans coding is because it's going from PCMU on leg a to PCMA when talking to exchange. please revert any changes, upgrade to current SVN trunk and try configuring exchange to use PCMA or confiigure FS to only use PCMA by editing vars.xml and making the codec_string be PMCA instead of PCMU On Sat, Sep 20, 2008 at 10:08 PM, Matt Darnell <mattdarnell@gmail.com>wrote:
In the meantime, Matt, try applying this non-standard change (it worked for me). Change src/switch_rtp.c (lines 1197-1198) from: rtp_session->dtmf_data.out_digit_sofar = samples; rtp_session->dtmf_data.out_digit_sub_sofar = samples; to: rtp_session->dtmf_data.out_digit_sofar = 0; rtp_session->dtmf_data.out_digit_sub_sofar = 0;
Let me know if that fixed your DTMF problem with your UM.
I made the change, did configure, make clean, make, & make install. I see this in the log now: 2008-09-20 16:54:32 [DEBUG] switch_rtp.c:1201 do_2833() Send start packet for [3] ts=12560 dur=0/0/2000 seq=15883 Before the duration would start at 160/160/2000. Is that what I should see?
It still doesn't solve the issue. It doesn't act like I would expect. The server either 'hears' digits on a call or it doesn't; I would expect it to miss digits every now and then, not either completely pass or completely fail.
What type of DTMF failure were you experiencing?
I wonder if it is not a Freeswitch issue but an Exchange issue, I will get a SIP/TCP softphone and try to connect directly to the Exchange server. I think SJPhone does SIP/TCP.
-Matt
_______________________________________________ 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/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
participants (8)
-
Anthony Minessale
-
Brian West
-
khushil.dep＠gmail.com
-
Matt Darnell
-
Michael Jerris
-
Steve Underwood
-
UV
-
UV