<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:lucida console, sans-serif;font-size:12pt"><DIV></DIV>
<DIV>dear all,</DIV>
<DIV> </DIV>
<DIV>does cisco IPCC 4.0(5)Express Standard can record misscalled from PSTN line?</DIV>
<DIV>if this things could, how do they do it?<BR> </DIV>GBU
<DIV></DIV><BR><BR>
<DIV>Regards,</DIV><BR><BR>
<DIV>Arnold Samuel Lesar</DIV><BR><BR>
<DIV>------------------------------------------------------<BR>Note: This message was created by ARNOLD SAMUEL LESAR.<BR>------------------------------------------------------</DIV><BR><BR>
<DIV>--------------------------------------------------------------------------<BR>--------------------------------------------------------------------------<BR>PT. PELITA RELIANCE INTERNATIONAL<BR>Eka Hospital BSD City, Tangerang <BR>Address : CBD Lot IX, BSD City, Tangerang <BR>Phone : (+62-21) 256 555 55 <BR>Fax : (+62-21) 256 555 44 <BR>--------------------------------------------------------------------------<BR>--------------------------------------------------------------------------
<DIV><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: lucida console, sans-serif"><BR>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> "cisco-voip-request@puck.nether.net" <cisco-voip-request@puck.nether.net><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> cisco-voip@puck.nether.net<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Wednesday, 28 October, 2009 23:00:02<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> cisco-voip Digest, Vol 72, Issue 28<BR></FONT><BR>Send cisco-voip mailing list submissions to<BR> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><BR>To subscribe or unsubscribe via the World Wide Web, visit<BR> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>or, via email, send a message with subject or body 'help' to<BR> <A href="mailto:cisco-voip-request@puck.nether.net"
ymailto="mailto:cisco-voip-request@puck.nether.net">cisco-voip-request@puck.nether.net</A><BR><BR>You can reach the person managing the list at<BR> <A href="mailto:cisco-voip-owner@puck.nether.net" ymailto="mailto:cisco-voip-owner@puck.nether.net">cisco-voip-owner@puck.nether.net</A><BR><BR>When replying, please edit your Subject line so it is more specific<BR>than "Re: Contents of cisco-voip digest..."<BR><BR><BR>Today's Topics:<BR><BR> 1. Re: FXO hookflash / conferencing - CM 7.1 (Jack Martin)<BR> 2. Re: FXO hookflash / conferencing - CM 7.1 (Ryan West)<BR> 3. ATA firmware update (Robert Singleton)<BR> 4. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 5. Re: UCCX Script (Jim Reed)<BR> 6. Re: Problem using pitney bowes postage machine (Norton, Mike)<BR> 7. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)<BR> 8. Re: FXO port Attendant DN won't ring Hunt Pilot
(Norton, Mike)<BR> 9. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)<BR> 10. Interpret CDR Search Results (Jeff Ruttman)<BR> 11. Re: Interpret CDR Search Results (Ryan Ratliff)<BR> 12. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 13. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)<BR> 14. Re: Interpret CDR Search Results (Jeff Ruttman)<BR> 15. Re: Interpret CDR Search Results (Ryan Ratliff)<BR> 16. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 17. Cisco 7961 - Wrong Time, No Local Directory, No Services<BR> (Jeff Cartier)<BR> 18. What am I missing with Background images? (Scott Voll)<BR> 19. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)<BR> 20. Re: Cisco 7961 - Wrong Time, No Local Directory, No Services<BR> (Ryan Ratliff)<BR>
21. Re: What am I missing with Background images? (Ryan Ratliff)<BR> 22. Re: What am I missing with Background images? (Joe Pollere (US))<BR> 23. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 24. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)<BR> 25. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 26. answer: Re: What am I missing with Background images? (Scott Voll)<BR> 27. SIP phones and caller ID (Philip Walenta)<BR> 28. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 29. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)<BR> 30. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 31. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)<BR> 32. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)<BR> 33. Re: CUPC troubleshooting tips? (Dana Tong (AU))<BR> 34. Re: CUPC
troubleshooting tips? (Dana Tong (AU))<BR> 35. Re: 7960 to SIP server (Kelemen Zolt?n)<BR> 36. LDAP Sync vs AD Integration (c3voip)<BR> 37. Re: LDAP Sync vs AD Integration (Scott Voll)<BR> 38. Mobility Calls: Transform Internal Extensions to DIDs<BR> (Matthew Loraditch)<BR><BR><BR>----------------------------------------------------------------------<BR><BR>Message: 1<BR>Date: Tue, 27 Oct 2009 11:24:19 -0500<BR>From: Jack Martin <<A href="mailto:jackm@tushaus.com" ymailto="mailto:jackm@tushaus.com">jackm@tushaus.com</A>><BR>To: Ryan West <<A href="mailto:rwest@zyedge.com" ymailto="mailto:rwest@zyedge.com">rwest@zyedge.com</A>>, "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>"<BR> <<A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] FXO hookflash / conferencing - CM 7.1<BR>Message-ID: <102128A0-EF02-4820-8E10-DB4609F2DA82@mimectl><BR>Content-Type: text/plain; charset="Windows-1252"<BR><BR>I believe what you are describing is expected behavior of a line appearancve configured with hookflash.<BR><BR>Are you trying the ad-hoc conference from the same line appearence? Is the CME configured as a key-system?<BR><BR>If you park the first outbound call then place a second outbound call, are you able to conference in the parked call?<BR><BR><BR>Jack Martin, CCVP<BR>Network Engineer<BR>Tushaus Computer Services<BR>10400 Innovation Drive, Ste 100<BR>Milwaukee, WI 53226<BR>414.908.2222 Helpdesk<BR>414.908.2267 Work<BR>414.908.4467 Fax<BR>________________________________<BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net"
ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Ryan West [<A href="mailto:rwest@zyedge.com" ymailto="mailto:rwest@zyedge.com">rwest@zyedge.com</A>]<BR>Sent: Tuesday, October 27, 2009 1:17 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] FXO hookflash / conferencing - CM 7.1<BR><BR>Hello,<BR><BR>I?m running into an issue 7.1 that seemed pretty easy at first, but I?m hitting a wall now. We have a remote site that had poor Internet connectivity and decided to go with an 881 with local FXO resources and H323 back to the CM. The lines were ordered by the customer with call-waiting and caller-id on the call-waiting line. The issue is with
inbound call-waiting, the customer can hear the inbound call, but cannot pick it up. With CME, you could implement the FLASH softkey and simulate the POTS behavior. TAC has directed me to the following bug / feature request that has existed since 3.1(1) <A href="http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088" target=_blank>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088</A> . As for the conferencing portion, does CM also have problem initiating a ?3-way? call? It seems I can make an outbound FXO call and then conference in an on-net call, but I can?t make two outbound calls.<BR><BR>Thanks,<BR><BR>-ryan<BR><BR><BR>------------------------------<BR><BR>Message: 2<BR>Date: Tue, 27 Oct 2009 12:26:31 -0400<BR>From: Ryan West <<A href="mailto:rwest@zyedge.com"
ymailto="mailto:rwest@zyedge.com">rwest@zyedge.com</A>><BR>To: Jack Martin <<A href="mailto:jackm@tushaus.com" ymailto="mailto:jackm@tushaus.com">jackm@tushaus.com</A>>, "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>"<BR> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] FXO hookflash / conferencing - CM 7.1<BR>Message-ID:<BR> <<A href="mailto:6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF437A@zy-ex1.zyedge.local" ymailto="mailto:6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF437A@zy-ex1.zyedge.local">6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF437A@zy-ex1.zyedge.local</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Jack,<BR><BR>>From what I've read this seems to be not an issue on a CME router. However, I'm on CM 7.1.2 and the
881SRST is H323. The endpoints are 7960's at the remote location. To answer your question though, yes I'm trying to ad-hoc conference. As far as initiating hookflash, I don't seem to be able configure this as phone button item in CM.<BR><BR>Thanks!<BR><BR>-ryan<BR><BR>-----Original Message-----<BR>From: Jack Martin [mailto:<A href="mailto:jackm@tushaus.com" ymailto="mailto:jackm@tushaus.com">jackm@tushaus.com</A>] <BR>Sent: Tuesday, October 27, 2009 12:24 PM<BR>To: Ryan West; <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: RE: FXO hookflash / conferencing - CM 7.1<BR><BR>I believe what you are describing is expected behavior of a line appearancve configured with hookflash.<BR><BR>Are you trying the ad-hoc conference from the same line appearence? Is the CME configured as a key-system?<BR><BR>If you park the first outbound call then place a second
outbound call, are you able to conference in the parked call?<BR><BR><BR>Jack Martin, CCVP<BR>Network Engineer<BR>Tushaus Computer Services<BR>10400 Innovation Drive, Ste 100<BR>Milwaukee, WI 53226<BR>414.908.2222 Helpdesk<BR>414.908.2267 Work<BR>414.908.4467 Fax<BR>________________________________<BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Ryan West [<A href="mailto:rwest@zyedge.com" ymailto="mailto:rwest@zyedge.com">rwest@zyedge.com</A>]<BR>Sent: Tuesday, October 27, 2009 1:17 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] FXO hookflash / conferencing - CM 7.1<BR><BR>Hello,<BR><BR>I'm
running into an issue 7.1 that seemed pretty easy at first, but I'm hitting a wall now. We have a remote site that had poor Internet connectivity and decided to go with an 881 with local FXO resources and H323 back to the CM. The lines were ordered by the customer with call-waiting and caller-id on the call-waiting line. The issue is with inbound call-waiting, the customer can hear the inbound call, but cannot pick it up. With CME, you could implement the FLASH softkey and simulate the POTS behavior. TAC has directed me to the following bug / feature request that has existed since 3.1(1) <A href="http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088" target=_blank>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088</A> . As for the conferencing portion, does CM also have problem initiating a "3-way"
call? It seems I can make an outbound FXO call and then conference in an on-net call, but I can't make two outbound calls.<BR><BR>Thanks,<BR><BR>-ryan<BR><BR><BR>------------------------------<BR><BR>Message: 3<BR>Date: Tue, 27 Oct 2009 11:48:31 -0500<BR>From: Robert Singleton <<A href="mailto:rsingleton@morsco.com" ymailto="mailto:rsingleton@morsco.com">rsingleton@morsco.com</A>><BR>To: voip puck <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] ATA firmware update<BR>Message-ID: <<A href="mailto:4AE7245F.40808@morsco.com" ymailto="mailto:4AE7245F.40808@morsco.com">4AE7245F.40808@morsco.com</A>><BR>Content-Type: text/plain; charset=ISO-8859-1; format=flowed<BR><BR>Greetings, All!<BR><BR>I have several ATA188s in the field that have never updated firmware, <BR>although most have. I have never been able to figure out why some
<BR>updated and others did not and more importantly, why some will decide to <BR>update suddenly months later.<BR><BR>The older ones are running v3.1.0, which has ethernet ports fixed at <BR>100Mb. The updated ones are running v3.02.03, which has ethernet ports <BR>fixed at 10Mb. Normally, the port speed doesn't matter because they are <BR>generally connected to switches that auto detect speed. In one <BR>particular case today, however, I have four ATAs that are daisy chained <BR>together and it appears that the 2nd in the string has updated, so it <BR>and the 2 behind it cannot register. The first in the chain is still <BR>running the older firmware.<BR><BR>The question is, how can I force an ATA to update, preferably *without* <BR>having to have someone at the branch find a telephone to plug in and use <BR>the voice menus? I will be able to have someone move ethernet cabling <BR>around, so I can have them connect each ATA to the switch port
<BR>individually, but how can I make it update on demand?<BR><BR>Thanks!<BR><BR>Robert<BR><BR>-- <BR>Robert Singleton<BR>817-259-0955 desk<BR>817-538-2286 mobile<BR><BR><BR>------------------------------<BR><BR>Message: 4<BR>Date: Tue, 27 Oct 2009 12:56:40 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910270956m1c0f2044kbb5f291d119f31d8@mail.gmail.com"
ymailto="mailto:a54820e50910270956m1c0f2044kbb5f291d119f31d8@mail.gmail.com">a54820e50910270956m1c0f2044kbb5f291d119f31d8@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Well I tried to switch providers just to test it out and now I am getting<BR>something back in the 183 but still no dtmf hmm<BR><BR>I see they are sending me<BR><BR>m=audio 11680 RTP/AVP 0 101<BR><BR>How do I interperate that line?<BR><BR><BR>Received:<BR>SIP/2.0 183 Session Progress<BR>Via: SIP/2.0/UDP 173.14.220.57:5060<BR>;branch=z9hG4bK749136B;received=173.14.220.57<BR>From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A> <sip%<A href="mailto:3A6782282221@did.voip.les.net" ymailto="mailto:3A6782282221@did.voip.les.net">3A6782282221@did.voip.les.net</A>><BR>>;tag=419FE94-8A1<BR>To: <sip:<A href="mailto:18774675464@did.voip.les.net"
ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A> <sip%<A href="mailto:3A18774675464@did.voip.les.net" ymailto="mailto:3A18774675464@did.voip.les.net">3A18774675464@did.voip.les.net</A>><BR>>;tag=as5677a12c<BR>Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>CSeq: 101 INVITE<BR>User-Agent: LES.NET.VoIP<BR>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>Contact: <sip:18774675464@64.34.181.47 <sip%3A18774675464@64.34.181.47>><BR>Content-Type: application/sdp<BR>Content-Length: 214<BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:<BR>INVITE response with no RSEQ - disable IS_REL1XX<BR>*Oct 27 18:02:12.551:
//-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No GTD<BR>found in inbound container<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation:<BR>Number of m-lines = 1<BR>SIP: Attribute mid, level 1 instance 1 not found.<BR>*Oct 27 18:02:12.551:<BR>//1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already<BR>bound, use existing source_media_ip_addr<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:<BR>Media src addr for stream 1 = 173.14.220.57<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation:<BR>Codec (g711ulaw) Negotiation Successful on Static Payload for m-line 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation:<BR>No ptime present or multiple ptime attributes that can't be handled<BR>*Oct 27 18:02:12.551:<BR>//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>*Oct 27 18:02:12.551:
//1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse:<BR>Dynamic payload(101) could not be reserved.<BR>*Oct 27 18:02:12.551:<BR>//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>relay option<BR>*Oct 27 18:02:12.555:<BR>//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>named event(NE) match in fmtp list of events.<BR>*Oct 27 18:02:12.555:<BR>//-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload<BR>from X-cap = 0<BR>*Oct 27 18:02:12.555:<BR>//1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>present in SDP. Disable modem relay<BR>*Oct 27 18:02:12.555:<BR>//1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction<BR>attribute present or multiple direction attributes that can't be handled for<BR>m-line:1 and num-a-lines:0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation:<BR>Codec negotiation successful for media line
1<BR> payload_type=0, codec_bytes=160, codec=g711ulaw, dtmf_relay=rtp-nte<BR> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,<BR>dest_port=11680<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/sipSPIChangeStreamState:<BR>Stream (callid = -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)<BR>*Oct 27 18:02:12.555:<BR>//1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR> Preferred Codec : g711ulaw, bytes :160<BR> Preferred DTMF relay : rtp-nte<BR> Preferred NTE payload : 101<BR> Early Media : No<BR> Delayed Media : No<BR> Bridge Done :
No<BR> New Media : No<BR> DSP DNLD Reqd : No<BR><BR>On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR><BR>> The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>> a 200 OK with the CSeq for 101 INVITE.<BR>><BR>> I've seen this for certain IVRs/providers - sometimes they don't<BR>> properly terminate a call with a 200 OK. If you were not sending an<BR>> SDP in your original INVITE, then you would need the PRACK setting<BR>> mentioned. You have two problems, either could fix the problem: They<BR>> could advertise DTMF in their 183, or they could send you a 200 OK
for<BR>> the call. It is assumed you would get DTMF in the 200 OK. It's<BR>> common for endpoints that support DTMF to not advertise it in the 183<BR>> because you technically shouldn't need DTMF to hear ringback.<BR>><BR>> -nick<BR>><BR>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR>> > There is no SDP in that 200 OK so I would assume the media info is the<BR>> same<BR>> > as in the 183 Ringing message. You really need your ITSP to tell you<BR>> what<BR>> > dtmf method they want you to use on your outbound calls. As Nick said<BR>> they<BR>> > don't appear to be advertising any dtmf method at all.<BR>> > -Ryan<BR>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>> > Is the below the ok I should be getting?<BR>> ><BR>>
><BR>> > They did send this with the first debug<BR>> ><BR>> > Received:<BR>> > SIP/2.0 200 OK<BR>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=32DA608-109A<BR>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>> > CSeq: 102 CANCEL<BR>> > Content-Length: 0<BR>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:<BR>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> > *Oct 27 13:44:12.828:
//922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>> > *Oct 27 13:44:12.836:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> > *Oct 27 13:44:12.840:<BR>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> > *Oct 27 13:44:12.840:<BR>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> > context=0x00000000<BR>> > *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> > Checking Invite Dialog<BR>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> ><BR>> > This with the 2nd debug<BR>> ><BR>> > Received:<BR>> > SIP/2.0 200 OK<BR>> > Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> > CSeq: 102 CANCEL<BR>> > Content-Length: 0<BR>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> > *Oct 27 12:34:15.912:<BR>>
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> > *Oct 27 12:34:15.912:<BR>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> > *Oct 27 12:34:15.912:<BR>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> > context=0x00000000<BR>> > *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> > Checking Invite Dialog<BR>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> > Received:<BR>> > SIP/2.0 487 Request Terminated<BR>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>> >;tag=3465630735-938664<BR>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> > CSeq: 102 INVITE<BR>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> > Content-Length: 0<BR>> ><BR>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>> wrote:<BR>> >><BR>> >> In the 183 Session Progress they're not advertising DTMF:<BR>> >><BR>> >> m=audio 45846 RTP/AVP 0<BR>> >><BR>> >> There should be a 100 or 101 there. Although, 183 is just
ringback.<BR>> >> You would want to pick up on the other side and they should send a 200<BR>> >> OK with a new SDP. If the other side did pick up, you need to tell<BR>> >> the provider that they need to send a 200 OK, because they're not.<BR>> >><BR>> >><BR>> >> -nick<BR>> >><BR>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> >> wrote:<BR>> >> > Nick<BR>> >> ><BR>> >> > I removed voice-class sip asymmetric payload dtmf and added in the<BR>> >> > other<BR>> >> > line<BR>> >> ><BR>> >> > Just to state incoming dtmf works but not outbound the ITSP has told<BR>> me<BR>> >> > they<BR>> >> > are using two different sip servers/vendors for
processing inbound and<BR>> >> > outbound<BR>> >> > How does this translate into what I should sent the following too?<BR>> >> ><BR>> >> > rtp payload-type nse<BR>> >> > rtp payload-type nte<BR>> >> ><BR>> >> > In the debug trhe following where set<BR>> >> ><BR>> >> > rtp payload-type nse 101<BR>> >> > rtp payload-type nte 100<BR>> >> ><BR>> >> > In the debug of ccsip If I am looking at it correctly I see me sending<BR>> >> > this<BR>> >> ><BR>> >> > *Oct 27 12:34:09.128:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>> >> > Preferred method of dtmf relay is: 6, with payload: 100<BR>> >> > *Oct 27 12:34:09.128:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>> >>
> max_event 15<BR>> >> ><BR>> >> > and<BR>> >> ><BR>> >> ><BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>> >> > payload<BR>> >> > from X-cap = 0<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>> >> > present<BR>> >> > in SDP. Disable modem relay<BR>> >> ><BR>> >> ><BR>> >> > Sent:<BR>> >> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>> >> > Remote-Party-ID:<BR>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>> >;party=calling;screen=yes;privacy=off<BR>> >> > From:
<sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>> >> > Min-SE: 1800<BR>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>> >> > SUBSCRIBE,<BR>> >> > NOTIFY, INFO,
REGISTER<BR>> >> > CSeq: 101 INVITE<BR>> >> > Max-Forwards: 70<BR>> >> > Timestamp: 1256646849<BR>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>> >> > Expires: 180<BR>> >> > Allow-Events: telephone-event<BR>> >> > Content-Type: application/sdp<BR>> >> > Content-Disposition: session;handling=required<BR>> >> > Content-Length: 250<BR>> >> > v=0<BR>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>> >> > s=SIP Call<BR>> >> > c=IN IP4 173.14.220.57<BR>> >> > t=0 0<BR>> >> > m=audio 16462 RTP/AVP 0 100<BR>> >> > c=IN IP4 173.14.220.57<BR>> >> > a=rtpmap:0 PCMU/8000<BR>> >> > a=rtpmap:100 telephone-event/8000<BR>> >> > a=fmtp:100 0-15<BR>> >> > a=ptime:20<BR>> >> ><BR>>
>> ><BR>> >> > Then when I do a search for fmtp again further down I see<BR>> >> ><BR>> >> > Sent:<BR>> >> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> >> > Remote-Party-ID:<BR>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>> >;party=calling;screen=yes;privacy=off<BR>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> >> > Date: Tue, 27 Oct 2009 12:34:09
GMT<BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>> >> > Min-SE: 1800<BR>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>> >> > SUBSCRIBE,<BR>> >> > NOTIFY, INFO, REGISTER<BR>> >> > CSeq: 102 INVITE<BR>> >> > Max-Forwards: 70<BR>> >> > Timestamp: 1256646849<BR>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>> >> > Expires: 180<BR>> >> > Allow-Events: telephone-event<BR>> >> > Proxy-Authorization: Digest<BR>> >> ><BR>> >> > username="1648245954",realm="64.154.41.110",uri="<BR>>
sip:18774675464@64.154.41.200:5060<BR>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>> >> > Content-Type: application/sdp<BR>> >> > Content-Disposition: session;handling=required<BR>> >> > Content-Length: 250<BR>> >> > v=0<BR>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>> >> > s=SIP Call<BR>> >> > c=IN IP4 173.14.220.57<BR>> >> > t=0 0<BR>> >> > m=audio 16462 RTP/AVP 0 100<BR>> >> > c=IN IP4 173.14.220.57<BR>> >> > a=rtpmap:0 PCMU/8000<BR>> >> > a=rtpmap:100 telephone-event/8000<BR>> >> > a=fmtp:100 0-15<BR>> >> > a=ptime:20<BR>> >> > *Oct 27 12:34:09.332:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> >> > Msg enqueued for SPI with
IP addr: [64.154.41.200]:5060<BR>> >> > *Oct 27 12:34:09.332:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> >> > *Oct 27 12:34:09.332:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> >> > context=0x00000000<BR>> >> > *Oct 27 12:34:09.332:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> >> > Checking Invite Dialog<BR>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> >> > Received:<BR>> >> > SIP/2.0 100 Trying<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > CSeq: 102 INVITE<BR>> >> > Content-Length: 0<BR>> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to<BR>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>> >> > *Oct
27 12:34:10.832:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> >> > *Oct 27 12:34:10.832:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> >> > *Oct 27 12:34:10.832:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> >> > context=0x00000000<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> >> > Checking Invite Dialog<BR>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> >> > Received:<BR>> >> > SIP/2.0 183 Session Progress<BR>> >> > To: <sip:18774675464@64.154.41.200
<sip%3A18774675464@64.154.41.200><BR>> >;tag=3465630735-938664<BR>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > Contact: <sip:18774675464@64.154.41.200:5060><BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > CSeq: 102 INVITE<BR>> >> > Content-Type: application/sdp<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> >> > Content-Length: 146<BR>> >> > v=0<BR>> >> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>> >> > s=sip call<BR>> >> > c=IN IP4 64.154.41.101<BR>> >> > t=0
0<BR>> >> > m=audio 45846 RTP/AVP 0<BR>> >> > a=ptime:20<BR>> >> > a=rtpmap:0 PCMU/8000<BR>> >> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:<BR>> No<BR>> >> > GTD<BR>> >> > found in inbound container<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>> >> > Number of m-lines = 1<BR>> >> > SIP: Attribute mid, level 1 instance 1 not found.<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>> >> > already<BR>> >> > bound, use existing source_media_ip_addr<BR>> >> > *Oct 27
12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>> >> > Media src addr for stream 1 = 173.14.220.57<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line 1<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>> >> > One ptime attribute found - value:20<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values<BR>> :Codec:<BR>> >> > g711ulaw ptime :20, codecbytes: 160<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>> :Codec:<BR>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>
>> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160 for<BR>> >> > codec<BR>> >> > g711ulaw<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index<BR>> 1<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>> >> > Dynamic payload(100) could not be reserved.<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>> >> > named<BR>> >> > event(NE) match in fmtp list of events.<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>
>> > payload<BR>> >> > from X-cap = 0<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>> >> > present<BR>> >> > in SDP. Disable modem relay<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No<BR>> direction<BR>> >> > attribute present or multiple direction attributes that can't be<BR>> handled<BR>> >> > for<BR>> >> > m-line:1 and num-a-lines:0<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>> >> > Codec negotiation successful for media line 1<BR>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>> >> > dtmf_relay=rtp-nte<BR>> >> >
stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>> >> > dest_port=45846<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>> >> > (STREAM_ADDING)<BR>> >> > *Oct 27 12:34:10.836:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>> >> > Preferred Codec : g711ulaw, bytes :160<BR>> >> > Preferred DTMF relay : rtp-nte<BR>> >> > Preferred NTE payload : 100<BR>> >> > Early Media : No<BR>> >> > Delayed Media
: No<BR>> >> > Bridge Done : No<BR>> >> > New Media : No<BR>> >> > DSP DNLD Reqd : No<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>> >> > already<BR>> >> > bound, use existing source_media_ip_addr<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>> >> > Media src addr for stream 1 = 173.14.220.57<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>
>> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>> >> > callId 846 size 240 ptr 0x4A170B28)<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>> >> > Hndl ptype 0 mline 1<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>> >> > Selecting<BR>> >> > codec g711ulaw<BR>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>> >> > Codec to be matched: 5<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD<BR>> >> > AUDIO<BR>> >> > CODEC 5<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>> :Codec:<BR>> >> > g711ulaw codecbytes :160, ptime: 20<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Media<BR>> >> > negotiation done:<BR>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,<BR>> coverted<BR>> >> > ptime=20 stream->mline_index=1, media_ndx=1<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1<BR>> >> > 64.154.41.101:45846<BR>>
>> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy<BR>> >> > sdp to<BR>> >> > channel- AFTER CODEC FILTERING:<BR>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy<BR>> >> > sdp to<BR>> >> > channel- AFTER CODEC FILTERING:<BR>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>> >> > Report initial call
media<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>> ccb->flags<BR>> >> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>> >> > callId 846 size 240 ptr 0x4DEC000C)<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>> >> > 5030: Posting Remote SRTP caps to other callleg.<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>> >> > cc_api_caps_ind()<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>> >> > Stream type :
voice+dtmf<BR>> >> > Media line : 1<BR>> >> > State : STREAM_ADDING (2)<BR>> >> > Stream address type : 1<BR>> >> > Callid : 846<BR>> >> > Negotiated Codec : g711ulaw, bytes :160<BR>> >> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>> >> > Negotiated DTMF relay : rtp-nte<BR>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)<BR>> >> > Negotiated
CN payload : 0<BR>> >> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>> >> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>> >> > headers<BR>> >> > recvd from app container<BR>> >> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:<BR>> >> > No<BR>> >> > QSIG Body found in inbound container<BR>> >> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:<BR>> >> > No<BR>> >> > RawMsg Body found in inbound container<BR>> >> > *Oct 27 12:34:10.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:<BR>> >> > No<BR>> >> > Data to form The
Raw Message<BR>> >> > *Oct 27 12:34:10.840:<BR>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>> >> > SUBSTATE_NONE)<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction<BR>> >> > Complete. Lock on Facilities released.<BR>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: confID<BR>> =<BR>> >> > 6,<BR>> >> > srcCallID = 846, dstCallID = 845<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> >
//846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>> >> > Old streamcallid=846, new streamcallid=846<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>> >> > Setting SPI mode to SIP-H323<BR>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = 1131891908<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>> >> > sipSPIProcessRtpSessions<BR>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:<BR>> >> > Adding<BR>>
>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>> >> > already<BR>> >> > bound, use existing source_media_ip_addr<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>> >> > Media src addr for stream 1 = 173.14.220.57<BR>> >> > *Oct 27 12:34:10.844:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>> >> > sipSPIUpdateRtcpSession for m-line 1<BR>> >> > *Oct 27 12:34:10.848:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>> >> > rtcp_session info<BR>> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,<BR>> >> >
rport=45846, do_rtcp=TRUE<BR>> >> > src_callid = 846, dest_callid = 845, stream type = voice+dtmf,<BR>> >> > stream direction = SENDRECV<BR>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0 media_addr_type<BR>> =<BR>> >> > 1<BR>> >> > *Oct 27 12:34:10.848:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>> >> > RTP session already created - update<BR>> >> > *Oct 27 12:34:10.848:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>> >> > stun is disabled for stream:4A1709F8<BR>> >> > *Oct 27 12:34:10.848:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>> >> > New Remote Media Direction = SENDRECV<BR>> >> > Present
Local Media Direction = SENDRECV<BR>> >> > New Local Media Direction = SENDRECV<BR>> >> > retVal = 0<BR>> >> > *Oct 27 12:34:10.848:<BR>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>> >> > (STREAM_ACTIVE)<BR>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge: really<BR>> >> > can't<BR>> >> > find peer_stream for<BR>> >> > dtmf-relay<BR>> interworking<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> Entry<BR>> >> > *Oct 27
12:34:11.140:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: CURRENT<BR>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>> >> > *Oct 27 12:34:11.140:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>> >> > VALUES:<BR>> >> > stream_callid=846, current_seq_num=0x11D9<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load<BR>> >> > DSP<BR>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set<BR>> >> > forking flag to 0x0<BR>> >> > *Oct 27 12:34:11.140:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx payload<BR>> =<BR>> >> >
100, tx payload = 100<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>> >> > config=0<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Disabling Modem Relay...<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>> >> > Xcap<BR>> >> > list<BR>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Modem<BR>> >> > Relay & Passthru both disabled<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > nse<BR>> >> > payload = 0, ptru mode = 0, ptru-codec=0,
redundancy=0, xid=0,<BR>> relay=0,<BR>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>> >> > *Oct 27 12:34:11.144:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > 1<BR>> >> > Active Streams<BR>> >> > *Oct 27 12:34:11.144:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > Adding stream type (voice+dtmf) from media<BR>> >> > line 1 codec g711ulaw<BR>> >> > *Oct 27 12:34:11.144:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>> >> > caps.stream_list.xmitFunc=<BR>> >> > *Oct 27 12:34:11.144:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>> >> > *Oct 27 12:34:11.144:<BR>>
//846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > 0x497E0B60 (gccb)<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load<BR>> >> > DSP<BR>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>> >> > video<BR>> >> > caps detected in the caps posted by peer leg<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> >> > Setting<BR>> >> > CAPS_RECEIVED flag<BR>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> >> > Calling<BR>> >> > cc_api_caps_ack()<BR>> >> > *Oct
27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack: Set<BR>> >> > forking flag to 0x0<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> Entry<BR>> >> > *Oct 27 12:34:11.168:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: CURRENT<BR>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>> >> > *Oct 27 12:34:11.168:<BR>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>> >> > VALUES:<BR>> >> > stream_callid=846, current_seq_num=0x11D9<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load<BR>> >> > DSP<BR>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set<BR>> >> > forking flag to
0x0<BR>> >> > *Oct 27 12:34:11.168:<BR>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx payload<BR>> =<BR>> >> > 100, tx payload = 100<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>> >> > config=0<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Disabling Modem Relay...<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>> >> > Xcap<BR>> >> > list<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >>
> Modem<BR>> >> > Relay & Passthru both disabled<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>> >> > nse<BR>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>> relay=0,<BR>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>> >> > *Oct 27 12:34:11.168:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > 1<BR>> >> > Active Streams<BR>> >> > *Oct 27 12:34:11.168:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > Adding stream type (voice+dtmf) from media<BR>> >> > line 1 codec g711ulaw<BR>> >> > *Oct 27 12:34:11.168:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>> >> >
caps.stream_list.xmitFunc=<BR>> >> > *Oct 27 12:34:11.168:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>> >> > *Oct 27 12:34:11.168:<BR>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>> >> > 0x497E0B60 (gccb)<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load<BR>> >> > DSP<BR>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>> >> > video<BR>> >> > caps detected in the caps posted by peer leg<BR>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>
Second<BR>> >> > TCS<BR>> >> > received for transfers across trunk - set CAPS2_RECEIVED<BR>> >> > *Oct 27 12:34:15.876:<BR>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>> >> > stun is disabled for stream:4A1709F8<BR>> >> > *Oct 27 12:34:15.876:<BR>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:<BR>> >> > Stats are not supported for IPIP call.<BR>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>> >> > Queued<BR>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> >> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:<BR>> >> > Associated
container=0x4E310C1C to Cancel<BR>> >> > *Oct 27 12:34:15.880:<BR>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:<BR>> >> > Sending CANCEL to the transport layer<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>> >> > msg=0x4DF0D994,<BR>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,<BR>> >> > switch=0, callBack=0x419703BC<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>> Proceedable<BR>> >> > for<BR>> >> > sending msg immediately<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>> >> > transport<BR>> >> > is 0<BR>> >> > *Oct 27 12:34:15.880:<BR>>
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to send<BR>> >> > the<BR>> >> > msg=0x4DF0D994<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting<BR>> >> > send<BR>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP<BR>> >> > *Oct 27 12:34:15.880:<BR>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>> >> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, SUBSTATE_NONE)<BR>> >> > to<BR>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> >>
> Sent:<BR>> >> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > CSeq: 102 CANCEL<BR>> >> > Max-Forwards: 70<BR>> >> > Timestamp: 1256646855<BR>> >> > Reason: Q.850;cause=16<BR>> >> > Content-Length: 0<BR>> >> > *Oct
27 12:34:15.900:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> >> > *Oct 27 12:34:15.900:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> >> > *Oct 27 12:34:15.900:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> >> > context=0x00000000<BR>> >> > *Oct 27 12:34:15.900:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> >> > Checking Invite Dialog<BR>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> >> > Received:<BR>> >> > SIP/2.0 200 OK<BR>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> >> > From:
<sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>> >;tag=2EDA9C8-25D6<BR>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> >> > CSeq: 102 CANCEL<BR>> >> > Content-Length: 0<BR>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> >> > *Oct 27 12:34:15.912:<BR>> >>
> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> >> > *Oct 27 12:34:15.912:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>> >> > *Oct 27 12:34:15.912:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> >> > context=0x00000000<BR>> >> > *Oct 27 12:34:15.912:<BR>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>> >> > Checking Invite Dialog<BR>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> >> ><BR>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>
>> > wrote:<BR>> >> >><BR>> >> >> You would want to check the SDP of 200 OK the provider sends for your<BR>> >> >> outgoing call. It will list the payload type for the dtmf in the<BR>> >> >> format a=fmtp 101 1-16, or something similar. You want to find out<BR>> >> >> what payload type they are advertising (or if they are at all). It<BR>> >> >> would be worth checking the incoming INVITE from them to see what<BR>> >> >> they're using when they send the first SDP.<BR>> >> >><BR>> >> >> On that note, I would also remove the asymmetric payload command - to<BR>> >> >> my knowledge it doesn't do what you're expecting it to. You may want<BR>> >> >> to try this command:<BR>> >> >> voice-class sip dtmf-relay force rtp-nte<BR>> >>
>><BR>> >> >><BR>> >> >> -nick<BR>> >> >><BR>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> >> >> wrote:<BR>> >> >> > Hello,<BR>> >> >> ><BR>> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf<BR>> works<BR>> >> >> > fine.<BR>> >> >> > It took some playing around with it. At first it didnt work till<BR>> the<BR>> >> >> > payload was ajusted. I am now trying to get outbound dtmf<BR>> working<BR>> >> >> > properly.<BR>> >> >> ><BR>> >> >> > On my 2821 I debugged voip rtp session named-events and then made a<BR>> >> >> >
call<BR>> >> >> > to<BR>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on the<BR>> >> >> > router<BR>> >> >> > nothing showed up in the debug. Does this mean I can safely asume<BR>> >> >> > that<BR>> >> >> > the<BR>> >> >> > problem for right now is not on the ITSP side but on my side since<BR>> >> >> > dtmf<BR>> >> >> > is<BR>> >> >> > not being sent down the sip trunk?<BR>> >> >> ><BR>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>> >> >> > configuration<BR>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas what<BR>> I<BR>> >> >> > can<BR>> >> >> > do<BR>> >>
>> > so dtmf digits process properly outbound?<BR>> >> >> ><BR>> >> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>> >> >> ><BR>> >> >> > h323 cucm gateway configuratration<BR>> >> >> > Signaling Port 1720<BR>> >> >> > media termination point required yes<BR>> >> >> > retry video call as auto yes<BR>> >> >> > wait for far end h.245 terminal capability set yes<BR>> >> >> > transmit utf-8 calling party name no<BR>> >> >> > h.235 pass through allowed no<BR>> >> >> > significant digits all<BR>> >> >> > redirect number IT deliver - inbound no<BR>> >> >> > enable inbound faststart yes<BR>> >> >> > display IE deliver no<BR>> >> >> > redirect nunmber IT deliver - outbound
no<BR>> >> >> > enable outbound faststart yes<BR>> >> >> ><BR>> >> >> ><BR>> >> >> > voice service voip<BR>> >> >> > allow-connections h323 to h323<BR>> >> >> > allow-connections h323 to sip<BR>> >> >> > allow-connections sip to h323<BR>> >> >> > allow-connections sip to sip<BR>> >> >> > fax protocol pass-through g711ulaw<BR>> >> >> > h323<BR>> >> >> > emptycapability<BR>> >> >> > h225 id-passthru<BR>> >> >> > h245 passthru tcsnonstd-passthru<BR>> >> >> > sip<BR>> >> >> ><BR>> >> >> ><BR>> >> >> > voice class h323 50<BR>> >> >> > h225 timeout tcp establish 3<BR>>
>> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > voice translation-rule 1<BR>> >> >> > rule 1 /.*/ /190/<BR>> >> >> > !<BR>> >> >> > voice translation-rule 2<BR>> >> >> > rule 1 /.*/ /1&/<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > voice translation-profile aa<BR>> >> >> > translate called 1<BR>> >> >> > !<BR>> >> >> > voice translation-profile addone<BR>> >> >> > translate called 2<BR>> >>
>> > !<BR>> >> >> > !<BR>> >> >> > voice-card 0<BR>> >> >> > dspfarm<BR>> >> >> > dsp services dspfarm<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > sccp local GigabitEthernet0/1<BR>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>> >> >> > sccp<BR>> >> >> > !<BR>> >> >> > sccp ccm group 1<BR>> >> >> > associate ccm 1 priority 1<BR>> >> >> > associate ccm 2 priority 2<BR>> >> >> > associate profile 1 register 2821transcode<BR>> >> >> > !<BR>> >> >> > dspfarm profile 1 transcode<BR>> >> >> > codec g711ulaw<BR>> >>
>> > codec g711alaw<BR>> >> >> > codec g729ar8<BR>> >> >> > codec g729abr8<BR>> >> >> > codec g729r8<BR>> >> >> > maximum sessions 4<BR>> >> >> > associate application SCCP<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > dial-peer voice 100 voip<BR>> >> >> > description AA Publisher<BR>> >> >> > preference 1<BR>> >> >> > destination-pattern 1..<BR>> >> >> > voice-class h323 50<BR>> >> >> > session target ipv4:10.1.80.10<BR>> >> >> > dtmf-relay h245-alphanumeric<BR>> >> >> > codec g711ulaw<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer
voice 1000 voip<BR>> >> >> > description incoming Call<BR>> >> >> > translation-profile incoming aa<BR>> >> >> > preference 1<BR>> >> >> > rtp payload-type nse 101<BR>> >> >> > rtp payload-type nte 100<BR>> >> >> > incoming called-number 6782282221<BR>> >> >> > dtmf-relay rtp-nte<BR>> >> >> > codec g711ulaw<BR>> >> >> > ip qos dscp cs5 media<BR>> >> >> > ip qos dscp cs5 signaling<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer voice 101 voip<BR>> >> >> > description AA Subscriber<BR>> >> >> > preference 2<BR>> >> >> > destination-pattern 1..<BR>> >> >> >
voice-class h323 50<BR>> >> >> > session target ipv4:10.1.80.11<BR>> >> >> > dtmf-relay h245-alphanumeric<BR>> >> >> > codec g711ulaw<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer voice 2000 voip<BR>> >> >> > description outbound<BR>> >> >> > translation-profile outgoing addone<BR>> >> >> > preference 1<BR>> >> >> > destination-pattern .T<BR>> >> >> > rtp payload-type nse 101<BR>> >> >> > rtp payload-type nte 100<BR>> >> >> > voice-class sip asymmetric payload dtmf<BR>> >> >> > session protocol sipv2<BR>> >> >> > session target ipv4:64.154.41.200<BR>> >> >> > dtmf-relay
rtp-nte<BR>> >> >> > codec g711ulaw<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > !<BR>> >> >> > sip-ua<BR>> >> >> > credentials username ***** password 7 ***** realm<BR>> sip.talkinip.net<BR>> >> >> > authentication username ***** password 7 *****<BR>> >> >> > authentication username ***** password 7 ***** realm<BR>> >> >> > sip.talkinip.net<BR>> >> >> > set pstn-cause 3 sip-status 486<BR>> >> >> > set pstn-cause 34 sip-status 486<BR>> >> >> > set pstn-cause 47 sip-status 486<BR>> >> >> > registrar dns:sip.talkinip.net expires 60<BR>> >> >> > sip-server dns:sip.talkinip.net:5060<BR>>
>> >> > _______________________________________________<BR>> >> >> > cisco-voip mailing list<BR>> >> >> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> >> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>> >> >> ><BR>> >> >> ><BR>> >> ><BR>> >> ><BR>> ><BR>> > _______________________________________________<BR>> > cisco-voip mailing list<BR>> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>> ><BR>>
><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f0979ab6/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f0979ab6/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 5<BR>Date: Tue, 27 Oct 2009 11:14:45 -0600<BR>From: Jim Reed <<A href="mailto:jreed@swiftnews.com" ymailto="mailto:jreed@swiftnews.com">jreed@swiftnews.com</A>><BR>To: Ratko Dodevski <<A href="mailto:rade239@gmail.com" ymailto="mailto:rade239@gmail.com">rade239@gmail.com</A>>, "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>"<BR> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re:
[cisco-voip] UCCX Script<BR>Message-ID: <C70C86A8.2B732%<A href="mailto:jreed@swiftnews.com" ymailto="mailto:jreed@swiftnews.com">jreed@swiftnews.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Attached is the script and document I sent Ratko in case anyone else is interested. Fairly straightforward. Found it would go through about 125 phone numbers before it generated the 1000-step execution error. Raised the parameter in our IPCC cluster to 3000 and was able to get through 200 phone numbers.<BR><BR>For what it's worth...<BR>--<BR>Jim Reed<BR>Swift Communications, Inc.<BR>970-683-5646 (Direct)<BR>775-772-7666 (Cell)<BR><BR>Quando omni flunkus moritati<BR>"When all else fails, play dead"<BR> Red Green - President: Possum Lodge<BR><BR><BR><BR>On 10/26/09 3:41 AM, "Ratko Dodevski" <<A href="mailto:rade239@gmail.com" ymailto="mailto:rade239@gmail.com">rade239@gmail.com</A>>
wrote:<BR><BR>Hi,<BR>Can someone help me a script? I need a script that would look in a xml file that contains list of telephone numbers and based on that search it allows or denies the call.<BR><BR>thanks in advanced<BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0001.html</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: PhoneNumberMatching.aef<BR>Type: application/octet-stream<BR>Size: 14804 bytes<BR>Desc: PhoneNumberMatching.aef<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0002.obj"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0002.obj</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: PhoneNumbers.xml<BR>Type: application/octet-stream<BR>Size: 7894 bytes<BR>Desc: PhoneNumbers.xml<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0003.obj" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0003.obj</A>><BR><BR>------------------------------<BR><BR>Message: 6<BR>Date: Tue, 27 Oct 2009 11:21:24 -0600<BR>From: "Norton, Mike" <<A href="mailto:mikenorton@pwsd76.ab.ca" ymailto="mailto:mikenorton@pwsd76.ab.ca">mikenorton@pwsd76.ab.ca</A>><BR>To: Robert Shearrill <<A href="mailto:rshearri@uchicago.edu" ymailto="mailto:rshearri@uchicago.edu">rshearri@uchicago.edu</A>>,<BR> "<A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>" <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] Problem using pitney bowes postage machine<BR>Message-ID:<BR> <<A href="mailto:096D50507635B645A061351B1308C90B01EFB32443@pwsdexchange03.pwsb33.ab.ca" ymailto="mailto:096D50507635B645A061351B1308C90B01EFB32443@pwsdexchange03.pwsb33.ab.ca">096D50507635B645A061351B1308C90B01EFB32443@pwsdexchange03.pwsb33.ab.ca</A>><BR> <BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Had that problem with one that was on an ATA. At the time, calls were going out an FXO gateway, so the results were not exactly surprising. I put the ATA in a different CSS so its calls would go out a PRI gateway instead, and that improved the call quality
enough to make the postage machine get by.<BR><BR>My understanding, IIRC, was that Pitney Bowes will only officially support having it on an ordinary telco POTS line. Which kinda makes one wonder why they bothered to put a "PBX" option in the machine's configuration for prefixing a nine.<BR><BR>--<BR>Mike Norton<BR>I.T. Support<BR>Peace Wapiti School Division No. 76<BR>Helpdesk: 780-831-3080<BR>Direct: 780-831-3076<BR><BR><BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Robert Shearrill<BR>Sent: October-26-09 12:37 PM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] Problem using pitney
bowes postage machine<BR><BR>I having trouble using pitney bowes postage machine on the vg224 analog gateway. Have anyone come across this problem or have a solution.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/23c58ae2/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/23c58ae2/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 7<BR>Date: Tue, 27 Oct 2009 14:00:01 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID: <<A href="mailto:AAFA07F1-1E5C-4C2B-90F8-8DFE0601A50A@cisco.com" ymailto="mailto:AAFA07F1-1E5C-4C2B-90F8-8DFE0601A50A@cisco.com">AAFA07F1-1E5C-4C2B-90F8-8DFE0601A50A@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>That is RFC2833 DTMF with a payload type of 101.<BR><BR>I do know that CUBE cannot do dynamic RFC2833 payload types. It can <BR>only send the payloadType defined in the voip dial-peer. So if <BR>inbound calls use a different payloadType than outbound calls you will <BR>want to update the dial-peers accordingly.<BR><BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR><BR>Well I tried to switch providers just to test it out and now I am <BR>getting
something back in the 183 but still no dtmf hmm<BR><BR>I see they are sending me<BR><BR>m=audio 11680 RTP/AVP 0 101<BR><BR>How do I interperate that line?<BR><BR><BR>Received:<BR>SIP/2.0 183 Session Progress<BR>Via: SIP/2.0/UDP <BR>173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57<BR>From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A>>;tag=419FE94-8A1<BR>To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A>>;tag=as5677a12c<BR>Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>CSeq: 101 INVITE<BR>User-Agent: LES.NET.VoIP<BR>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>Contact: <sip:18774675464@64.34.181.47><BR>Content-Type: application/sdp<BR>Content-Length: 214<BR>v=0<BR>o=root 5115 5115 IN IP4
64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX<BR>*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: <BR>No GTD found in inbound container<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>SIP: Attribute mid, level 1 instance 1 not found.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>resolve_media_ip_address_to_bind: Media already bound, use existing <BR>source_media_ip_addr<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/ <BR>sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
<BR>sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on <BR>Static Payload for m-line 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoPtimeNegotiation: No ptime present or multiple ptime <BR>attributes that can't be handled<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in <BR>fmtp list of events.<BR>*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
<BR>sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem <BR>relay<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIGetSDPDirectionAttribute: No direction attribute present or <BR>multiple direction attributes that can't be handled for m-line:1 and <BR>num-a-lines:0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1<BR> payload_type=0, codec_bytes=160, codec=g711ulaw, <BR>dtmf_relay=rtp-nte<BR> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47, <BR>dest_port=11680<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/ <BR>sipSPIChangeStreamState: Stream (callid = -1) State changed from <BR>(STREAM_DEAD) to (STREAM_ADDING)<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/ <BR>sipSPIUpdCallWithSdpInfo:<BR>
Preferred Codec : g711ulaw, bytes :160<BR> Preferred DTMF relay : rtp-nte<BR> Preferred NTE payload : 101<BR> Early Media : No<BR> Delayed Media : No<BR> Bridge Done : No<BR> New Media : No<BR> DSP DNLD Reqd : No<BR><BR>On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> <BR>wrote:<BR>The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>You can tell because in the 200 OK: CSeq: 102 CANCEL.
You should see<BR>a 200 OK with the CSeq for 101 INVITE.<BR><BR>I've seen this for certain IVRs/providers - sometimes they don't<BR>properly terminate a call with a 200 OK. If you were not sending an<BR>SDP in your original INVITE, then you would need the PRACK setting<BR>mentioned. You have two problems, either could fix the problem: They<BR>could advertise DTMF in their 183, or they could send you a 200 OK for<BR>the call. It is assumed you would get DTMF in the 200 OK. It's<BR>common for endpoints that support DTMF to not advertise it in the 183<BR>because you technically shouldn't need DTMF to hear ringback.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>> There is no SDP in that 200 OK so I would assume the media info is <BR>the same<BR>> as in the 183 Ringing
message. You really need your ITSP to tell <BR>you what<BR>> dtmf method they want you to use on your outbound calls. As Nick <BR>said they<BR>> don't appear to be advertising any dtmf method at all.<BR>> -Ryan<BR>> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>> Is the below the ok I should be getting?<BR>><BR>><BR>> They did send this with the first debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=32DA608-109A<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/ <BR>sipSPICheckResponse:<BR>>
non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>><BR>> This with the 2nd debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event
1<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> Received:<BR>> SIP/2.0 487 Request Terminated<BR>> To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> Contact: <sip:18774675464@64.154.41.200:5060><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 INVITE<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> Content-Length: 0<BR>><BR>> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <BR><<A
href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> In the 183 Session Progress they're not advertising DTMF:<BR>>><BR>>> m=audio 45846 RTP/AVP 0<BR>>><BR>>> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>> You would want to pick up on the other side and they should send a <BR>200<BR>>> OK with a new SDP. If the other side did pick up, you need to tell<BR>>> the provider that they need to send a 200 OK, because they're not.<BR>>><BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Nick<BR>>> ><BR>>> > I removed voice-class sip asymmetric payload dtmf and added in
<BR>the<BR>>> > other<BR>>> > line<BR>>> ><BR>>> > Just to state incoming dtmf works but not outbound the ITSP has <BR>told me<BR>>> > they<BR>>> > are using two different sip servers/vendors for processing <BR>inbound and<BR>>> > outbound<BR>>> > How does this translate into what I should sent the following too?<BR>>> ><BR>>> > rtp payload-type nse<BR>>> > rtp payload-type nte<BR>>> ><BR>>> > In the debug trhe following where set<BR>>> ><BR>>> > rtp payload-type nse 101<BR>>> > rtp payload-type nte 100<BR>>> ><BR>>> > In the debug of ccsip If I am looking at it correctly I see me <BR>sending<BR>>> > this<BR>>> ><BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>> > Preferred
method of dtmf relay is: 6, with payload: 100<BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>> > max_event 15<BR>>> ><BR>>> > and<BR>>> ><BR>>> ><BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> ><BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>> > Remote-Party-ID:<BR>>> > <sip:
<BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 101 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact:
<sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> ><BR>>> ><BR>>> > Then when I do a search for fmtp again further down I see<BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 102 INVITE<BR>>>
> Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Proxy-Authorization: Digest<BR>>> ><BR>>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464@64.154.41.200:5060 <BR>",response <BR>= <BR>"ab63d4755ff4182631ad2db0f9ed0e44 <BR>",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0
PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 100 Trying<BR>>> > Via:
SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_SENT_INVITE, <BR>SUBSTATE_NONE) to<BR>>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>> > *Oct 27 12:34:10.832:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 183 Session Progress<BR>>> > To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Type: application/sdp<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Content-Length: 146<BR>>> > v=0<BR>>> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>> > s=sip call<BR>>> > c=IN IP4 64.154.41.101<BR>>> > t=0 0<BR>>> > m=audio 45846 RTP/AVP 0<BR>>> > a=ptime:20<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentGTD:
No<BR>>> > GTD<BR>>> > found in inbound container<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>> > Number of m-lines = 1<BR>>> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m- <BR>line 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>> > One ptime attribute found - value:20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: <BR>Values :Codec:<BR>>> > g711ulaw ptime :20, codecbytes: 160<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: <BR>160 for<BR>>> > codec<BR>>> > g711ulaw<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line <BR>index 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>> > Dynamic payload(100) could not be reserved.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case <BR>of full<BR>>> > named<BR>>> > event(NE) match in fmtp list of events.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No <BR>direction<BR>>> > attribute present or multiple direction attributes that can't be <BR>handled<BR>>>
> for<BR>>> > m-line:1 and num-a-lines:0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec negotiation successful for media line 1<BR>>> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>> > dtmf_relay=rtp-nte<BR>>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>> > dest_port=45846<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>> > (STREAM_ADDING)<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Preferred Codec : g711ulaw, bytes :160<BR>>> >
Preferred DTMF relay : rtp-nte<BR>>> > Preferred NTE payload : 100<BR>>> > Early Media : No<BR>>> > Delayed Media : No<BR>>> > Bridge Done : No<BR>>> > New Media : No<BR>>> > DSP DNLD Reqd : No<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4A170B28)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Hndl ptype 0 mline 1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Selecting<BR>>> >
codec g711ulaw<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>> > Codec to be matched: 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>ADD<BR>>> > AUDIO<BR>>> > CODEC 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Media<BR>>> > negotiation done:<BR>>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160, <BR>coverted<BR>>> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 <BR>ss 1<BR>>> > 64.154.41.101:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 flags 0x100 state
STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > Report initial call media<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: <BR>ccb->flags<BR>>> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4DEC000C)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>> > 5030: Posting Remote SRTP caps to other callleg.<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>> > cc_api_caps_ind()<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Stream type : voice+dtmf<BR>>> > Media line : 1<BR>>> > State : STREAM_ADDING (2)<BR>>> > Stream address type : 1<BR>>> > Callid : 846<BR>>> > Negotiated Codec : g711ulaw, bytes :160<BR>>> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>> > Negotiated DTMF relay : rtp-nte<BR>>> >
Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>> > Negotiated CN payload : 0<BR>>> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>> > headers<BR>>> > recvd from app container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQSIG:<BR>>> > No<BR>>> > QSIG Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQ931:<BR>>> > No<BR>>> > RawMsg Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
<BR>sipSPICreateNewRawMsg:<BR>>> > No<BR>>> > Data to form The Raw Message<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: <BR>Transaction<BR>>> > Complete. Lock on Facilities released.<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>confID =<BR>>> > 6,<BR>>> > srcCallID = 846, dstCallID = 845<BR>>> > *Oct 27 12:34:10.844:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old streamcallid=846, new streamcallid=846<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>> > Setting SPI mode to SIP-H323<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = <BR>1131891908<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>> > sipSPIProcessRtpSessions<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/ <BR>sipSPIAddStream:<BR>>> > Adding<BR>>> > stream 1 of type voice+dtmf (callid 846) to the
VOIP RTP library<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > sipSPIUpdateRtcpSession for m-line 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > rtcp_session info<BR>>> > laddr = 173.14.220.57, lport = 16462, raddr = <BR>64.154.41.101,<BR>>> > rport=45846, do_rtcp=TRUE<BR>>> > src_callid = 846, dest_callid = 845, stream type =
voice <BR>+dtmf,<BR>>> > stream direction = SENDRECV<BR>>> > media_ip_addr = 64.154.41.101, vrf tableid = 0 <BR>media_addr_type =<BR>>> > 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > RTP session already created - update<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>> > New Remote Media Direction = SENDRECV<BR>>> > Present Local Media Direction = SENDRECV<BR>>> > New Local Media Direction = SENDRECV<BR>>> > retVal = 0<BR>>> >
*Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>> > (STREAM_ACTIVE)<BR>>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>really<BR>>> > can't<BR>>> > find peer_stream for<BR>>> > dtmf-relay <BR>interworking<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>> > *Oct 27 12:34:11.140:<BR>>> >
//846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.140:
//846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27
12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind:
ccb->pld.flags_ipip = 0x200405<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Setting<BR>>> > CAPS_RECEIVED flag<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Calling<BR>>> > cc_api_caps_ack()<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ack: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27
12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27
12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> >
*Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind:
ccb->pld.flags_ipip = 0x200425<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Second<BR>>> > TCS<BR>>> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>> > *Oct 27 12:34:15.876:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/ <BR>ccsip_call_statistics:<BR>>> > Stats are not supported for IPIP call.<BR>>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>> > Queued<BR>>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>> > *Oct 27 12:34:15.880:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/ <BR>sipSPISendCancel:<BR>>> > Associated container=0x4E310C1C to Cancel<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/ <BR>sipSPISendCancel:<BR>>> > Sending CANCEL to the transport layer<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> > msg=0x4DF0D994,<BR>>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, <BR>transport=1,<BR>>> > switch=0, callBack=0x419703BC<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage: <BR>Proceedable<BR>>> > for<BR>>> > sending msg immediately<BR>>> > *Oct 27
12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>> > transport<BR>>> > is 0<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set <BR>to send<BR>>> > the<BR>>> > msg=0x4DF0D994<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: <BR>Posting<BR>>> > send<BR>>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for <BR>UDP<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
<BR>SUBSTATE_NONE)<BR>>> > to<BR>>> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Sent:<BR>>> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646855<BR>>> > Reason: Q.850;cause=16<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >
ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> ><BR>>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A> <BR>><BR>>> > wrote:<BR>>> >><BR>>> >> You would want to check the SDP of 200 OK the provider sends <BR>for your<BR>>> >> outgoing call. It will list the payload type for the dtmf in the<BR>>> >> format a=fmtp 101 1-16, or something similar. You want to find
<BR>out<BR>>> >> what payload type they are advertising (or if they are at <BR>all). It<BR>>> >> would be worth checking the incoming INVITE from them to see what<BR>>> >> they're using when they send the first SDP.<BR>>> >><BR>>> >> On that note, I would also remove the asymmetric payload <BR>command - to<BR>>> >> my knowledge it doesn't do what you're expecting it to. You <BR>may want<BR>>> >> to try this command:<BR>>> >> voice-class sip dtmf-relay force rtp-nte<BR>>> >><BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A> <BR>><BR>>> >> wrote:<BR>>> >> > Hello,<BR>>> >> ><BR>>>
>> > I am having an issue with dtmf working outbound. Inbound <BR>dtmf works<BR>>> >> > fine.<BR>>> >> > It took some playing around with it. At first it didnt work <BR>till the<BR>>> >> > payload was ajusted. I am now trying to get outbound dtmf <BR>working<BR>>> >> > properly.<BR>>> >> ><BR>>> >> > On my 2821 I debugged voip rtp session named-events and then <BR>made a<BR>>> >> > call<BR>>> >> > to<BR>>> >> > a 1800 number and hit digits. I didn't see any dtmf output <BR>on the<BR>>> >> > router<BR>>> >> > nothing showed up in the debug. Does this mean I can safely <BR>asume<BR>>> >> > that<BR>>> >> > the<BR>>> >> > problem for right now is not on the ITSP side but
on my side <BR>since<BR>>> >> > dtmf<BR>>> >> > is<BR>>> >> > not being sent down the sip trunk?<BR>>> >> ><BR>>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>> >> > configuration<BR>>> >> > of the cisco 2821 is shown below. Does anyone have any ideas <BR>what I<BR>>> >> > can<BR>>> >> > do<BR>>> >> > so dtmf digits process properly outbound?<BR>>> >> ><BR>>> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>> >> ><BR>>> >> > h323 cucm gateway configuratration<BR>>> >> > Signaling Port 1720<BR>>> >> > media termination point required yes<BR>>> >> > retry video call as auto yes<BR>>> >> > wait for far end h.245 terminal
capability set yes<BR>>> >> > transmit utf-8 calling party name no<BR>>> >> > h.235 pass through allowed no<BR>>> >> > significant digits all<BR>>> >> > redirect number IT deliver - inbound no<BR>>> >> > enable inbound faststart yes<BR>>> >> > display IE deliver no<BR>>> >> > redirect nunmber IT deliver - outbound no<BR>>> >> > enable outbound faststart yes<BR>>> >> ><BR>>> >> ><BR>>> >> > voice service voip<BR>>> >> > allow-connections h323 to h323<BR>>> >> > allow-connections h323 to sip<BR>>> >> > allow-connections sip to h323<BR>>> >> > allow-connections sip to sip<BR>>> >> > fax protocol pass-through g711ulaw<BR>>> >> > h323<BR>>> >> >
emptycapability<BR>>> >> > h225 id-passthru<BR>>> >> > h245 passthru tcsnonstd-passthru<BR>>> >> > sip<BR>>> >> ><BR>>> >> ><BR>>> >> > voice class h323 50<BR>>> >> > h225 timeout tcp establish 3<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-rule 1<BR>>> >> > rule 1 /.*/ /190/<BR>>> >> > !<BR>>> >> > voice translation-rule 2<BR>>> >> > rule 1 /.*/ /1&/<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice
translation-profile aa<BR>>> >> > translate called 1<BR>>> >> > !<BR>>> >> > voice translation-profile addone<BR>>> >> > translate called 2<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice-card 0<BR>>> >> > dspfarm<BR>>> >> > dsp services dspfarm<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sccp local GigabitEthernet0/1<BR>>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>> >> > sccp<BR>>> >> > !<BR>>> >> > sccp ccm group 1<BR>>> >> > associate ccm 1 priority 1<BR>>> >> > associate ccm 2 priority 2<BR>>> >> > associate profile 1 register 2821transcode<BR>>>
>> > !<BR>>> >> > dspfarm profile 1 transcode<BR>>> >> > codec g711ulaw<BR>>> >> > codec g711alaw<BR>>> >> > codec g729ar8<BR>>> >> > codec g729abr8<BR>>> >> > codec g729r8<BR>>> >> > maximum sessions 4<BR>>> >> > associate application SCCP<BR>>> >> > !<BR>>> >> > !<BR>>> >> > dial-peer voice 100 voip<BR>>> >> > description AA Publisher<BR>>> >> > preference 1<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.10<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> >
!<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > description incoming Call<BR>>> >> > translation-profile incoming aa<BR>>> >> > preference 1<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > incoming called-number 6782282221<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > ip qos dscp cs5 media<BR>>> >> > ip qos dscp cs5 signaling<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > description AA Subscriber<BR>>> >> > preference 2<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >>
> session target ipv4:10.1.80.11<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > description outbound<BR>>> >> > translation-profile outgoing addone<BR>>> >> > preference 1<BR>>> >> > destination-pattern .T<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > voice-class sip asymmetric payload dtmf<BR>>> >> > session protocol sipv2<BR>>> >> > session target ipv4:64.154.41.200<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> >
!<BR>>> >> > !<BR>>> >> > sip-ua<BR>>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net<BR>>> >> > authentication username ***** password 7 *****<BR>>> >> > authentication username ***** password 7 ***** realm<BR>>> >> > sip.talkinip.net<BR>>> >> > set pstn-cause 3 sip-status 486<BR>>> >> > set pstn-cause 34 sip-status 486<BR>>> >> > set pstn-cause 47 sip-status 486<BR>>> >> > registrar dns:sip.talkinip.net expires 60<BR>>> >> > sip-server dns:sip.talkinip.net:5060<BR>>> >> > _______________________________________________<BR>>> >> > cisco-voip mailing list<BR>>> >> > <A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> >> ><BR>>> >> ><BR>>> ><BR>>> ><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/6fcf0fb2/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/6fcf0fb2/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 8<BR>Date: Tue, 27 Oct 2009 11:41:24 -0600<BR>From: "Norton, Mike" <<A href="mailto:mikenorton@pwsd76.ab.ca" ymailto="mailto:mikenorton@pwsd76.ab.ca">mikenorton@pwsd76.ab.ca</A>><BR>To: "Jason Aarons (US)" <<A href="mailto:jason.aarons@us.didata.com" ymailto="mailto:jason.aarons@us.didata.com">jason.aarons@us.didata.com</A>>,<BR> "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>" <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] FXO port Attendant DN won't ring Hunt Pilot<BR>Message-ID:<BR> <<A
href="mailto:096D50507635B645A061351B1308C90B01EFB3245D@pwsdexchange03.pwsb33.ab.ca" ymailto="mailto:096D50507635B645A061351B1308C90B01EFB3245D@pwsdexchange03.pwsb33.ab.ca">096D50507635B645A061351B1308C90B01EFB3245D@pwsdexchange03.pwsb33.ab.ca</A>><BR> <BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>You're still fighting that issue, eh? Like I said before, I do it all the time and have never had it not work. Weird.<BR><BR>--<BR>Mike Norton<BR>I.T. Support<BR>Peace Wapiti School Division No. 76<BR>Helpdesk: 780-831-3080<BR>Direct: 780-831-3076<BR><BR><BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Jason Aarons (US)<BR>Sent: October-26-09 2:00 PM<BR>To: <A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] FXO port Attendant DN won't ring Hunt Pilot<BR><BR>Under Device Gateway > Router > 4FXO Port > Attendant DN can you point that directly to a Hunt Pilot? In the past it hasn't worked, I had to point the Attendant DN number to a Translation Pattern to the Hunt Pilot.<BR><BR>Is this a feature or a bug?<BR>________________________________<BR><BR>Disclaimer: This e-mail communication and any attachments may contain confidential and privileged information and is for use by the designated addressee(s) named above only. If you are not the intended addressee, you are hereby notified that you have received this communication in error and that any use or reproduction of this email or its contents is strictly prohibited and may be unlawful. If you have received this communication in error, please
notify us immediately by replying to this message and deleting it from your computer. Thank you.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/ed4ff56f/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/ed4ff56f/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 9<BR>Date: Tue, 27 Oct 2009 14:10:35 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip
trunk<BR>Message-ID: <<A href="mailto:4B18CB48-6FE5-4ACF-8D2A-86E267B63193@cisco.com" ymailto="mailto:4B18CB48-6FE5-4ACF-8D2A-86E267B63193@cisco.com">4B18CB48-6FE5-4ACF-8D2A-86E267B63193@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>Sorry this part is the actual DTMF:<BR><BR>a=rtpmap:101 telephone-event/8000<BR><BR>The line you quoted is part of the SDP and references both RTP and DTMF.<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>The fist line means your RTP is on port 11680 and references the <BR>a:rtpmap entries for 0 and 101.<BR>The second line means your RTP is g.711.<BR>The 3rd line is the DTMF with a payload type of 101.<BR>The 4th line means it can accept DTMF 0-16<BR>The last line is pretty self explanatory (silence suppression disabled).<BR><BR>This is a
very basic interpretation of the SDP info. RFC 2327 is <BR>where you want to go to get into the nitty-gritty details.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR><BR>That is RFC2833 DTMF with a payload type of 101.<BR><BR>I do know that CUBE cannot do dynamic RFC2833 payload types. It can <BR>only send the payloadType defined in the voip dial-peer. So if <BR>inbound calls use a different payloadType than outbound calls you will <BR>want to update the dial-peers accordingly.<BR><BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR><BR>Well I tried to switch providers just to test it out and now I am <BR>getting something back in the 183 but still no dtmf hmm<BR><BR>I see they are sending me<BR><BR>m=audio 11680 RTP/AVP 0 101<BR><BR>How do I interperate that line?<BR><BR><BR>Received:<BR>SIP/2.0 183 Session Progress<BR>Via: SIP/2.0/UDP
<BR>173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57<BR>From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A>>;tag=419FE94-8A1<BR>To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A>>;tag=as5677a12c<BR>Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>CSeq: 101 INVITE<BR>User-Agent: LES.NET.VoIP<BR>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>Contact: <sip:18774675464@64.34.181.47><BR>Content-Type: application/sdp<BR>Content-Length: 214<BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
<BR>sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX<BR>*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: <BR>No GTD found in inbound container<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>SIP: Attribute mid, level 1 instance 1 not found.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>resolve_media_ip_address_to_bind: Media already bound, use existing <BR>source_media_ip_addr<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/ <BR>sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on <BR>Static Payload for m-line 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoPtimeNegotiation: No ptime present or multiple ptime <BR>attributes that can't be
handled<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in <BR>fmtp list of events.<BR>*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem <BR>relay<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIGetSDPDirectionAttribute: No direction attribute present or <BR>multiple direction attributes that can't be handled
for m-line:1 and <BR>num-a-lines:0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1<BR> payload_type=0, codec_bytes=160, codec=g711ulaw, <BR>dtmf_relay=rtp-nte<BR> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47, <BR>dest_port=11680<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/ <BR>sipSPIChangeStreamState: Stream (callid = -1) State changed from <BR>(STREAM_DEAD) to (STREAM_ADDING)<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/ <BR>sipSPIUpdCallWithSdpInfo:<BR> Preferred Codec : g711ulaw, bytes :160<BR> Preferred DTMF relay : rtp-nte<BR> Preferred NTE payload : 101<BR> Early Media
: No<BR> Delayed Media : No<BR> Bridge Done : No<BR> New Media : No<BR> DSP DNLD Reqd : No<BR><BR>On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> <BR>wrote:<BR>The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>a 200 OK with the CSeq for 101 INVITE.<BR><BR>I've seen this for certain IVRs/providers - sometimes they don't<BR>properly terminate a call with a 200 OK. If you were not sending an<BR>SDP in your original INVITE, then you would need the PRACK
setting<BR>mentioned. You have two problems, either could fix the problem: They<BR>could advertise DTMF in their 183, or they could send you a 200 OK for<BR>the call. It is assumed you would get DTMF in the 200 OK. It's<BR>common for endpoints that support DTMF to not advertise it in the 183<BR>because you technically shouldn't need DTMF to hear ringback.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>> There is no SDP in that 200 OK so I would assume the media info is <BR>the same<BR>> as in the 183 Ringing message. You really need your ITSP to tell <BR>you what<BR>> dtmf method they want you to use on your outbound calls. As Nick <BR>said they<BR>> don't appear to be advertising any dtmf method at all.<BR>> -Ryan<BR>> On Oct 27, 2009,
at 8:51 AM, Dane Newman wrote:<BR>> Is the below the ok I should be getting?<BR>><BR>><BR>> They did send this with the first debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=32DA608-109A<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/
<BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>><BR>> This with the 2nd debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID:
DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27
12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> Received:<BR>> SIP/2.0 487 Request Terminated<BR>> To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> Contact: <sip:18774675464@64.154.41.200:5060><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 INVITE<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> Content-Length: 0<BR>><BR>> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <BR><<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> In the 183 Session Progress they're not advertising DTMF:<BR>>><BR>>> m=audio 45846 RTP/AVP 0<BR>>><BR>>> There should be a 100 or 101
there. Although, 183 is just ringback.<BR>>> You would want to pick up on the other side and they should send a <BR>200<BR>>> OK with a new SDP. If the other side did pick up, you need to tell<BR>>> the provider that they need to send a 200 OK, because they're not.<BR>>><BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Nick<BR>>> ><BR>>> > I removed voice-class sip asymmetric payload dtmf and added in <BR>the<BR>>> > other<BR>>> > line<BR>>> ><BR>>> > Just to state incoming dtmf works but not outbound the ITSP has <BR>told me<BR>>> > they<BR>>> > are using two different sip servers/vendors for processing <BR>inbound
and<BR>>> > outbound<BR>>> > How does this translate into what I should sent the following too?<BR>>> ><BR>>> > rtp payload-type nse<BR>>> > rtp payload-type nte<BR>>> ><BR>>> > In the debug trhe following where set<BR>>> ><BR>>> > rtp payload-type nse 101<BR>>> > rtp payload-type nte 100<BR>>> ><BR>>> > In the debug of ccsip If I am looking at it correctly I see me <BR>sending<BR>>> > this<BR>>> ><BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>> > Preferred method of dtmf relay is: 6, with payload: 100<BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>> > max_event 15<BR>>> ><BR>>> > and<BR>>> ><BR>>> ><BR>>> >
*Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> ><BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct
2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 101 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4
173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> ><BR>>> ><BR>>> > Then when I do a search for fmtp again further down I see<BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To:
<sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 102 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Proxy-Authorization: Digest<BR>>> ><BR>>> >
username="1648245954",realm="64.154.41.110",uri="sip:18774675464@64.154.41.200:5060 <BR>",response <BR>= <BR>"ab63d4755ff4182631ad2db0f9ed0e44 <BR>",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr:
[64.154.41.200]:5060<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 100 Trying<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To:
<sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_SENT_INVITE, <BR>SUBSTATE_NONE) to<BR>>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for
event 1<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 183 Session Progress<BR>>> > To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Type: application/sdp<BR>>>
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Content-Length: 146<BR>>> > v=0<BR>>> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>> > s=sip call<BR>>> > c=IN IP4 64.154.41.101<BR>>> > t=0 0<BR>>> > m=audio 45846 RTP/AVP 0<BR>>> > a=ptime:20<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentGTD: No<BR>>> > GTD<BR>>> > found in inbound container<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>> > Number of m-lines = 1<BR>>> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m- <BR>line 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>> > One ptime attribute found - value:20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: <BR>Values :Codec:<BR>>> > g711ulaw ptime :20, codecbytes: 160<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: <BR>160 for<BR>>> > codec<BR>>> > g711ulaw<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line <BR>index 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>> > Dynamic payload(100) could not be reserved.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case <BR>of full<BR>>> > named<BR>>> > event(NE) match in fmtp list of events.<BR>>> > *Oct 27
12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No <BR>direction<BR>>> > attribute present or multiple direction attributes that can't be <BR>handled<BR>>> > for<BR>>> > m-line:1 and num-a-lines:0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec negotiation successful for media line 1<BR>>> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>> >
dtmf_relay=rtp-nte<BR>>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>> > dest_port=45846<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>> > (STREAM_ADDING)<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Preferred Codec : g711ulaw, bytes :160<BR>>> > Preferred DTMF relay : rtp-nte<BR>>> > Preferred NTE payload : 100<BR>>> > Early Media : No<BR>>> > Delayed Media :
No<BR>>> > Bridge Done : No<BR>>> > New Media : No<BR>>> > DSP DNLD Reqd : No<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4A170B28)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Hndl ptype 0 mline 1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Selecting<BR>>> > codec g711ulaw<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>> > Codec to be matched: 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>ADD<BR>>> > AUDIO<BR>>> > CODEC 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Media<BR>>> > negotiation done:<BR>>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160, <BR>coverted<BR>>> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 <BR>ss 1<BR>>> > 64.154.41.101:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> >
ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > Report initial call media<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: <BR>ccb->flags<BR>>> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>> > *Oct 27 12:34:10.840:
//846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4DEC000C)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>> > 5030: Posting Remote SRTP caps to other callleg.<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>> > cc_api_caps_ind()<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Stream type : voice+dtmf<BR>>> > Media line : 1<BR>>> > State : STREAM_ADDING (2)<BR>>> > Stream
address type : 1<BR>>> > Callid : 846<BR>>> > Negotiated Codec : g711ulaw, bytes :160<BR>>> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>> > Negotiated DTMF relay : rtp-nte<BR>>> > Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>> > Negotiated CN payload : 0<BR>>> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>>
> headers<BR>>> > recvd from app container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQSIG:<BR>>> > No<BR>>> > QSIG Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQ931:<BR>>> > No<BR>>> > RawMsg Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPICreateNewRawMsg:<BR>>> > No<BR>>> > Data to form The Raw Message<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_PROCEEDING_PROCEEDING) to
(STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: <BR>Transaction<BR>>> > Complete. Lock on Facilities released.<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>confID =<BR>>> > 6,<BR>>> > srcCallID = 846, dstCallID = 845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old streamcallid=846, new streamcallid=846<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>> > Setting SPI mode to SIP-H323<BR>>> > *Oct 27 12:34:10.844:
//846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = <BR>1131891908<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>> > sipSPIProcessRtpSessions<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/ <BR>sipSPIAddStream:<BR>>> > Adding<BR>>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.844:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > sipSPIUpdateRtcpSession for m-line 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > rtcp_session info<BR>>> > laddr = 173.14.220.57, lport = 16462, raddr = <BR>64.154.41.101,<BR>>> > rport=45846, do_rtcp=TRUE<BR>>> > src_callid = 846, dest_callid = 845, stream type = voice <BR>+dtmf,<BR>>> > stream direction = SENDRECV<BR>>> > media_ip_addr = 64.154.41.101, vrf tableid = 0 <BR>media_addr_type =<BR>>> > 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > RTP session already created - update<BR>>> > *Oct 27 12:34:10.848:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>> > New Remote Media Direction = SENDRECV<BR>>> > Present Local Media Direction = SENDRECV<BR>>> > New Local Media Direction = SENDRECV<BR>>> > retVal = 0<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>> > (STREAM_ACTIVE)<BR>>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>really<BR>>> > can't<BR>>> > find peer_stream for<BR>>> >
dtmf-relay <BR>interworking<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> >
forking flag to 0x0<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> >
Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
<BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Setting<BR>>> > CAPS_RECEIVED flag<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> >
Calling<BR>>> > cc_api_caps_ack()<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ack: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking
flag to 0x0<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay
& Passthru both disabled<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
<BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Second<BR>>> > TCS<BR>>> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>> > *Oct 27 12:34:15.876:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/ <BR>ccsip_call_statistics:<BR>>> > Stats are not supported for IPIP call.<BR>>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>> > Queued<BR>>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/ <BR>sipSPISendCancel:<BR>>> > Associated container=0x4E310C1C to Cancel<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/ <BR>sipSPISendCancel:<BR>>> > Sending CANCEL to the transport layer<BR>>> > *Oct 27 12:34:15.880:<BR>>>
> //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> > msg=0x4DF0D994,<BR>>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, <BR>transport=1,<BR>>> > switch=0, callBack=0x419703BC<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage: <BR>Proceedable<BR>>> > for<BR>>> > sending msg immediately<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>> > transport<BR>>> > is 0<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set <BR>to send<BR>>> > the<BR>>> > msg=0x4DF0D994<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: <BR>Posting<BR>>> >
send<BR>>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for <BR>UDP<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, <BR>SUBSTATE_NONE)<BR>>> > to<BR>>> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Sent:<BR>>> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646855<BR>>> > Reason: Q.850;cause=16<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>
> context=0x00000000<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27
12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> ><BR>>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick
Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A> <BR>><BR>>> > wrote:<BR>>> >><BR>>> >> You would want to check the SDP of 200 OK the provider sends <BR>for your<BR>>> >> outgoing call. It will list the payload type for the dtmf in the<BR>>> >> format a=fmtp 101 1-16, or something similar. You want to find <BR>out<BR>>> >> what payload type they are advertising (or if they are at <BR>all). It<BR>>> >> would be worth checking the incoming INVITE from them to see what<BR>>> >> they're using when they send the first SDP.<BR>>> >><BR>>> >> On that note, I would also remove the asymmetric payload <BR>command - to<BR>>> >> my knowledge it doesn't do what you're expecting it to. You <BR>may want<BR>>> >>
to try this command:<BR>>> >> voice-class sip dtmf-relay force rtp-nte<BR>>> >><BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A> <BR>><BR>>> >> wrote:<BR>>> >> > Hello,<BR>>> >> ><BR>>> >> > I am having an issue with dtmf working outbound. Inbound <BR>dtmf works<BR>>> >> > fine.<BR>>> >> > It took some playing around with it. At first it didnt work <BR>till the<BR>>> >> > payload was ajusted. I am now trying to get outbound dtmf <BR>working<BR>>> >> > properly.<BR>>> >> ><BR>>> >> > On my 2821 I debugged voip rtp session named-events and then
<BR>made a<BR>>> >> > call<BR>>> >> > to<BR>>> >> > a 1800 number and hit digits. I didn't see any dtmf output <BR>on the<BR>>> >> > router<BR>>> >> > nothing showed up in the debug. Does this mean I can safely <BR>asume<BR>>> >> > that<BR>>> >> > the<BR>>> >> > problem for right now is not on the ITSP side but on my side <BR>since<BR>>> >> > dtmf<BR>>> >> > is<BR>>> >> > not being sent down the sip trunk?<BR>>> >> ><BR>>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>> >> > configuration<BR>>> >> > of the cisco 2821 is shown below. Does anyone have any ideas <BR>what I<BR>>> >> > can<BR>>> >> > do<BR>>> >> > so dtmf
digits process properly outbound?<BR>>> >> ><BR>>> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>> >> ><BR>>> >> > h323 cucm gateway configuratration<BR>>> >> > Signaling Port 1720<BR>>> >> > media termination point required yes<BR>>> >> > retry video call as auto yes<BR>>> >> > wait for far end h.245 terminal capability set yes<BR>>> >> > transmit utf-8 calling party name no<BR>>> >> > h.235 pass through allowed no<BR>>> >> > significant digits all<BR>>> >> > redirect number IT deliver - inbound no<BR>>> >> > enable inbound faststart yes<BR>>> >> > display IE deliver no<BR>>> >> > redirect nunmber IT deliver - outbound no<BR>>> >> > enable outbound faststart yes<BR>>> >> ><BR>>>
>> ><BR>>> >> > voice service voip<BR>>> >> > allow-connections h323 to h323<BR>>> >> > allow-connections h323 to sip<BR>>> >> > allow-connections sip to h323<BR>>> >> > allow-connections sip to sip<BR>>> >> > fax protocol pass-through g711ulaw<BR>>> >> > h323<BR>>> >> > emptycapability<BR>>> >> > h225 id-passthru<BR>>> >> > h245 passthru tcsnonstd-passthru<BR>>> >> > sip<BR>>> >> ><BR>>> >> ><BR>>> >> > voice class h323 50<BR>>> >> > h225 timeout tcp establish 3<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> >
!<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-rule 1<BR>>> >> > rule 1 /.*/ /190/<BR>>> >> > !<BR>>> >> > voice translation-rule 2<BR>>> >> > rule 1 /.*/ /1&/<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-profile aa<BR>>> >> > translate called 1<BR>>> >> > !<BR>>> >> > voice translation-profile addone<BR>>> >> > translate called 2<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice-card 0<BR>>> >> > dspfarm<BR>>> >> > dsp services dspfarm<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sccp local GigabitEthernet0/1<BR>>> >>
> sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>> >> > sccp<BR>>> >> > !<BR>>> >> > sccp ccm group 1<BR>>> >> > associate ccm 1 priority 1<BR>>> >> > associate ccm 2 priority 2<BR>>> >> > associate profile 1 register 2821transcode<BR>>> >> > !<BR>>> >> > dspfarm profile 1 transcode<BR>>> >> > codec g711ulaw<BR>>> >> > codec g711alaw<BR>>> >> > codec g729ar8<BR>>> >> > codec g729abr8<BR>>> >> > codec g729r8<BR>>> >> > maximum sessions 4<BR>>> >> > associate application SCCP<BR>>> >> > !<BR>>> >> > !<BR>>> >> > dial-peer voice 100 voip<BR>>> >>
> description AA Publisher<BR>>> >> > preference 1<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.10<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > description incoming Call<BR>>> >> > translation-profile incoming aa<BR>>> >> > preference 1<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > incoming called-number 6782282221<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > ip qos dscp
cs5 media<BR>>> >> > ip qos dscp cs5 signaling<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > description AA Subscriber<BR>>> >> > preference 2<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.11<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > description outbound<BR>>> >> > translation-profile outgoing addone<BR>>> >> > preference 1<BR>>> >> > destination-pattern .T<BR>>> >> > rtp payload-type nse
101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > voice-class sip asymmetric payload dtmf<BR>>> >> > session protocol sipv2<BR>>> >> > session target ipv4:64.154.41.200<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sip-ua<BR>>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net<BR>>> >> > authentication username ***** password 7 *****<BR>>> >> > authentication username ***** password 7 ***** realm<BR>>> >> > sip.talkinip.net<BR>>> >> > set pstn-cause 3 sip-status 486<BR>>> >> > set pstn-cause 34 sip-status
486<BR>>> >> > set pstn-cause 47 sip-status 486<BR>>> >> > registrar dns:sip.talkinip.net expires 60<BR>>> >> > sip-server dns:sip.talkinip.net:5060<BR>>> >> > _______________________________________________<BR>>> >> > cisco-voip mailing list<BR>>> >> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> >> ><BR>>> >> ><BR>>> ><BR>>> ><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A
href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1e0e0070/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1e0e0070/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 10<BR>Date: Tue, 27 Oct 2009 13:35:19 -0500<BR>From: "Jeff Ruttman" <<A
href="mailto:ruttmanj@carewisc.org" ymailto="mailto:ruttmanj@carewisc.org">ruttmanj@carewisc.org</A>><BR>To: "Cisco VOIP Newsletter - puck.nether.net"<BR> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] Interpret CDR Search Results<BR>Message-ID:<BR> <<A href="mailto:07365C3161D8D8419EE51C3834C02205B84F06@ma1-exc01.ec2802.elderc.org" ymailto="mailto:07365C3161D8D8419EE51C3834C02205B84F06@ma1-exc01.ec2802.elderc.org">07365C3161D8D8419EE51C3834C02205B84F06@ma1-exc01.ec2802.elderc.org</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Greetings,<BR><BR>In the results of a CDR Search by Extension, I see entries like these:<BR><BR>Sl No Call Type GCID CMId<BR>GCID CallId Orig Node Id<BR>Dest Node Id Orig Leg Id<BR>Dest Leg
Id Calling No<BR>Calling No Partition Called No<BR>Called No Partition Dest No<BR>Dest No Partition Last Rd No<BR>Last Rd No Partition Media Info <BR>Orig Pkts Rcd Dest Pkts Rcd <BR>Orig Pkts Lost Dest Pkts Lost <BR>CDR - CMR Dump <BR><BR>33 Simple 3<BR>2155334 3<BR>0 50453618<BR>50453619 6174<BR>Phones null<BR>null null<BR>null null<BR>null null null Others<BR><javascript:fnDetails('Others',13)> <BR>null null View
<javascript:fnDetails('View',13)><BR><BR><BR><BR>24 Simple 3<BR>2155266 3<BR>3 50453393<BR>50453394 null<BR>null 6174<BR>Phones 6174<BR>Phones 6174<BR>Phones 2954 null Others<BR><javascript:fnDetails('Others',4)> <BR>0 null View <javascript:fnDetails('View',4)> <BR><BR>What do these mean? The first one I can reproduce by going off hook and<BR>waiting for dial tone to time out. Is that all such an entry could<BR>mean? What about the second one?<BR><BR>Thanks<BR>jeff<BR>CONFIDENTIALITY NOTICE: The information contained in this email including attachments is intended for the specific delivery to
and use by the individual(s) to whom it is addressed, and includes information which should be considered as private and confidential. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you have received this message in error, please reply to the sender immediately and delete the original message and any copy of it from your computer system. Thank you.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/40cdc442/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/40cdc442/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 11<BR>Date: Tue, 27 Oct 2009 14:42:28 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com"
ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Jeff Ruttman <<A href="mailto:ruttmanj@carewisc.org" ymailto="mailto:ruttmanj@carewisc.org">ruttmanj@carewisc.org</A>><BR>Cc: "Cisco VOIP Newsletter - puck.nether.net"<BR> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] Interpret CDR Search Results<BR>Message-ID: <<A href="mailto:13323F5E-5CEB-4E7B-8BE0-2199CF7221EE@cisco.com" ymailto="mailto:13323F5E-5CEB-4E7B-8BE0-2199CF7221EE@cisco.com">13323F5E-5CEB-4E7B-8BE0-2199CF7221EE@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>Take a look at <A href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html"
target=_blank>http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html</A> <BR>.<BR><BR>The first one you can correlate by the fact that there is no called <BR>party number and the lack of any media information.<BR>The second one was a call to your phone that seems to have no calling <BR>party number and only partial media information.<BR><BR>You can take the GCID and search CCM traces to find more info if you <BR>really want.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:<BR><BR>Greetings,<BR><BR>In the results of a CDR Search by Extension, I see entries like these:<BR><BR>Sl No Call Type GCID CMId<BR>GCID CallId Orig Node Id<BR>Dest Node Id Orig Leg Id<BR>Dest Leg Id Calling No<BR>Calling No Partition Called No<BR>Called No Partition Dest No<BR>Dest No
Partition Last Rd No<BR>Last Rd No Partition <BR>Media Info<BR>Orig Pkts Rcd Dest Pkts Rcd<BR>Orig Pkts Lost Dest Pkts Lost<BR>CDR - CMR Dump<BR><BR>33 Simple 3<BR>2155334 3<BR>0 50453618<BR>50453619 6174<BR>Phones null<BR>null null<BR>null null<BR>null null null Others<BR>null null View<BR><BR><BR>24 Simple 3<BR>2155266 3<BR>3 50453393<BR>50453394 null<BR>null 6174<BR>Phones 6174<BR>Phones 6174<BR>Phones 2954
null Others<BR>0 null View<BR><BR>What do these mean? The first one I can reproduce by going off hook <BR>and waiting for dial tone to time out. Is that all such an entry <BR>could mean? What about the second one?<BR><BR>Thanks<BR>jeff<BR><BR>CONFIDENTIALITY NOTICE: The information contained in this email <BR>including attachments is intended for the specific delivery to and use <BR>by the individual(s) to whom it is addressed, and includes information <BR>which should be considered as private and confidential. Any review, <BR>retransmission, dissemination, or taking of any action in reliance <BR>upon this information by anyone other than the intended recipient is <BR>prohibited. If you have received this message in error, please reply <BR>to the sender
immediately and delete the original message and any copy <BR>of it from your computer system. Thank you.<BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/a6ce6439/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/a6ce6439/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 12<BR>Date: Tue, 27 Oct 2009 14:48:21 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com"
ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271148tecac9e4u2c7dcb406d95b964@mail.gmail.com" ymailto="mailto:a54820e50910271148tecac9e4u2c7dcb406d95b964@mail.gmail.com">a54820e50910271148tecac9e4u2c7dcb406d95b964@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>The difference I see between the invite and the 183 session progression from<BR>the telco is<BR><BR>invite<BR>a=fmtp:101 0-15<BR><BR>session progression<BR>a=fmtp:101 0-16<BR><BR>Could this miss match in supported digits be what is causing all
dtmf not to<BR>work? How can I make my cisco router support 0-16?<BR><BR>Dane<BR><BR>*Invite*<BR>**<BR>**<BR>v=0<BR>o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57<BR>s=SIP Call<BR>c=IN IP4 173.14.220.57<BR>t=0 0<BR>m=audio 18770 RTP/AVP 0 101 19<BR>c=IN IP4 173.14.220.57<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-15<BR>a=rtpmap:19 CN/8000<BR>a=ptime:20<BR><BR><BR><BR>*session progression*<BR><BR><BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 17646 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR><BR>> Sorry this part is the actual DTMF:<BR>><BR>> a=rtpmap:101 telephone-event/8000<BR>><BR>> The line
you quoted is part of the SDP and references both RTP and DTMF.<BR>> m=audio 11680 RTP/AVP 0 101<BR>> a=rtpmap:0 PCMU/8000<BR>> a=rtpmap:101 telephone-event/8000<BR>> a=fmtp:101 0-16<BR>> a=silenceSupp:off - - - -<BR>><BR>> The fist line means your RTP is on port 11680 and references the a:rtpmap<BR>> entries for 0 and 101.<BR>> The second line means your RTP is g.711.<BR>> The 3rd line is the DTMF with a payload type of 101.<BR>> The 4th line means it can accept DTMF 0-16<BR>> The last line is pretty self explanatory (silence suppression disabled).<BR>><BR>> This is a very basic interpretation of the SDP info. RFC 2327 is where you<BR>> want to go to get into the nitty-gritty details.<BR>><BR>> -Ryan<BR>><BR>> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR>><BR>> That is RFC2833 DTMF with a payload type of 101.<BR>><BR>> I do know that CUBE cannot do
dynamic RFC2833 payload types. It can only<BR>> send the payloadType defined in the voip dial-peer. So if inbound calls use<BR>> a different payloadType than outbound calls you will want to update the<BR>> dial-peers accordingly.<BR>><BR>><BR>> -Ryan<BR>><BR>> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR>><BR>> Well I tried to switch providers just to test it out and now I am getting<BR>> something back in the 183 but still no dtmf hmm<BR>><BR>> I see they are sending me<BR>><BR>> m=audio 11680 RTP/AVP 0 101<BR>><BR>> How do I interperate that line?<BR>><BR>><BR>> Received:<BR>> SIP/2.0 183 Session Progress<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060<BR>> ;branch=z9hG4bK749136B;received=173.14.220.57<BR>> From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A> <sip%<A
href="mailto:3A6782282221@did.voip.les.net" ymailto="mailto:3A6782282221@did.voip.les.net">3A6782282221@did.voip.les.net</A>><BR>> >;tag=419FE94-8A1<BR>> To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A> <sip%<A href="mailto:3A18774675464@did.voip.les.net" ymailto="mailto:3A18774675464@did.voip.les.net">3A18774675464@did.voip.les.net</A>><BR>> >;tag=as5677a12c<BR>> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>> CSeq: 101 INVITE<BR>> User-Agent: LES.NET.VoIP<BR>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>> Contact: <sip:18774675464@64.34.181.47 <sip%3A18774675464@64.34.181.47>><BR>> Content-Type: application/sdp<BR>> Content-Length: 214<BR>> v=0<BR>> o=root 5115 5115 IN IP4 64.34.181.47<BR>> s=session<BR>> c=IN IP4 64.34.181.47<BR>> t=0 0<BR>> m=audio
11680 RTP/AVP 0 101<BR>> a=rtpmap:0 PCMU/8000<BR>> a=rtpmap:101 telephone-event/8000<BR>> a=fmtp:101 0-16<BR>> a=silenceSupp:off - - - -<BR>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:<BR>> INVITE response with no RSEQ - disable IS_REL1XX<BR>> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No<BR>> GTD found in inbound container<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>> SIP: Attribute mid, level 1 instance 1 not found.<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already<BR>> bound, use existing source_media_ip_addr<BR>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:<BR>> Media src addr for stream 1 = 173.14.220.57<BR>> *Oct 27 18:02:12.551:<BR>>
//1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)<BR>> Negotiation Successful on Static Payload for m-line 1<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or<BR>> multiple ptime attributes that can't be handled<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)<BR>> could not be reserved.<BR>> *Oct 27 18:02:12.551:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>> relay option<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>> named event(NE) match in fmtp list of events.<BR>> *Oct 27 18:02:12.555:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
payload<BR>> from X-cap = 0<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>> present in SDP. Disable modem relay<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction<BR>> attribute present or multiple direction attributes that can't be handled for<BR>> m-line:1 and num-a-lines:0<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation<BR>> successful for media line 1<BR>> payload_type=0, codec_bytes=160, codec=g711ulaw, dtmf_relay=rtp-nte<BR>> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,<BR>> dest_port=11680<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =<BR>> -1) State changed from (STREAM_DEAD) to
(STREAM_ADDING)<BR>> *Oct 27 18:02:12.555:<BR>> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>> Preferred Codec : g711ulaw, bytes :160<BR>> Preferred DTMF relay : rtp-nte<BR>> Preferred NTE payload : 101<BR>> Early Media : No<BR>> Delayed Media : No<BR>> Bridge Done : No<BR>> New Media : No<BR>> DSP DNLD Reqd : No<BR>><BR>> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com"
ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>>wrote:<BR>><BR>>> The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>>> a 200 OK with the CSeq for 101 INVITE.<BR>>><BR>>> I've seen this for certain IVRs/providers - sometimes they don't<BR>>> properly terminate a call with a 200 OK. If you were not sending an<BR>>> SDP in your original INVITE, then you would need the PRACK setting<BR>>> mentioned. You have two problems, either could fix the problem: They<BR>>> could advertise DTMF in their 183, or they could send you a 200 OK for<BR>>> the call. It is assumed you would get DTMF in the 200 OK. It's<BR>>> common for endpoints that support DTMF to not advertise it in the 183<BR>>> because you technically shouldn't need DTMF to hear
ringback.<BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR>>> > There is no SDP in that 200 OK so I would assume the media info is the<BR>>> same<BR>>> > as in the 183 Ringing message. You really need your ITSP to tell you<BR>>> what<BR>>> > dtmf method they want you to use on your outbound calls. As Nick said<BR>>> they<BR>>> > don't appear to be advertising any dtmf method at all.<BR>>> > -Ryan<BR>>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>>> > Is the below the ok I should be getting?<BR>>> ><BR>>> ><BR>>> > They did send this with the first debug<BR>>> ><BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via:
SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=32DA608-109A<BR>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>>> > *Oct 27
13:44:12.836:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 13:44:12.840:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 13:44:12.840:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 13:44:12.840:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> ><BR>>> > This with the 2nd debug<BR>>> ><BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A
href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> > *Oct 27 12:34:15.912:<BR>>>
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.912:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 487 Request Terminated<BR>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> >;tag=3465630735-938664<BR>>> > From: <sip:<A
href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Content-Length: 0<BR>>> ><BR>>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>> wrote:<BR>>> >><BR>>> >> In the 183 Session Progress they're not advertising DTMF:<BR>>> >><BR>>> >> m=audio 45846 RTP/AVP 0<BR>>>
>><BR>>> >> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>> >> You would want to pick up on the other side and they should send a 200<BR>>> >> OK with a new SDP. If the other side did pick up, you need to tell<BR>>> >> the provider that they need to send a 200 OK, because they're not.<BR>>> >><BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> >> wrote:<BR>>> >> > Nick<BR>>> >> ><BR>>> >> > I removed voice-class sip asymmetric payload dtmf and added in the<BR>>> >> > other<BR>>> >> > line<BR>>> >> ><BR>>> >> > Just to state incoming
dtmf works but not outbound the ITSP has told<BR>>> me<BR>>> >> > they<BR>>> >> > are using two different sip servers/vendors for processing inbound<BR>>> and<BR>>> >> > outbound<BR>>> >> > How does this translate into what I should sent the following too?<BR>>> >> ><BR>>> >> > rtp payload-type nse<BR>>> >> > rtp payload-type nte<BR>>> >> ><BR>>> >> > In the debug trhe following where set<BR>>> >> ><BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> ><BR>>> >> > In the debug of ccsip If I am looking at it correctly I see me<BR>>> sending<BR>>> >> > this<BR>>> >> ><BR>>> >> > *Oct 27 12:34:09.128:<BR>>> >> >
//846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>> >> > Preferred method of dtmf relay is: 6, with payload: 100<BR>>> >> > *Oct 27 12:34:09.128:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>> >> > max_event 15<BR>>> >> ><BR>>> >> > and<BR>>> >> ><BR>>> >> ><BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> >> > payload<BR>>> >> > from X-cap = 0<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>> >> > present<BR>>> >> > in SDP. Disable modem relay<BR>>> >> ><BR>>> >> ><BR>>> >> > Sent:<BR>>>
>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>> >> > Remote-Party-ID:<BR>>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>>> >;party=calling;screen=yes;privacy=off<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> ><BR>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >>
> Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> >> > Min-SE: 1800<BR>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> >> > SUBSCRIBE,<BR>>> >> > NOTIFY, INFO, REGISTER<BR>>> >> > CSeq: 101 INVITE<BR>>> >> > Max-Forwards: 70<BR>>> >> > Timestamp: 1256646849<BR>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> >> > Expires: 180<BR>>> >> > Allow-Events: telephone-event<BR>>> >> > Content-Type: application/sdp<BR>>> >> > Content-Disposition: session;handling=required<BR>>> >> > Content-Length: 250<BR>>> >> > v=0<BR>>> >> >
o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> >> > s=SIP Call<BR>>> >> > c=IN IP4 173.14.220.57<BR>>> >> > t=0 0<BR>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>> >> > c=IN IP4 173.14.220.57<BR>>> >> > a=rtpmap:0 PCMU/8000<BR>>> >> > a=rtpmap:100 telephone-event/8000<BR>>> >> > a=fmtp:100 0-15<BR>>> >> > a=ptime:20<BR>>> >> ><BR>>> >> ><BR>>> >> > Then when I do a search for fmtp again further down I see<BR>>> >> ><BR>>> >> > Sent:<BR>>> >> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> >> > Remote-Party-ID:<BR>>> >> > <sip:6782282221@173.14.220.57
<sip%3A6782282221@173.14.220.57><BR>>> >;party=calling;screen=yes;privacy=off<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> ><BR>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> >> > Min-SE: 1800<BR>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> >> > User-Agent:
Cisco-SIPGateway/IOS-12.x<BR>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> >> > SUBSCRIBE,<BR>>> >> > NOTIFY, INFO, REGISTER<BR>>> >> > CSeq: 102 INVITE<BR>>> >> > Max-Forwards: 70<BR>>> >> > Timestamp: 1256646849<BR>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> >> > Expires: 180<BR>>> >> > Allow-Events: telephone-event<BR>>> >> > Proxy-Authorization: Digest<BR>>> >> ><BR>>> >> > username="1648245954",realm="64.154.41.110",uri="<BR>>> sip:18774675464@64.154.41.200:5060<BR>>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>> >> > Content-Type: application/sdp<BR>>> >> > Content-Disposition:
session;handling=required<BR>>> >> > Content-Length: 250<BR>>> >> > v=0<BR>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> >> > s=SIP Call<BR>>> >> > c=IN IP4 173.14.220.57<BR>>> >> > t=0 0<BR>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>> >> > c=IN IP4 173.14.220.57<BR>>> >> > a=rtpmap:0 PCMU/8000<BR>>> >> > a=rtpmap:100 telephone-event/8000<BR>>> >> > a=fmtp:100 0-15<BR>>> >> > a=ptime:20<BR>>> >> > *Oct 27 12:34:09.332:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> >> > *Oct 27 12:34:09.332:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >> >
ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> >> > *Oct 27 12:34:09.332:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> >> > context=0x00000000<BR>>> >> > *Oct 27 12:34:09.332:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> >> > Checking Invite Dialog<BR>>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> >> > Received:<BR>>> >> > SIP/2.0 100 Trying<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net"
ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> ><BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >> > CSeq: 102 INVITE<BR>>> >> > Content-Length: 0<BR>>> >> > *Oct 27 12:34:09.332:<BR>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to<BR>>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>> >> > *Oct 27 12:34:10.832:<BR>>> >> >
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> >> > *Oct 27 12:34:10.832:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> >> > *Oct 27 12:34:10.832:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> >> > context=0x00000000<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> >> > Checking Invite Dialog<BR>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> >> > Received:<BR>>> >> > SIP/2.0 183 Session Progress<BR>>> >> > To: <sip:18774675464@64.154.41.200
<sip%3A18774675464@64.154.41.200><BR>>> >;tag=3465630735-938664<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >> > CSeq: 102 INVITE<BR>>> >> > Content-Type: application/sdp<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> >> > Content-Length: 146<BR>>> >> > v=0<BR>>> >> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>> >> > s=sip call<BR>>> >> > c=IN
IP4 64.154.41.101<BR>>> >> > t=0 0<BR>>> >> > m=audio 45846 RTP/AVP 0<BR>>> >> > a=ptime:20<BR>>> >> > a=rtpmap:0 PCMU/8000<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:<BR>>> No<BR>>> >> > GTD<BR>>> >> > found in inbound container<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>> >> > Number of m-lines = 1<BR>>> >> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>
>> > already<BR>>> >> > bound, use existing source_media_ip_addr<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line<BR>>> 1<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>> >> > One ptime attribute found - value:20<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values<BR>>> :Codec:<BR>>> >> > g711ulaw ptime :20, codecbytes: 160<BR>>> >> > *Oct 27
12:34:10.836:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>> :Codec:<BR>>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160 for<BR>>> >> > codec<BR>>> >> > g711ulaw<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line<BR>>> index 1<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>> >> > Dynamic payload(100) could not be reserved.<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation:
Case of<BR>>> full<BR>>> >> > named<BR>>> >> > event(NE) match in fmtp list of events.<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> >> > payload<BR>>> >> > from X-cap = 0<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>> >> > present<BR>>> >> > in SDP. Disable modem relay<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No<BR>>> direction<BR>>> >> > attribute present or multiple direction attributes that can't be<BR>>> handled<BR>>> >> > for<BR>>> >> > m-line:1 and num-a-lines:0<BR>>> >> > *Oct 27
12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> >> > Codec negotiation successful for media line 1<BR>>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>> >> > dtmf_relay=rtp-nte<BR>>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>> >> > dest_port=45846<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>> >> > (STREAM_ADDING)<BR>>> >> > *Oct 27 12:34:10.836:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> >> > Preferred Codec :
g711ulaw, bytes :160<BR>>> >> > Preferred DTMF relay : rtp-nte<BR>>> >> > Preferred NTE payload : 100<BR>>> >> > Early Media : No<BR>>> >> > Delayed Media : No<BR>>> >> > Bridge Done : No<BR>>> >> > New Media : No<BR>>> >> > DSP DNLD Reqd : No<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>> >> > already<BR>>> >> > bound, use
existing source_media_ip_addr<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> >> > callId 846 size 240 ptr 0x4A170B28)<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> >> > Hndl ptype 0 mline 1<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> >> > Selecting<BR>>> >> > codec g711ulaw<BR>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>> >> > Codec to be matched: 5<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD<BR>>> >> > AUDIO<BR>>> >> > CODEC 5<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>> :Codec:<BR>>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >>
> //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> Media<BR>>> >> > negotiation done:<BR>>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,<BR>>> coverted<BR>>> >> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1<BR>>> >> > 64.154.41.101:45846<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy<BR>>> >> > sdp to<BR>>> >> > channel- AFTER CODEC FILTERING:<BR>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>> >> > *Oct 27
12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy<BR>>> >> > sdp to<BR>>> >> > channel- AFTER CODEC FILTERING:<BR>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> >> > Report initial call media<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> ccb->flags<BR>>> >> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>> >> > *Oct 27 12:34:10.840:
//846/8094E28C1800/SIP/Info/copy_channels:<BR>>> >> > callId 846 size 240 ptr 0x4DEC000C)<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>> >> > 5030: Posting Remote SRTP caps to other callleg.<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>> >> > cc_api_caps_ind()<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> >> > Stream type : voice+dtmf<BR>>> >> > Media line : 1<BR>>> >> > State
: STREAM_ADDING (2)<BR>>> >> > Stream address type : 1<BR>>> >> > Callid : 846<BR>>> >> > Negotiated Codec : g711ulaw, bytes :160<BR>>> >> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>> >> > Negotiated DTMF relay : rtp-nte<BR>>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>> >> > Negotiated CN payload : 0<BR>>> >> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>> >> >
Media Dest Addr/Port : [64.154.41.101]:45846<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>> >> > headers<BR>>> >> > recvd from app container<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:<BR>>> >> > No<BR>>> >> > QSIG Body found in inbound container<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:<BR>>> >> > No<BR>>> >> > RawMsg Body found in inbound container<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:<BR>>> >> > No<BR>>> >> > Data to form The Raw Message<BR>>> >> > *Oct 27 12:34:10.840:<BR>>> >> >
//846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>> >> > SUBSTATE_NONE)<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction<BR>>> >> > Complete. Lock on Facilities released.<BR>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> confID =<BR>>> >> > 6,<BR>>> >> > srcCallID = 846, dstCallID = 845<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> >
//846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> >> > Old streamcallid=846, new streamcallid=846<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>> >> > Setting SPI mode to SIP-H323<BR>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = 1131891908<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>> >> > sipSPIProcessRtpSessions<BR>>> >> > *Oct 27 12:34:10.844:
//846/8094E28C1800/SIP/Media/sipSPIAddStream:<BR>>> >> > Adding<BR>>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>> >> > already<BR>>> >> > bound, use existing source_media_ip_addr<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>> >> > *Oct 27 12:34:10.844:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> >> > sipSPIUpdateRtcpSession for m-line 1<BR>>> >> > *Oct 27 12:34:10.848:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> >> > rtcp_session
info<BR>>> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,<BR>>> >> > rport=45846, do_rtcp=TRUE<BR>>> >> > src_callid = 846, dest_callid = 845, stream type =<BR>>> voice+dtmf,<BR>>> >> > stream direction = SENDRECV<BR>>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0<BR>>> media_addr_type =<BR>>> >> > 1<BR>>> >> > *Oct 27 12:34:10.848:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> >> > RTP session already created - update<BR>>> >> > *Oct 27 12:34:10.848:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> >> > stun is disabled for stream:4A1709F8<BR>>> >> > *Oct 27 12:34:10.848:<BR>>> >> >
//846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>> >> > New Remote Media Direction = SENDRECV<BR>>> >> > Present Local Media Direction = SENDRECV<BR>>> >> > New Local Media Direction = SENDRECV<BR>>> >> > retVal = 0<BR>>> >> > *Oct 27 12:34:10.848:<BR>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>> >> > (STREAM_ACTIVE)<BR>>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> really<BR>>> >> > can't<BR>>> >> > find peer_stream for<BR>>> >> >
dtmf-relay<BR>>> interworking<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Entry<BR>>> >> > *Oct 27 12:34:11.140:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>> CURRENT<BR>>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>> >> > *Oct 27 12:34:11.140:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> >> > VALUES:<BR>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Load<BR>>> >> > DSP<BR>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>> >> > *Oct 27 12:34:11.140:
//846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set<BR>>> >> > forking flag to 0x0<BR>>> >> > *Oct 27 12:34:11.140:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx<BR>>> payload =<BR>>> >> > 100, tx payload = 100<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> >> > config=0<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Disabling Modem Relay...<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>>> >> >
Xcap<BR>>> >> > list<BR>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Modem<BR>>> >> > Relay & Passthru both disabled<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > nse<BR>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>> relay=0,<BR>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> >> > *Oct 27 12:34:11.144:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > 1<BR>>> >> > Active Streams<BR>>> >> > *Oct 27 12:34:11.144:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > Adding stream type (voice+dtmf) from media<BR>>> >> > line 1 codec
g711ulaw<BR>>> >> > *Oct 27 12:34:11.144:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> >> > caps.stream_list.xmitFunc=<BR>>> >> > *Oct 27 12:34:11.144:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>>> >> > *Oct 27 12:34:11.144:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > 0x497E0B60 (gccb)<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Load<BR>>> >> > DSP<BR>>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip =
0x200405<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>>> >> > video<BR>>> >> > caps detected in the caps posted by peer leg<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> >> > Setting<BR>>> >> > CAPS_RECEIVED flag<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> >> > Calling<BR>>> >> > cc_api_caps_ack()<BR>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack: Set<BR>>> >> > forking flag to 0x0<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Entry<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>>
CURRENT<BR>>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> >> > VALUES:<BR>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Load<BR>>> >> > DSP<BR>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set<BR>>> >> > forking flag to 0x0<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx<BR>>> payload =<BR>>> >> > 100, tx payload =
100<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> >> > config=0<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Disabling Modem Relay...<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>>> >> > Xcap<BR>>> >> > list<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > Modem<BR>>> >> > Relay & Passthru both disabled<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>> >> > nse<BR>>> >> >
payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>> relay=0,<BR>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > 1<BR>>> >> > Active Streams<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > Adding stream type (voice+dtmf) from media<BR>>> >> > line 1 codec g711ulaw<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> >> > caps.stream_list.xmitFunc=<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> >
voip_rtp_xmit, caps.stream_list.context=<BR>>> >> > *Oct 27 12:34:11.168:<BR>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>> >> > 0x497E0B60 (gccb)<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Load<BR>>> >> > DSP<BR>>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>>> >> > video<BR>>> >> > caps detected in the caps posted by peer leg<BR>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> Second<BR>>> >> > TCS<BR>>> >> > received for transfers
across trunk - set CAPS2_RECEIVED<BR>>> >> > *Oct 27 12:34:15.876:<BR>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> >> > stun is disabled for stream:4A1709F8<BR>>> >> > *Oct 27 12:34:15.876:<BR>>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:<BR>>> >> > Stats are not supported for IPIP call.<BR>>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>> >> > Queued<BR>>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:<BR>>> >> > Associated container=0x4E310C1C to
Cancel<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:<BR>>> >> > Sending CANCEL to the transport layer<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> >> > msg=0x4DF0D994,<BR>>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,<BR>>> >> > switch=0, callBack=0x419703BC<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> Proceedable<BR>>> >> > for<BR>>> >> > sending msg immediately<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>> >> > transport<BR>>> >> > is 0<BR>>>
>> > *Oct 27 12:34:15.880:<BR>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to<BR>>> send<BR>>> >> > the<BR>>> >> > msg=0x4DF0D994<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting<BR>>> >> > send<BR>>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP<BR>>> >> > *Oct 27 12:34:15.880:<BR>>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>> >> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, SUBSTATE_NONE)<BR>>> >> > to<BR>>> >> > (STATE_DISCONNECTING,
SUBSTATE_NONE)<BR>>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> >> > Sent:<BR>>> >> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> ><BR>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >> > CSeq: 102 CANCEL<BR>>> >>
> Max-Forwards: 70<BR>>> >> > Timestamp: 1256646855<BR>>> >> > Reason: Q.850;cause=16<BR>>> >> > Content-Length: 0<BR>>> >> > *Oct 27 12:34:15.900:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> >> > *Oct 27 12:34:15.900:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> >> > *Oct 27 12:34:15.900:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> >> > context=0x00000000<BR>>> >> > *Oct 27 12:34:15.900:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> >> > Checking Invite Dialog<BR>>> >> >
*Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> >> > Received:<BR>>> >> > SIP/2.0 200 OK<BR>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>> >;tag=2EDA9C8-25D6<BR>>> >> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>> ><BR>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> >> > CSeq: 102 CANCEL<BR>>> >> > Content-Length: 0<BR>>> >> > *Oct 27 12:34:15.900:<BR>>>
//846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> >> > *Oct 27 12:34:15.912:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> >> > *Oct 27 12:34:15.912:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> >> > *Oct 27 12:34:15.912:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> >> > context=0x00000000<BR>>> >> > *Oct 27
12:34:15.912:<BR>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> >> > Checking Invite Dialog<BR>>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> >> ><BR>>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>> >> > wrote:<BR>>> >> >><BR>>> >> >> You would want to check the SDP of 200 OK the provider sends for<BR>>> your<BR>>> >> >> outgoing call. It will list the payload type for the dtmf in the<BR>>> >> >> format a=fmtp 101 1-16, or something similar. You want to find out<BR>>> >> >> what payload type they are advertising (or if they are at all). It<BR>>> >> >> would be worth
checking the incoming INVITE from them to see what<BR>>> >> >> they're using when they send the first SDP.<BR>>> >> >><BR>>> >> >> On that note, I would also remove the asymmetric payload command -<BR>>> to<BR>>> >> >> my knowledge it doesn't do what you're expecting it to. You may<BR>>> want<BR>>> >> >> to try this command:<BR>>> >> >> voice-class sip dtmf-relay force rtp-nte<BR>>> >> >><BR>>> >> >><BR>>> >> >> -nick<BR>>> >> >><BR>>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A><BR>>> ><BR>>> >> >> wrote:<BR>>> >> >> > Hello,<BR>>> >> >> ><BR>>> >>
>> > I am having an issue with dtmf working outbound. Inbound dtmf<BR>>> works<BR>>> >> >> > fine.<BR>>> >> >> > It took some playing around with it. At first it didnt work till<BR>>> the<BR>>> >> >> > payload was ajusted. I am now trying to get outbound dtmf<BR>>> working<BR>>> >> >> > properly.<BR>>> >> >> ><BR>>> >> >> > On my 2821 I debugged voip rtp session named-events and then made<BR>>> a<BR>>> >> >> > call<BR>>> >> >> > to<BR>>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on the<BR>>> >> >> > router<BR>>> >> >> > nothing showed up in the debug. Does this mean I can safely asume<BR>>> >> >> >
that<BR>>> >> >> > the<BR>>> >> >> > problem for right now is not on the ITSP side but on my side since<BR>>> >> >> > dtmf<BR>>> >> >> > is<BR>>> >> >> > not being sent down the sip trunk?<BR>>> >> >> ><BR>>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>> >> >> > configuration<BR>>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas what<BR>>> I<BR>>> >> >> > can<BR>>> >> >> > do<BR>>> >> >> > so dtmf digits process properly outbound?<BR>>> >> >> ><BR>>> >> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>> >> >> ><BR>>> >> >> > h323 cucm
gateway configuratration<BR>>> >> >> > Signaling Port 1720<BR>>> >> >> > media termination point required yes<BR>>> >> >> > retry video call as auto yes<BR>>> >> >> > wait for far end h.245 terminal capability set yes<BR>>> >> >> > transmit utf-8 calling party name no<BR>>> >> >> > h.235 pass through allowed no<BR>>> >> >> > significant digits all<BR>>> >> >> > redirect number IT deliver - inbound no<BR>>> >> >> > enable inbound faststart yes<BR>>> >> >> > display IE deliver no<BR>>> >> >> > redirect nunmber IT deliver - outbound no<BR>>> >> >> > enable outbound faststart yes<BR>>> >> >> ><BR>>> >> >> ><BR>>> >> >> > voice service
voip<BR>>> >> >> > allow-connections h323 to h323<BR>>> >> >> > allow-connections h323 to sip<BR>>> >> >> > allow-connections sip to h323<BR>>> >> >> > allow-connections sip to sip<BR>>> >> >> > fax protocol pass-through g711ulaw<BR>>> >> >> > h323<BR>>> >> >> > emptycapability<BR>>> >> >> > h225 id-passthru<BR>>> >> >> > h245 passthru tcsnonstd-passthru<BR>>> >> >> > sip<BR>>> >> >> ><BR>>> >> >> ><BR>>> >> >> > voice class h323 50<BR>>> >> >> > h225 timeout tcp establish 3<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>>
>> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > voice translation-rule 1<BR>>> >> >> > rule 1 /.*/ /190/<BR>>> >> >> > !<BR>>> >> >> > voice translation-rule 2<BR>>> >> >> > rule 1 /.*/ /1&/<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > voice translation-profile aa<BR>>> >> >> > translate called 1<BR>>> >> >> > !<BR>>> >> >> > voice translation-profile addone<BR>>> >> >> > translate called 2<BR>>> >> >> >
!<BR>>> >> >> > !<BR>>> >> >> > voice-card 0<BR>>> >> >> > dspfarm<BR>>> >> >> > dsp services dspfarm<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > sccp local GigabitEthernet0/1<BR>>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>> >> >> > sccp<BR>>> >> >> > !<BR>>> >> >> > sccp ccm group 1<BR>>> >> >> > associate ccm 1 priority 1<BR>>> >> >> > associate ccm 2 priority 2<BR>>> >> >> > associate profile 1 register 2821transcode<BR>>> >> >> > !<BR>>> >> >> > dspfarm profile 1 transcode<BR>>> >>
>> > codec g711ulaw<BR>>> >> >> > codec g711alaw<BR>>> >> >> > codec g729ar8<BR>>> >> >> > codec g729abr8<BR>>> >> >> > codec g729r8<BR>>> >> >> > maximum sessions 4<BR>>> >> >> > associate application SCCP<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > dial-peer voice 100 voip<BR>>> >> >> > description AA Publisher<BR>>> >> >> > preference 1<BR>>> >> >> > destination-pattern 1..<BR>>> >> >> > voice-class h323 50<BR>>> >> >> > session target ipv4:10.1.80.10<BR>>> >> >> > dtmf-relay h245-alphanumeric<BR>>> >> >> > codec
g711ulaw<BR>>> >> >> > no vad<BR>>> >> >> > !<BR>>> >> >> > dial-peer voice 1000 voip<BR>>> >> >> > description incoming Call<BR>>> >> >> > translation-profile incoming aa<BR>>> >> >> > preference 1<BR>>> >> >> > rtp payload-type nse 101<BR>>> >> >> > rtp payload-type nte 100<BR>>> >> >> > incoming called-number 6782282221<BR>>> >> >> > dtmf-relay rtp-nte<BR>>> >> >> > codec g711ulaw<BR>>> >> >> > ip qos dscp cs5 media<BR>>> >> >> > ip qos dscp cs5 signaling<BR>>> >> >> > no vad<BR>>> >> >> > !<BR>>> >> >> > dial-peer voice 101 voip<BR>>> >>
>> > description AA Subscriber<BR>>> >> >> > preference 2<BR>>> >> >> > destination-pattern 1..<BR>>> >> >> > voice-class h323 50<BR>>> >> >> > session target ipv4:10.1.80.11<BR>>> >> >> > dtmf-relay h245-alphanumeric<BR>>> >> >> > codec g711ulaw<BR>>> >> >> > no vad<BR>>> >> >> > !<BR>>> >> >> > dial-peer voice 2000 voip<BR>>> >> >> > description outbound<BR>>> >> >> > translation-profile outgoing addone<BR>>> >> >> > preference 1<BR>>> >> >> > destination-pattern .T<BR>>> >> >> > rtp payload-type nse 101<BR>>> >> >> > rtp payload-type nte
100<BR>>> >> >> > voice-class sip asymmetric payload dtmf<BR>>> >> >> > session protocol sipv2<BR>>> >> >> > session target ipv4:64.154.41.200<BR>>> >> >> > dtmf-relay rtp-nte<BR>>> >> >> > codec g711ulaw<BR>>> >> >> > no vad<BR>>> >> >> > !<BR>>> >> >> > !<BR>>> >> >> > sip-ua<BR>>> >> >> > credentials username ***** password 7 ***** realm<BR>>> sip.talkinip.net<BR>>> >> >> > authentication username ***** password 7 *****<BR>>> >> >> > authentication username ***** password 7 ***** realm<BR>>> >> >> > sip.talkinip.net<BR>>> >> >> > set pstn-cause 3
sip-status 486<BR>>> >> >> > set pstn-cause 34 sip-status 486<BR>>> >> >> > set pstn-cause 47 sip-status 486<BR>>> >> >> > registrar dns:sip.talkinip.net expires 60<BR>>> >> >> > sip-server dns:sip.talkinip.net:5060<BR>>> >> >> > _______________________________________________<BR>>> >> >> > cisco-voip mailing list<BR>>> >> >> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> >> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> >> >> ><BR>>> >> >> ><BR>>> >> ><BR>>> >> ><BR>>> ><BR>>> >
_______________________________________________<BR>>> > cisco-voip mailing list<BR>>> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> ><BR>>> ><BR>>><BR>><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A
href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/af939459/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/af939459/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 13<BR>Date: Tue, 27 Oct 2009 14:56:23 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID: <<A href="mailto:A6C76132-8F5E-4424-BB52-B1214B1BD4E6@cisco.com"
ymailto="mailto:A6C76132-8F5E-4424-BB52-B1214B1BD4E6@cisco.com">A6C76132-8F5E-4424-BB52-B1214B1BD4E6@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>I doubt that is related to your lack of DTMF but it's most likely the <BR>side sending the 183 is actually counting 1-16 and printing the 0. <BR>The Session Progress is received by the router isn't it?<BR><BR>There are only 16 DTMF characters, the 12 on your keypad and 4 hidden <BR>ones A, B, C, and D.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:<BR><BR>The difference I see between the invite and the 183 session <BR>progression from the telco is<BR><BR>invite<BR>a=fmtp:101 0-15<BR><BR>session progression<BR>a=fmtp:101 0-16<BR><BR>Could this miss match in supported digits be what is causing all dtmf <BR>not to work? How can I make my cisco router support
0-16?<BR><BR>Dane<BR><BR>Invite<BR><BR><BR>v=0<BR>o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57<BR>s=SIP Call<BR>c=IN IP4 173.14.220.57<BR>t=0 0<BR>m=audio 18770 RTP/AVP 0 101 19<BR>c=IN IP4 173.14.220.57<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-15<BR>a=rtpmap:19 CN/8000<BR>a=ptime:20<BR><BR><BR><BR>session progression<BR><BR><BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 17646 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>Sorry this part is the actual DTMF:<BR><BR>a=rtpmap:101 telephone-event/8000<BR><BR>The line you quoted is part of the SDP and references both RTP and DTMF.<BR>m=audio 11680
RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>The fist line means your RTP is on port 11680 and references the <BR>a:rtpmap entries for 0 and 101.<BR>The second line means your RTP is g.711.<BR>The 3rd line is the DTMF with a payload type of 101.<BR>The 4th line means it can accept DTMF 0-16<BR>The last line is pretty self explanatory (silence suppression disabled).<BR><BR>This is a very basic interpretation of the SDP info. RFC 2327 is <BR>where you want to go to get into the nitty-gritty details.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR><BR>That is RFC2833 DTMF with a payload type of 101.<BR><BR>I do know that CUBE cannot do dynamic RFC2833 payload types. It can <BR>only send the payloadType defined in the voip dial-peer. So if <BR>inbound calls use a different payloadType than outbound calls you
will <BR>want to update the dial-peers accordingly.<BR><BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR><BR>Well I tried to switch providers just to test it out and now I am <BR>getting something back in the 183 but still no dtmf hmm<BR><BR>I see they are sending me<BR><BR>m=audio 11680 RTP/AVP 0 101<BR><BR>How do I interperate that line?<BR><BR><BR>Received:<BR>SIP/2.0 183 Session Progress<BR>Via: SIP/2.0/UDP <BR>173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57<BR>From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A>>;tag=419FE94-8A1<BR>To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A>>;tag=as5677a12c<BR>Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>CSeq: 101 INVITE<BR>User-Agent: LES.NET.VoIP<BR>Allow:
INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>Contact: <sip:18774675464@64.34.181.47><BR>Content-Type: application/sdp<BR>Content-Length: 214<BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX<BR>*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: <BR>No GTD found in inbound container<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>SIP: Attribute mid, level 1 instance 1 not found.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>resolve_media_ip_address_to_bind: Media already bound, use existing
<BR>source_media_ip_addr<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/ <BR>sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on <BR>Static Payload for m-line 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoPtimeNegotiation: No ptime present or multiple ptime <BR>attributes that can't be handled<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
<BR>fmtp list of events.<BR>*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem <BR>relay<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIGetSDPDirectionAttribute: No direction attribute present or <BR>multiple direction attributes that can't be handled for m-line:1 and <BR>num-a-lines:0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1<BR> payload_type=0, codec_bytes=160, codec=g711ulaw, <BR>dtmf_relay=rtp-nte<BR> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47, <BR>dest_port=11680<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/ <BR>sipSPIChangeStreamState: Stream
(callid = -1) State changed from <BR>(STREAM_DEAD) to (STREAM_ADDING)<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/ <BR>sipSPIUpdCallWithSdpInfo:<BR> Preferred Codec : g711ulaw, bytes :160<BR> Preferred DTMF relay : rtp-nte<BR> Preferred NTE payload : 101<BR> Early Media : No<BR> Delayed Media : No<BR> Bridge Done : No<BR> New Media : No<BR> DSP DNLD Reqd : No<BR><BR>On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com"
ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> <BR>wrote:<BR>The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>a 200 OK with the CSeq for 101 INVITE.<BR><BR>I've seen this for certain IVRs/providers - sometimes they don't<BR>properly terminate a call with a 200 OK. If you were not sending an<BR>SDP in your original INVITE, then you would need the PRACK setting<BR>mentioned. You have two problems, either could fix the problem: They<BR>could advertise DTMF in their 183, or they could send you a 200 OK for<BR>the call. It is assumed you would get DTMF in the 200 OK. It's<BR>common for endpoints that support DTMF to not advertise it in the 183<BR>because you technically shouldn't need DTMF to hear ringback.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A
href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>> There is no SDP in that 200 OK so I would assume the media info is <BR>the same<BR>> as in the 183 Ringing message. You really need your ITSP to tell <BR>you what<BR>> dtmf method they want you to use on your outbound calls. As Nick <BR>said they<BR>> don't appear to be advertising any dtmf method at all.<BR>> -Ryan<BR>> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>> Is the below the ok I should be getting?<BR>><BR>><BR>> They did send this with the first debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=32DA608-109A<BR>> To:
<sip:18774675464@64.154.41.200><BR>> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/
<BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>><BR>> This with the 2nd debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> *Oct 27 12:34:15.912:
//-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> Received:<BR>> SIP/2.0 487 Request Terminated<BR>> To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> Contact: <sip:18774675464@64.154.41.200:5060><BR>>
Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 INVITE<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> Content-Length: 0<BR>><BR>> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <BR><<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> In the 183 Session Progress they're not advertising DTMF:<BR>>><BR>>> m=audio 45846 RTP/AVP 0<BR>>><BR>>> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>> You would want to pick up on the other side and they should send a <BR>200<BR>>> OK with a new SDP. If the other side did pick up, you need to tell<BR>>> the provider that they need to send a 200 OK, because they're not.<BR>>><BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A
href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Nick<BR>>> ><BR>>> > I removed voice-class sip asymmetric payload dtmf and added in <BR>the<BR>>> > other<BR>>> > line<BR>>> ><BR>>> > Just to state incoming dtmf works but not outbound the ITSP has <BR>told me<BR>>> > they<BR>>> > are using two different sip servers/vendors for processing <BR>inbound and<BR>>> > outbound<BR>>> > How does this translate into what I should sent the following too?<BR>>> ><BR>>> > rtp payload-type nse<BR>>> > rtp payload-type nte<BR>>> ><BR>>> > In the debug trhe following where set<BR>>> ><BR>>> > rtp payload-type nse 101<BR>>> > rtp payload-type nte 100<BR>>> ><BR>>> > In the
debug of ccsip If I am looking at it correctly I see me <BR>sending<BR>>> > this<BR>>> ><BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>> > Preferred method of dtmf relay is: 6, with payload: 100<BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>> > max_event 15<BR>>> ><BR>>> > and<BR>>> ><BR>>> ><BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> ><BR>>> ><BR>>> >
Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 101 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> ><BR>>> ><BR>>> > Then when I do
a search for fmtp again further down I see<BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>>
> Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 102 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Proxy-Authorization: Digest<BR>>> ><BR>>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464@64.154.41.200:5060 <BR>",response <BR>= <BR>"ab63d4755ff4182631ad2db0f9ed0e44 <BR>",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP
Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite
Dialog<BR>>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 100 Trying<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_SENT_INVITE, <BR>SUBSTATE_NONE)
to<BR>>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 183 Session Progress<BR>>> > To:
<sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Type: application/sdp<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Content-Length: 146<BR>>> > v=0<BR>>> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>> > s=sip call<BR>>> > c=IN IP4 64.154.41.101<BR>>> > t=0 0<BR>>> > m=audio 45846 RTP/AVP 0<BR>>> > a=ptime:20<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE
response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentGTD: No<BR>>> > GTD<BR>>> > found in inbound container<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>> > Number of m-lines = 1<BR>>> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec (g711ulaw) Negotiation
Successful on Static Payload for m- <BR>line 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>> > One ptime attribute found - value:20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: <BR>Values :Codec:<BR>>> > g711ulaw ptime :20, codecbytes: 160<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: <BR>160 for<BR>>> > codec<BR>>> > g711ulaw<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation:
m-line <BR>index 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>> > Dynamic payload(100) could not be reserved.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case <BR>of full<BR>>> > named<BR>>> > event(NE) match in fmtp list of events.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No <BR>direction<BR>>> > attribute
present or multiple direction attributes that can't be <BR>handled<BR>>> > for<BR>>> > m-line:1 and num-a-lines:0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec negotiation successful for media line 1<BR>>> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>> > dtmf_relay=rtp-nte<BR>>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>> > dest_port=45846<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>> > (STREAM_ADDING)<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> >
Preferred Codec : g711ulaw, bytes :160<BR>>> > Preferred DTMF relay : rtp-nte<BR>>> > Preferred NTE payload : 100<BR>>> > Early Media : No<BR>>> > Delayed Media : No<BR>>> > Bridge Done : No<BR>>> > New Media : No<BR>>> > DSP DNLD Reqd : No<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>>
> *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4A170B28)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Hndl ptype 0 mline 1<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Selecting<BR>>> > codec g711ulaw<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>> > Codec to be matched: 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>ADD<BR>>> > AUDIO<BR>>> > CODEC 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Media<BR>>> > negotiation done:<BR>>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160, <BR>coverted<BR>>> > ptime=20 stream->mline_index=1,
media_ndx=1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 <BR>ss 1<BR>>> > 64.154.41.101:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>
> callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > Report initial call media<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: <BR>ccb->flags<BR>>> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4DEC000C)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>> > 5030: Posting Remote SRTP caps to other callleg.<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>> > cc_api_caps_ind()<BR>>> > *Oct 27 12:34:10.840:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Stream type : voice+dtmf<BR>>> > Media line : 1<BR>>> > State : STREAM_ADDING (2)<BR>>> > Stream address type : 1<BR>>> > Callid : 846<BR>>> > Negotiated Codec : g711ulaw, bytes :160<BR>>> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>> > Negotiated DTMF relay : rtp-nte<BR>>> >
Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>> > Negotiated CN payload : 0<BR>>> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>> > headers<BR>>> > recvd from app container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQSIG:<BR>>> > No<BR>>> > QSIG Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQ931:<BR>>> > No<BR>>> > RawMsg Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
<BR>sipSPICreateNewRawMsg:<BR>>> > No<BR>>> > Data to form The Raw Message<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: <BR>Transaction<BR>>> > Complete. Lock on Facilities released.<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>confID =<BR>>> > 6,<BR>>> > srcCallID = 846, dstCallID = 845<BR>>> > *Oct 27 12:34:10.844:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old streamcallid=846, new streamcallid=846<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>> > Setting SPI mode to SIP-H323<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = <BR>1131891908<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>> > sipSPIProcessRtpSessions<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/ <BR>sipSPIAddStream:<BR>>> > Adding<BR>>> > stream 1 of type voice+dtmf (callid 846) to the
VOIP RTP library<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > sipSPIUpdateRtcpSession for m-line 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > rtcp_session info<BR>>> > laddr = 173.14.220.57, lport = 16462, raddr = <BR>64.154.41.101,<BR>>> > rport=45846, do_rtcp=TRUE<BR>>> > src_callid = 846, dest_callid = 845, stream type =
voice <BR>+dtmf,<BR>>> > stream direction = SENDRECV<BR>>> > media_ip_addr = 64.154.41.101, vrf tableid = 0 <BR>media_addr_type =<BR>>> > 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > RTP session already created - update<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>> > New Remote Media Direction = SENDRECV<BR>>> > Present Local Media Direction = SENDRECV<BR>>> > New Local Media Direction = SENDRECV<BR>>> > retVal = 0<BR>>> >
*Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>> > (STREAM_ACTIVE)<BR>>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>really<BR>>> > can't<BR>>> > find peer_stream for<BR>>> > dtmf-relay <BR>interworking<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>> > *Oct 27 12:34:11.140:<BR>>> >
//846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.140:
//846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27
12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind:
ccb->pld.flags_ipip = 0x200405<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Setting<BR>>> > CAPS_RECEIVED flag<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Calling<BR>>> > cc_api_caps_ack()<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ack: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27
12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27
12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> >
*Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind:
ccb->pld.flags_ipip = 0x200425<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Second<BR>>> > TCS<BR>>> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>> > *Oct 27 12:34:15.876:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/ <BR>ccsip_call_statistics:<BR>>> > Stats are not supported for IPIP call.<BR>>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>> > Queued<BR>>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>> > *Oct 27 12:34:15.880:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/ <BR>sipSPISendCancel:<BR>>> > Associated container=0x4E310C1C to Cancel<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/ <BR>sipSPISendCancel:<BR>>> > Sending CANCEL to the transport layer<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> > msg=0x4DF0D994,<BR>>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, <BR>transport=1,<BR>>> > switch=0, callBack=0x419703BC<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage: <BR>Proceedable<BR>>> > for<BR>>> > sending msg immediately<BR>>> > *Oct 27
12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>> > transport<BR>>> > is 0<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set <BR>to send<BR>>> > the<BR>>> > msg=0x4DF0D994<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: <BR>Posting<BR>>> > send<BR>>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for <BR>UDP<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
<BR>SUBSTATE_NONE)<BR>>> > to<BR>>> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Sent:<BR>>> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646855<BR>>> > Reason: Q.850;cause=16<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900:<BR>>> >
//-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> >
ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> ><BR>>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A> <BR>><BR>>> > wrote:<BR>>> >><BR>>> >> You would want to check the SDP of 200 OK the provider sends <BR>for your<BR>>> >> outgoing call. It will list the payload type for the dtmf in the<BR>>> >> format a=fmtp 101 1-16, or something similar. You want to find
<BR>out<BR>>> >> what payload type they are advertising (or if they are at <BR>all). It<BR>>> >> would be worth checking the incoming INVITE from them to see what<BR>>> >> they're using when they send the first SDP.<BR>>> >><BR>>> >> On that note, I would also remove the asymmetric payload <BR>command - to<BR>>> >> my knowledge it doesn't do what you're expecting it to. You <BR>may want<BR>>> >> to try this command:<BR>>> >> voice-class sip dtmf-relay force rtp-nte<BR>>> >><BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A> <BR>><BR>>> >> wrote:<BR>>> >> > Hello,<BR>>> >> ><BR>>>
>> > I am having an issue with dtmf working outbound. Inbound <BR>dtmf works<BR>>> >> > fine.<BR>>> >> > It took some playing around with it. At first it didnt work <BR>till the<BR>>> >> > payload was ajusted. I am now trying to get outbound dtmf <BR>working<BR>>> >> > properly.<BR>>> >> ><BR>>> >> > On my 2821 I debugged voip rtp session named-events and then <BR>made a<BR>>> >> > call<BR>>> >> > to<BR>>> >> > a 1800 number and hit digits. I didn't see any dtmf output <BR>on the<BR>>> >> > router<BR>>> >> > nothing showed up in the debug. Does this mean I can safely <BR>asume<BR>>> >> > that<BR>>> >> > the<BR>>> >> > problem for right now is not on the ITSP side but
on my side <BR>since<BR>>> >> > dtmf<BR>>> >> > is<BR>>> >> > not being sent down the sip trunk?<BR>>> >> ><BR>>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>> >> > configuration<BR>>> >> > of the cisco 2821 is shown below. Does anyone have any ideas <BR>what I<BR>>> >> > can<BR>>> >> > do<BR>>> >> > so dtmf digits process properly outbound?<BR>>> >> ><BR>>> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>> >> ><BR>>> >> > h323 cucm gateway configuratration<BR>>> >> > Signaling Port 1720<BR>>> >> > media termination point required yes<BR>>> >> > retry video call as auto yes<BR>>> >> > wait for far end h.245 terminal
capability set yes<BR>>> >> > transmit utf-8 calling party name no<BR>>> >> > h.235 pass through allowed no<BR>>> >> > significant digits all<BR>>> >> > redirect number IT deliver - inbound no<BR>>> >> > enable inbound faststart yes<BR>>> >> > display IE deliver no<BR>>> >> > redirect nunmber IT deliver - outbound no<BR>>> >> > enable outbound faststart yes<BR>>> >> ><BR>>> >> ><BR>>> >> > voice service voip<BR>>> >> > allow-connections h323 to h323<BR>>> >> > allow-connections h323 to sip<BR>>> >> > allow-connections sip to h323<BR>>> >> > allow-connections sip to sip<BR>>> >> > fax protocol pass-through g711ulaw<BR>>> >> > h323<BR>>> >> >
emptycapability<BR>>> >> > h225 id-passthru<BR>>> >> > h245 passthru tcsnonstd-passthru<BR>>> >> > sip<BR>>> >> ><BR>>> >> ><BR>>> >> > voice class h323 50<BR>>> >> > h225 timeout tcp establish 3<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-rule 1<BR>>> >> > rule 1 /.*/ /190/<BR>>> >> > !<BR>>> >> > voice translation-rule 2<BR>>> >> > rule 1 /.*/ /1&/<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice
translation-profile aa<BR>>> >> > translate called 1<BR>>> >> > !<BR>>> >> > voice translation-profile addone<BR>>> >> > translate called 2<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice-card 0<BR>>> >> > dspfarm<BR>>> >> > dsp services dspfarm<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sccp local GigabitEthernet0/1<BR>>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>> >> > sccp<BR>>> >> > !<BR>>> >> > sccp ccm group 1<BR>>> >> > associate ccm 1 priority 1<BR>>> >> > associate ccm 2 priority 2<BR>>> >> > associate profile 1 register 2821transcode<BR>>>
>> > !<BR>>> >> > dspfarm profile 1 transcode<BR>>> >> > codec g711ulaw<BR>>> >> > codec g711alaw<BR>>> >> > codec g729ar8<BR>>> >> > codec g729abr8<BR>>> >> > codec g729r8<BR>>> >> > maximum sessions 4<BR>>> >> > associate application SCCP<BR>>> >> > !<BR>>> >> > !<BR>>> >> > dial-peer voice 100 voip<BR>>> >> > description AA Publisher<BR>>> >> > preference 1<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.10<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> >
!<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > description incoming Call<BR>>> >> > translation-profile incoming aa<BR>>> >> > preference 1<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > incoming called-number 6782282221<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > ip qos dscp cs5 media<BR>>> >> > ip qos dscp cs5 signaling<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > description AA Subscriber<BR>>> >> > preference 2<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >>
> session target ipv4:10.1.80.11<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > description outbound<BR>>> >> > translation-profile outgoing addone<BR>>> >> > preference 1<BR>>> >> > destination-pattern .T<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > voice-class sip asymmetric payload dtmf<BR>>> >> > session protocol sipv2<BR>>> >> > session target ipv4:64.154.41.200<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> >
!<BR>>> >> > !<BR>>> >> > sip-ua<BR>>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net<BR>>> >> > authentication username ***** password 7 *****<BR>>> >> > authentication username ***** password 7 ***** realm<BR>>> >> > sip.talkinip.net<BR>>> >> > set pstn-cause 3 sip-status 486<BR>>> >> > set pstn-cause 34 sip-status 486<BR>>> >> > set pstn-cause 47 sip-status 486<BR>>> >> > registrar dns:sip.talkinip.net expires 60<BR>>> >> > sip-server dns:sip.talkinip.net:5060<BR>>> >> > _______________________________________________<BR>>> >> > cisco-voip mailing list<BR>>> >> > <A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> >> ><BR>>> >> ><BR>>> ><BR>>> ><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A
href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/4183b841/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/4183b841/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 14<BR>Date: Tue, 27 Oct 2009 14:06:02 -0500<BR>From: "Jeff Ruttman" <<A href="mailto:ruttmanj@carewisc.org" ymailto="mailto:ruttmanj@carewisc.org">ruttmanj@carewisc.org</A>><BR>To: "Ryan Ratliff" <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: "Cisco VOIP Newsletter - puck.nether.net"<BR> <<A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] Interpret CDR Search Results<BR>Message-ID:<BR> <<A href="mailto:07365C3161D8D8419EE51C3834C02205B84F07@ma1-exc01.ec2802.elderc.org" ymailto="mailto:07365C3161D8D8419EE51C3834C02205B84F07@ma1-exc01.ec2802.elderc.org">07365C3161D8D8419EE51C3834C02205B84F07@ma1-exc01.ec2802.elderc.org</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Thanks! I'll have a look at that doc.<BR><BR>On that second one, if the caller had caller ID blocked, would that<BR>produce the "Null"?<BR><BR>jeff<BR><BR>________________________________<BR><BR>From: Ryan Ratliff [mailto:<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>] <BR>Sent: Tuesday, October 27, 2009 1:42 PM<BR>To: Jeff Ruttman<BR>Cc: Cisco VOIP Newsletter - puck.nether.net<BR>Subject: Re: [cisco-voip] Interpret CDR Search
Results<BR><BR><BR>Take a look at<BR><A href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/c" target=_blank>http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/c</A><BR>arcdrdef.html. <BR><BR>The first one you can correlate by the fact that there is no called<BR>party number and the lack of any media information. <BR>The second one was a call to your phone that seems to have no calling<BR>party number and only partial media information. <BR><BR>You can take the GCID and search CCM traces to find more info if you<BR>really want. <BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:<BR><BR>Greetings,<BR><BR>In the results of a CDR Search by Extension, I see entries like these:<BR><BR>Sl No Call Type GCID CMId<BR>GCID CallId Orig Node Id<BR>Dest Node Id Orig Leg Id<BR>Dest Leg Id Calling
No<BR>Calling No Partition Called No<BR>Called No Partition Dest No<BR>Dest No Partition Last Rd No<BR>Last Rd No Partition Media Info <BR>Orig Pkts Rcd Dest Pkts Rcd <BR>Orig Pkts Lost Dest Pkts Lost <BR>CDR - CMR Dump <BR><BR>33 Simple 3<BR>2155334 3<BR>0 50453618<BR>50453619 6174<BR>Phones null<BR>null null<BR>null null<BR>null null null Others<BR><javascript:fnDetails('Others',13)> <BR>null null View <javascript:fnDetails('View',13)><BR><BR><BR><BR>24
Simple 3<BR>2155266 3<BR>3 50453393<BR>50453394 null<BR>null 6174<BR>Phones 6174<BR>Phones 6174<BR>Phones 2954 null Others<BR><javascript:fnDetails('Others',4)> <BR>0 null View <javascript:fnDetails('View',4)> <BR><BR>What do these mean? The first one I can reproduce by going off hook and<BR>waiting for dial tone to time out. Is that all such an entry could<BR>mean? What about the second one?<BR><BR>Thanks<BR>jeff<BR><BR>CONFIDENTIALITY NOTICE: The information contained in this email<BR>including attachments is intended for the specific delivery to and use<BR>by the individual(s) to whom it is addressed, and includes
information<BR>which should be considered as private and confidential. Any review,<BR>retransmission, dissemination, or taking of any action in reliance upon<BR>this information by anyone other than the intended recipient is<BR>prohibited. If you have received this message in error, please reply to<BR>the sender immediately and delete the original message and any copy of<BR>it from your computer system. Thank you.<BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>CONFIDENTIALITY NOTICE: The information contained in this email including attachments is intended for the specific delivery to and use by the individual(s) to whom it is addressed, and includes
information which should be considered as private and confidential. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you have received this message in error, please reply to the sender immediately and delete the original message and any copy of it from your computer system. Thank you.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f833248c/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f833248c/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 15<BR>Date: Tue, 27 Oct 2009 15:07:29 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: "Jeff Ruttman"
<<A href="mailto:ruttmanj@carewisc.org" ymailto="mailto:ruttmanj@carewisc.org">ruttmanj@carewisc.org</A>><BR>Cc: "Cisco VOIP Newsletter - puck.nether.net"<BR> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] Interpret CDR Search Results<BR>Message-ID: <<A href="mailto:DE773F61-2423-4A47-A52B-6AD95E5542E1@cisco.com" ymailto="mailto:DE773F61-2423-4A47-A52B-6AD95E5542E1@cisco.com">DE773F61-2423-4A47-A52B-6AD95E5542E1@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>It certainly would.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 3:06 PM, Jeff Ruttman wrote:<BR><BR>Thanks! I'll have a look at that doc.<BR><BR>On that second one, if the caller had caller ID blocked, would that <BR>produce the "Null"?<BR><BR>jeff<BR><BR>From: Ryan Ratliff
[mailto:<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>]<BR>Sent: Tuesday, October 27, 2009 1:42 PM<BR>To: Jeff Ruttman<BR>Cc: Cisco VOIP Newsletter - puck.nether.net<BR>Subject: Re: [cisco-voip] Interpret CDR Search Results<BR><BR>Take a look at <A href="http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html" target=_blank>http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html</A> <BR>.<BR><BR>The first one you can correlate by the fact that there is no called <BR>party number and the lack of any media information.<BR>The second one was a call to your phone that seems to have no calling <BR>party number and only partial media information.<BR><BR>You can take the GCID and search CCM traces to find more info if you <BR>really want.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:<BR><BR>Greetings,<BR><BR>In
the results of a CDR Search by Extension, I see entries like these:<BR><BR>Sl No Call Type GCID CMId<BR>GCID CallId Orig Node Id<BR>Dest Node Id Orig Leg Id<BR>Dest Leg Id Calling No<BR>Calling No Partition Called No<BR>Called No Partition Dest No<BR>Dest No Partition Last Rd No<BR>Last Rd No Partition <BR>Media Info<BR>Orig Pkts Rcd Dest Pkts Rcd<BR>Orig Pkts Lost Dest Pkts Lost<BR>CDR - CMR Dump<BR><BR>33 Simple 3<BR>2155334 3<BR>0 50453618<BR>50453619 6174<BR>Phones null<BR>null null<BR>null null<BR>null null null Others<BR>null
null View<BR><BR><BR>24 Simple 3<BR>2155266 3<BR>3 50453393<BR>50453394 null<BR>null 6174<BR>Phones 6174<BR>Phones 6174<BR>Phones 2954 null Others<BR>0 null View<BR><BR>What do these mean? The first one I can reproduce by going off hook <BR>and waiting for dial tone to time out. Is that all such an entry <BR>could mean? What about the second one?<BR><BR>Thanks<BR>jeff<BR><BR>CONFIDENTIALITY NOTICE: The information contained in this email <BR>including attachments is intended for the specific delivery to and use <BR>by the individual(s) to whom it is
addressed, and includes information <BR>which should be considered as private and confidential. Any review, <BR>retransmission, dissemination, or taking of any action in reliance <BR>upon this information by anyone other than the intended recipient is <BR>prohibited. If you have received this message in error, please reply <BR>to the sender immediately and delete the original message and any copy <BR>of it from your computer system. Thank you.<BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>CONFIDENTIALITY NOTICE: The information contained in this email <BR>including attachments is intended for the specific delivery to
and use <BR>by the individual(s) to whom it is addressed, and includes information <BR>which should be considered as private and confidential. Any review, <BR>retransmission, dissemination, or taking of any action in reliance <BR>upon this information by anyone other than the intended recipient is <BR>prohibited. If you have received this message in error, please reply <BR>to the sender immediately and delete the original message and any copy <BR>of it from your computer system. Thank you.<BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/e66ad05d/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/e66ad05d/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 16<BR>Date: Tue, 27 Oct 2009 15:16:46 -0400<BR>From:
Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271216i36f500d5n29ed90a45978cbee@mail.gmail.com" ymailto="mailto:a54820e50910271216i36f500d5n29ed90a45978cbee@mail.gmail.com">a54820e50910271216i36f500d5n29ed90a45978cbee@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Yes the session progress is receviced by the router<BR><BR>In all my debugs I noticed I have the same thing<BR><BR>*Oct 27 20:25:37.558:
//1528/003E40690D00/SIP/Info/sipSPICheckDynPayloadUse:<BR>Dynamic payload(101) could not be reserved.<BR>*Oct 27 20:25:37.558:<BR>//1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>relay option<BR>*Oct 27 20:25:37.562:<BR>//1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>named event(NE) match in fmtp list of events.<BR>*Oct 27 20:25:37.562:<BR>//-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload<BR>from X-cap = 0<BR>*Oct 27 20:25:37.562:<BR>//1528/003E40690D00/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>present in SDP. Disable modem relay<BR><BR>Is Dynamic payload(101) could not be reserved telling me I have no dtmf<BR>support?<BR><BR>On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR><BR>> I doubt that is related to your lack of DTMF but it's most likely the
side<BR>> sending the 183 is actually counting 1-16 and printing the 0. The Session<BR>> Progress is received by the router isn't it?<BR>><BR>> There are only 16 DTMF characters, the 12 on your keypad and 4 hidden ones<BR>> A, B, C, and D.<BR>><BR>> -Ryan<BR>><BR>> On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:<BR>><BR>> The difference I see between the invite and the 183 session progression<BR>> from the telco is<BR>><BR>> invite<BR>> a=fmtp:101 0-15<BR>><BR>> session progression<BR>> a=fmtp:101 0-16<BR>><BR>> Could this miss match in supported digits be what is causing all dtmf not<BR>> to work? How can I make my cisco router support 0-16?<BR>><BR>> Dane<BR>><BR>> *Invite*<BR>> **<BR>> **<BR>> v=0<BR>> o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57<BR>> s=SIP Call<BR>> c=IN IP4 173.14.220.57<BR>> t=0 0<BR>> m=audio 18770
RTP/AVP 0 101 19<BR>> c=IN IP4 173.14.220.57<BR>> a=rtpmap:0 PCMU/8000<BR>> a=rtpmap:101 telephone-event/8000<BR>> a=fmtp:101 0-15<BR>> a=rtpmap:19 CN/8000<BR>> a=ptime:20<BR>><BR>><BR>><BR>> *session progression*<BR>><BR>><BR>> v=0<BR>> o=root 5115 5115 IN IP4 64.34.181.47<BR>> s=session<BR>> c=IN IP4 64.34.181.47<BR>> t=0 0<BR>> m=audio 17646 RTP/AVP 0 101<BR>> a=rtpmap:0 PCMU/8000<BR>> a=rtpmap:101 telephone-event/8000<BR>> a=fmtp:101 0-16<BR>> a=silenceSupp:off - - - -<BR>><BR>> On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR>><BR>>> Sorry this part is the actual DTMF:<BR>>><BR>>> a=rtpmap:101 telephone-event/8000<BR>>><BR>>> The line you quoted is part of the SDP and references both RTP and DTMF.<BR>>> m=audio 11680 RTP/AVP
0 101<BR>>> a=rtpmap:0 PCMU/8000<BR>>> a=rtpmap:101 telephone-event/8000<BR>>> a=fmtp:101 0-16<BR>>> a=silenceSupp:off - - - -<BR>>><BR>>> The fist line means your RTP is on port 11680 and references the a:rtpmap<BR>>> entries for 0 and 101.<BR>>> The second line means your RTP is g.711.<BR>>> The 3rd line is the DTMF with a payload type of 101.<BR>>> The 4th line means it can accept DTMF 0-16<BR>>> The last line is pretty self explanatory (silence suppression disabled).<BR>>><BR>>> This is a very basic interpretation of the SDP info. RFC 2327 is where<BR>>> you want to go to get into the nitty-gritty details.<BR>>><BR>>> -Ryan<BR>>><BR>>> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR>>><BR>>> That is RFC2833 DTMF with a payload type of 101.<BR>>><BR>>> I do know that CUBE cannot do dynamic RFC2833
payload types. It can only<BR>>> send the payloadType defined in the voip dial-peer. So if inbound calls use<BR>>> a different payloadType than outbound calls you will want to update the<BR>>> dial-peers accordingly.<BR>>><BR>>><BR>>> -Ryan<BR>>><BR>>> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR>>><BR>>> Well I tried to switch providers just to test it out and now I am getting<BR>>> something back in the 183 but still no dtmf hmm<BR>>><BR>>> I see they are sending me<BR>>><BR>>> m=audio 11680 RTP/AVP 0 101<BR>>><BR>>> How do I interperate that line?<BR>>><BR>>><BR>>> Received:<BR>>> SIP/2.0 183 Session Progress<BR>>> Via: SIP/2.0/UDP 173.14.220.57:5060<BR>>> ;branch=z9hG4bK749136B;received=173.14.220.57<BR>>> From: <sip:<A href="mailto:6782282221@did.voip.les.net"
ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A><sip%<A href="mailto:3A6782282221@did.voip.les.net" ymailto="mailto:3A6782282221@did.voip.les.net">3A6782282221@did.voip.les.net</A>><BR>>> >;tag=419FE94-8A1<BR>>> To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A><sip%<A href="mailto:3A18774675464@did.voip.les.net" ymailto="mailto:3A18774675464@did.voip.les.net">3A18774675464@did.voip.les.net</A>><BR>>> >;tag=as5677a12c<BR>>> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>>> CSeq: 101 INVITE<BR>>> User-Agent: LES.NET.VoIP<BR>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>>> Contact: <sip:18774675464@64.34.181.47 <sip%3A18774675464@64.34.181.47>><BR>>> Content-Type: application/sdp<BR>>> Content-Length:
214<BR>>> v=0<BR>>> o=root 5115 5115 IN IP4 64.34.181.47<BR>>> s=session<BR>>> c=IN IP4 64.34.181.47<BR>>> t=0 0<BR>>> m=audio 11680 RTP/AVP 0 101<BR>>> a=rtpmap:0 PCMU/8000<BR>>> a=rtpmap:101 telephone-event/8000<BR>>> a=fmtp:101 0-16<BR>>> a=silenceSupp:off - - - -<BR>>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:<BR>>> INVITE response with no RSEQ - disable IS_REL1XX<BR>>> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No<BR>>> GTD found in inbound container<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>>> SIP: Attribute mid, level 1 instance 1 not found.<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already<BR>>> bound, use existing
source_media_ip_addr<BR>>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> Media src addr for stream 1 = 173.14.220.57<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)<BR>>> Negotiation Successful on Static Payload for m-line 1<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or<BR>>> multiple ptime attributes that can't be handled<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)<BR>>> could not be reserved.<BR>>> *Oct 27 18:02:12.551:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>>> relay option<BR>>> *Oct
27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>>> named event(NE) match in fmtp list of events.<BR>>> *Oct 27 18:02:12.555:<BR>>> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload<BR>>> from X-cap = 0<BR>>> *Oct 27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>> present in SDP. Disable modem relay<BR>>> *Oct 27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction<BR>>> attribute present or multiple direction attributes that can't be handled for<BR>>> m-line:1 and num-a-lines:0<BR>>> *Oct 27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation<BR>>> successful for media line 1<BR>>> payload_type=0, codec_bytes=160,
codec=g711ulaw,<BR>>> dtmf_relay=rtp-nte<BR>>> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,<BR>>> dest_port=11680<BR>>> *Oct 27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =<BR>>> -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)<BR>>> *Oct 27 18:02:12.555:<BR>>> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> Preferred Codec : g711ulaw, bytes :160<BR>>> Preferred DTMF relay : rtp-nte<BR>>> Preferred NTE payload : 101<BR>>> Early Media : No<BR>>> Delayed Media : No<BR>>> Bridge
Done : No<BR>>> New Media : No<BR>>> DSP DNLD Reqd : No<BR>>><BR>>> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>>wrote:<BR>>><BR>>>> The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>>>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>>>> a 200 OK with the CSeq for 101 INVITE.<BR>>>><BR>>>> I've seen this for certain IVRs/providers - sometimes they don't<BR>>>> properly terminate a call with a 200 OK. If you were not sending an<BR>>>> SDP in your original INVITE, then you would need the PRACK setting<BR>>>>
mentioned. You have two problems, either could fix the problem: They<BR>>>> could advertise DTMF in their 183, or they could send you a 200 OK for<BR>>>> the call. It is assumed you would get DTMF in the 200 OK. It's<BR>>>> common for endpoints that support DTMF to not advertise it in the 183<BR>>>> because you technically shouldn't need DTMF to hear ringback.<BR>>>><BR>>>> -nick<BR>>>><BR>>>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>>>> wrote:<BR>>>> > There is no SDP in that 200 OK so I would assume the media info is the<BR>>>> same<BR>>>> > as in the 183 Ringing message. You really need your ITSP to tell you<BR>>>> what<BR>>>> > dtmf method they want you to use on your
outbound calls. As Nick said<BR>>>> they<BR>>>> > don't appear to be advertising any dtmf method at all.<BR>>>> > -Ryan<BR>>>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>>>> > Is the below the ok I should be getting?<BR>>>> ><BR>>>> ><BR>>>> > They did send this with the first debug<BR>>>> ><BR>>>> > Received:<BR>>>> > SIP/2.0 200 OK<BR>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=32DA608-109A<BR>>>> > To: <sip:18774675464@64.154.41.200
<sip%3A18774675464@64.154.41.200>><BR>>>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>>>> > CSeq: 102 CANCEL<BR>>>> > Content-Length: 0<BR>>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:<BR>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>>>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>>>> > *Oct 27 13:44:12.836:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> > *Oct 27 13:44:12.840:<BR>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>> > *Oct 27
13:44:12.840:<BR>>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> > context=0x00000000<BR>>>> > *Oct 27 13:44:12.840:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> > Checking Invite Dialog<BR>>>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> ><BR>>>> > This with the 2nd debug<BR>>>> ><BR>>>> > Received:<BR>>>> > SIP/2.0 200 OK<BR>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>>
> To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> > CSeq: 102 CANCEL<BR>>>> > Content-Length: 0<BR>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>>> > *Oct 27 12:34:15.912:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> > *Oct 27 12:34:15.912:<BR>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> > ccsip_spi_get_msg_type returned: 2 for event
1<BR>>>> > *Oct 27 12:34:15.912:<BR>>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> > context=0x00000000<BR>>>> > *Oct 27 12:34:15.912:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> > Checking Invite Dialog<BR>>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> > Received:<BR>>>> > SIP/2.0 487 Request Terminated<BR>>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>>> >;tag=3465630735-938664<BR>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>
>;tag=2EDA9C8-25D6<BR>>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> > CSeq: 102 INVITE<BR>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> > Content-Length: 0<BR>>>> ><BR>>>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>>> wrote:<BR>>>> >><BR>>>> >> In the 183 Session Progress they're not advertising DTMF:<BR>>>> >><BR>>>> >> m=audio 45846 RTP/AVP 0<BR>>>> >><BR>>>> >> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>>> >> You would want to pick up on the other side and they should send a 200<BR>>>>
>> OK with a new SDP. If the other side did pick up, you need to tell<BR>>>> >> the provider that they need to send a 200 OK, because they're not.<BR>>>> >><BR>>>> >><BR>>>> >> -nick<BR>>>> >><BR>>>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>>> >> wrote:<BR>>>> >> > Nick<BR>>>> >> ><BR>>>> >> > I removed voice-class sip asymmetric payload dtmf and added in the<BR>>>> >> > other<BR>>>> >> > line<BR>>>> >> ><BR>>>> >> > Just to state incoming dtmf works but not outbound the ITSP has told<BR>>>> me<BR>>>> >> > they<BR>>>> >> > are using two
different sip servers/vendors for processing inbound<BR>>>> and<BR>>>> >> > outbound<BR>>>> >> > How does this translate into what I should sent the following too?<BR>>>> >> ><BR>>>> >> > rtp payload-type nse<BR>>>> >> > rtp payload-type nte<BR>>>> >> ><BR>>>> >> > In the debug trhe following where set<BR>>>> >> ><BR>>>> >> > rtp payload-type nse 101<BR>>>> >> > rtp payload-type nte 100<BR>>>> >> ><BR>>>> >> > In the debug of ccsip If I am looking at it correctly I see me<BR>>>> sending<BR>>>> >> > this<BR>>>> >> ><BR>>>> >> > *Oct 27 12:34:09.128:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>>> >> >
Preferred method of dtmf relay is: 6, with payload: 100<BR>>>> >> > *Oct 27 12:34:09.128:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>>> >> > max_event 15<BR>>>> >> ><BR>>>> >> > and<BR>>>> >> ><BR>>>> >> ><BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>>> >> > payload<BR>>>> >> > from X-cap = 0<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>>> >> > present<BR>>>> >> > in SDP. Disable modem relay<BR>>>> >> ><BR>>>> >> ><BR>>>> >> > Sent:<BR>>>>
>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>>> >> > Remote-Party-ID:<BR>>>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>>>> >;party=calling;screen=yes;privacy=off<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> ><BR>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>> >> > Call-ID:
DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>>> >> > Min-SE: 1800<BR>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>>> >> > SUBSCRIBE,<BR>>>> >> > NOTIFY, INFO, REGISTER<BR>>>> >> > CSeq: 101 INVITE<BR>>>> >> > Max-Forwards: 70<BR>>>> >> > Timestamp: 1256646849<BR>>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>>> >> > Expires: 180<BR>>>> >> > Allow-Events: telephone-event<BR>>>> >> > Content-Type: application/sdp<BR>>>> >> >
Content-Disposition: session;handling=required<BR>>>> >> > Content-Length: 250<BR>>>> >> > v=0<BR>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>>> >> > s=SIP Call<BR>>>> >> > c=IN IP4 173.14.220.57<BR>>>> >> > t=0 0<BR>>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>>> >> > c=IN IP4 173.14.220.57<BR>>>> >> > a=rtpmap:0 PCMU/8000<BR>>>> >> > a=rtpmap:100 telephone-event/8000<BR>>>> >> > a=fmtp:100 0-15<BR>>>> >> > a=ptime:20<BR>>>> >> ><BR>>>> >> ><BR>>>> >> > Then when I do a search for fmtp again further down I see<BR>>>> >> ><BR>>>> >> > Sent:<BR>>>> >> > INVITE sip:18774675464@64.154.41.200:5060
SIP/2.0<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> >> > Remote-Party-ID:<BR>>>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>>>> >;party=calling;screen=yes;privacy=off<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> ><BR>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> >
Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>>> >> > Min-SE: 1800<BR>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>>> >> > SUBSCRIBE,<BR>>>> >> > NOTIFY, INFO, REGISTER<BR>>>> >> > CSeq: 102 INVITE<BR>>>> >> > Max-Forwards: 70<BR>>>> >> > Timestamp: 1256646849<BR>>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>>> >> > Expires: 180<BR>>>> >> > Allow-Events: telephone-event<BR>>>> >> > Proxy-Authorization: Digest<BR>>>> >> ><BR>>>> >> > username="1648245954",realm="64.154.41.110",uri="<BR>>>>
sip:18774675464@64.154.41.200:5060<BR>>>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>>> >> > Content-Type: application/sdp<BR>>>> >> > Content-Disposition: session;handling=required<BR>>>> >> > Content-Length: 250<BR>>>> >> > v=0<BR>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>>> >> > s=SIP Call<BR>>>> >> > c=IN IP4 173.14.220.57<BR>>>> >> > t=0 0<BR>>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>>> >> > c=IN IP4 173.14.220.57<BR>>>> >> > a=rtpmap:0 PCMU/8000<BR>>>> >> > a=rtpmap:100 telephone-event/8000<BR>>>> >> > a=fmtp:100 0-15<BR>>>> >> > a=ptime:20<BR>>>> >> > *Oct 27
12:34:09.332:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> >> > *Oct 27 12:34:09.332:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>> >> > *Oct 27 12:34:09.332:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> >> > context=0x00000000<BR>>>> >> > *Oct 27 12:34:09.332:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> >> > Checking Invite Dialog<BR>>>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> >> > Received:<BR>>>> >> > SIP/2.0 100
Trying<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> ><BR>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> > CSeq: 102 INVITE<BR>>>> >> > Content-Length: 0<BR>>>> >> > *Oct 27 12:34:09.332:<BR>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>>>
>> > *Oct 27 12:34:09.332:<BR>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE)<BR>>>> to<BR>>>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>>> >> > *Oct 27 12:34:10.832:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> >> > *Oct 27 12:34:10.832:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>> >> > *Oct 27 12:34:10.832:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> >> > context=0x00000000<BR>>>> >> >
*Oct 27 12:34:10.836:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> >> > Checking Invite Dialog<BR>>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> >> > Received:<BR>>>> >> > SIP/2.0 183 Session Progress<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> >;tag=3465630735-938664<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>>> >> > Call-ID:
DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> > CSeq: 102 INVITE<BR>>>> >> > Content-Type: application/sdp<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> >> > Content-Length: 146<BR>>>> >> > v=0<BR>>>> >> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>>> >> > s=sip call<BR>>>> >> > c=IN IP4 64.154.41.101<BR>>>> >> > t=0 0<BR>>>> >> > m=audio 45846 RTP/AVP 0<BR>>>> >> > a=ptime:20<BR>>>> >> > a=rtpmap:0 PCMU/8000<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>>
//-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No<BR>>>> >> > GTD<BR>>>> >> > found in inbound container<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>>> >> > Number of m-lines = 1<BR>>>> >> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>> >> > already<BR>>>> >> > bound, use existing source_media_ip_addr<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> >
//846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line<BR>>>> 1<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>>> >> > One ptime attribute found - value:20<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values<BR>>>> :Codec:<BR>>>> >> > g711ulaw ptime :20, codecbytes: 160<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>>> :Codec:<BR>>>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> >
//846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160<BR>>>> for<BR>>>> >> > codec<BR>>>> >> > g711ulaw<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line<BR>>>> index 1<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>>> >> > Dynamic payload(100) could not be reserved.<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of<BR>>>> full<BR>>>> >> > named<BR>>>> >> > event(NE) match in fmtp list of events.<BR>>>> >> > *Oct 27
12:34:10.836:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>>> >> > payload<BR>>>> >> > from X-cap = 0<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>>> >> > present<BR>>>> >> > in SDP. Disable modem relay<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No<BR>>>> direction<BR>>>> >> > attribute present or multiple direction attributes that can't be<BR>>>> handled<BR>>>> >> > for<BR>>>> >> > m-line:1 and num-a-lines:0<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> >
//846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>>> >> > Codec negotiation successful for media line 1<BR>>>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>>> >> > dtmf_relay=rtp-nte<BR>>>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>>> >> > dest_port=45846<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>>> >> > (STREAM_ADDING)<BR>>>> >> > *Oct 27 12:34:10.836:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>>> >> > Preferred Codec :
g711ulaw, bytes :160<BR>>>> >> > Preferred DTMF relay : rtp-nte<BR>>>> >> > Preferred NTE payload : 100<BR>>>> >> > Early Media : No<BR>>>> >> > Delayed Media : No<BR>>>> >> > Bridge Done : No<BR>>>> >> > New Media : No<BR>>>> >> > DSP DNLD Reqd : No<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>> >> >
already<BR>>>> >> > bound, use existing source_media_ip_addr<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>>> >> > callId 846 size 240 ptr 0x4A170B28)<BR>>>> >> > *Oct 27
12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> >> > Hndl ptype 0 mline 1<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> >> > Selecting<BR>>>> >> > codec g711ulaw<BR>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>>> >> > Codec to be matched: 5<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD<BR>>>> >> > AUDIO<BR>>>> >> > CODEC 5<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>>> :Codec:<BR>>>> >> >
g711ulaw codecbytes :160, ptime: 20<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> Media<BR>>>> >> > negotiation done:<BR>>>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,<BR>>>> coverted<BR>>>> >> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1<BR>>>> >> > 64.154.41.101:45846<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> Copy<BR>>>> >> > sdp
to<BR>>>> >> > channel- AFTER CODEC FILTERING:<BR>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>> Copy<BR>>>> >> > sdp to<BR>>>> >> > channel- AFTER CODEC FILTERING:<BR>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>> >> > Report initial call media<BR>>>> >> >
*Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>> ccb->flags<BR>>>> >> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>>> >> > callId 846 size 240 ptr 0x4DEC000C)<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>>> >> > 5030: Posting Remote SRTP caps to other callleg.<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>>> >> > cc_api_caps_ind()<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>>> >> >
Stream type : voice+dtmf<BR>>>> >> > Media line : 1<BR>>>> >> > State : STREAM_ADDING (2)<BR>>>> >> > Stream address type : 1<BR>>>> >> > Callid : 846<BR>>>> >> > Negotiated Codec : g711ulaw, bytes :160<BR>>>> >> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>>> >> > Negotiated DTMF relay : rtp-nte<BR>>>> >>
> Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>>> >> > Negotiated CN payload : 0<BR>>>> >> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>>> >> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>>> >> > headers<BR>>>> >> > recvd from app container<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:<BR>>>> >> > No<BR>>>> >> > QSIG Body found in inbound container<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>>
//-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:<BR>>>> >> > No<BR>>>> >> > RawMsg Body found in inbound container<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:<BR>>>> >> > No<BR>>>> >> > Data to form The Raw Message<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>>> >> > *Oct 27 12:34:10.840:<BR>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>>> >> > SUBSTATE_NONE)<BR>>>> >> > *Oct 27
12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction<BR>>>> >> > Complete. Lock on Facilities released.<BR>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>> confID =<BR>>>> >> > 6,<BR>>>> >> > srcCallID = 846, dstCallID = 845<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>>> >> > Old streamcallid=846, new streamcallid=846<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> >
//846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>>> >> > Setting SPI mode to SIP-H323<BR>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =<BR>>>> 1131891908<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>>> >> > sipSPIProcessRtpSessions<BR>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:<BR>>>> >> > Adding<BR>>>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>> >> > already<BR>>>> >> >
bound, use existing source_media_ip_addr<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>> >> > *Oct 27 12:34:10.844:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>> >> > sipSPIUpdateRtcpSession for m-line 1<BR>>>> >> > *Oct 27 12:34:10.848:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>> >> > rtcp_session info<BR>>>> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,<BR>>>> >> > rport=45846, do_rtcp=TRUE<BR>>>> >> > src_callid = 846, dest_callid = 845, stream type =<BR>>>> voice+dtmf,<BR>>>>
>> > stream direction = SENDRECV<BR>>>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0<BR>>>> media_addr_type =<BR>>>> >> > 1<BR>>>> >> > *Oct 27 12:34:10.848:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>> >> > RTP session already created - update<BR>>>> >> > *Oct 27 12:34:10.848:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>>> >> > stun is disabled for stream:4A1709F8<BR>>>> >> > *Oct 27 12:34:10.848:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>>> >> > New Remote Media Direction = SENDRECV<BR>>>> >> > Present Local Media Direction =
SENDRECV<BR>>>> >> > New Local Media Direction = SENDRECV<BR>>>> >> > retVal = 0<BR>>>> >> > *Oct 27 12:34:10.848:<BR>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>>> >> > (STREAM_ACTIVE)<BR>>>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>> really<BR>>>> >> > can't<BR>>>> >> > find peer_stream for<BR>>>> >> > dtmf-relay<BR>>>> interworking<BR>>>> >> > *Oct 27 12:34:11.140:
//846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Entry<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>>> CURRENT<BR>>>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>>> >> > VALUES:<BR>>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Load<BR>>>> >> > DSP<BR>>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Set<BR>>>> >> > forking flag to
0x0<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx<BR>>>> payload =<BR>>>> >> > 100, tx payload = 100<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>>> >> > config=0<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Disabling Modem Relay...<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>>>>
>> > Xcap<BR>>>> >> > list<BR>>>> >> > *Oct 27 12:34:11.140:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Modem<BR>>>> >> > Relay & Passthru both disabled<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > nse<BR>>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>>> relay=0,<BR>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > 1<BR>>>> >> > Active Streams<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>
>> > Adding stream type (voice+dtmf) from media<BR>>>> >> > line 1 codec g711ulaw<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>>> >> > caps.stream_list.xmitFunc=<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>>>> >> > *Oct 27 12:34:11.144:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > 0x497E0B60 (gccb)<BR>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Load<BR>>>> >> > DSP<BR>>>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>>>
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405<BR>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>>>> >> > video<BR>>>> >> > caps detected in the caps posted by peer leg<BR>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> >> > Setting<BR>>>> >> > CAPS_RECEIVED flag<BR>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> >> > Calling<BR>>>> >> > cc_api_caps_ack()<BR>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack:<BR>>>> Set<BR>>>> >> > forking flag to 0x0<BR>>>> >> > *Oct 27 12:34:11.168:
//846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Entry<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>>> CURRENT<BR>>>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>>> >> > VALUES:<BR>>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Load<BR>>>> >> > DSP<BR>>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Set<BR>>>> >> > forking flag to
0x0<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx<BR>>>> payload =<BR>>>> >> > 100, tx payload = 100<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>>> >> > config=0<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Disabling Modem Relay...<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP<BR>>>>
>> > Xcap<BR>>>> >> > list<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > Modem<BR>>>> >> > Relay & Passthru both disabled<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>> >> > nse<BR>>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>>> relay=0,<BR>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > 1<BR>>>> >> > Active Streams<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>
>> > Adding stream type (voice+dtmf) from media<BR>>>> >> > line 1 codec g711ulaw<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>>> >> > caps.stream_list.xmitFunc=<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>>>> >> > *Oct 27 12:34:11.168:<BR>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>> >> > 0x497E0B60 (gccb)<BR>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Load<BR>>>> >> > DSP<BR>>>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>>>
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No<BR>>>> >> > video<BR>>>> >> > caps detected in the caps posted by peer leg<BR>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>> Second<BR>>>> >> > TCS<BR>>>> >> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>>> >> > *Oct 27 12:34:15.876:<BR>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>>> >> > stun is disabled for stream:4A1709F8<BR>>>> >> > *Oct 27 12:34:15.876:<BR>>>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:<BR>>>> >> > Stats
are not supported for IPIP call.<BR>>>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>>> >> > Queued<BR>>>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> >> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:<BR>>>> >> > Associated container=0x4E310C1C to Cancel<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:<BR>>>> >> > Sending CANCEL to the transport layer<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> >
//846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>>> >> > msg=0x4DF0D994,<BR>>>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,<BR>>>> >> > switch=0, callBack=0x419703BC<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>>> Proceedable<BR>>>> >> > for<BR>>>> >> > sending msg immediately<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>>> >> > transport<BR>>>> >> > is 0<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to<BR>>>> send<BR>>>> >> > the<BR>>>>
>> > msg=0x4DF0D994<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting<BR>>>> >> > send<BR>>>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>>> >> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>>> >> > *Oct 27 12:34:15.880:<BR>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>>> SUBSTATE_NONE)<BR>>>> >> > to<BR>>>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>>> >> > *Oct 27 12:34:15.888:
//-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> >> > Sent:<BR>>>> >> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> ><BR>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> > CSeq: 102 CANCEL<BR>>>> >> > Max-Forwards:
70<BR>>>> >> > Timestamp: 1256646855<BR>>>> >> > Reason: Q.850;cause=16<BR>>>> >> > Content-Length: 0<BR>>>> >> > *Oct 27 12:34:15.900:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> >> > *Oct 27 12:34:15.900:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>> >> > *Oct 27 12:34:15.900:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> >> > context=0x00000000<BR>>>> >> > *Oct 27 12:34:15.900:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> >> >
Checking Invite Dialog<BR>>>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> >> > Received:<BR>>>> >> > SIP/2.0 200 OK<BR>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>> >;tag=2EDA9C8-25D6<BR>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>> ><BR>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>> >> > CSeq: 102 CANCEL<BR>>>> >> > Content-Length: 0<BR>>>>
>> > *Oct 27 12:34:15.900:<BR>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>>> >> > *Oct 27 12:34:15.912:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>> >> > *Oct 27 12:34:15.912:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>> >> > *Oct 27 12:34:15.912:<BR>>>> >> >
//-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>> >> > context=0x00000000<BR>>>> >> > *Oct 27 12:34:15.912:<BR>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>> >> > Checking Invite Dialog<BR>>>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>> >> ><BR>>>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A><BR>>>> ><BR>>>> >> > wrote:<BR>>>> >> >><BR>>>> >> >> You would want to check the SDP of 200 OK the provider sends for<BR>>>> your<BR>>>> >> >> outgoing call. It will list the payload type for the dtmf in the<BR>>>> >> >> format
a=fmtp 101 1-16, or something similar. You want to find out<BR>>>> >> >> what payload type they are advertising (or if they are at all). It<BR>>>> >> >> would be worth checking the incoming INVITE from them to see what<BR>>>> >> >> they're using when they send the first SDP.<BR>>>> >> >><BR>>>> >> >> On that note, I would also remove the asymmetric payload command -<BR>>>> to<BR>>>> >> >> my knowledge it doesn't do what you're expecting it to. You may<BR>>>> want<BR>>>> >> >> to try this command:<BR>>>> >> >> voice-class sip dtmf-relay force rtp-nte<BR>>>> >> >><BR>>>> >> >><BR>>>> >> >> -nick<BR>>>> >> >><BR>>>> >> >> On Mon, Oct 26, 2009 at 5:16
PM, Dane Newman <<BR>>>> <A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>>> >> >> wrote:<BR>>>> >> >> > Hello,<BR>>>> >> >> ><BR>>>> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf<BR>>>> works<BR>>>> >> >> > fine.<BR>>>> >> >> > It took some playing around with it. At first it didnt work till<BR>>>> the<BR>>>> >> >> > payload was ajusted. I am now trying to get outbound dtmf<BR>>>> working<BR>>>> >> >> > properly.<BR>>>> >> >> ><BR>>>> >> >> > On my 2821 I debugged voip rtp session named-events and then made<BR>>>> a<BR>>>> >> >> >
call<BR>>>> >> >> > to<BR>>>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on<BR>>>> the<BR>>>> >> >> > router<BR>>>> >> >> > nothing showed up in the debug. Does this mean I can safely<BR>>>> asume<BR>>>> >> >> > that<BR>>>> >> >> > the<BR>>>> >> >> > problem for right now is not on the ITSP side but on my side<BR>>>> since<BR>>>> >> >> > dtmf<BR>>>> >> >> > is<BR>>>> >> >> > not being sent down the sip trunk?<BR>>>> >> >> ><BR>>>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>>> >> >> > configuration<BR>>>> >> >> > of the cisco
2821 is shown below. Does anyone have any ideas<BR>>>> what I<BR>>>> >> >> > can<BR>>>> >> >> > do<BR>>>> >> >> > so dtmf digits process properly outbound?<BR>>>> >> >> ><BR>>>> >> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>>> >> >> ><BR>>>> >> >> > h323 cucm gateway configuratration<BR>>>> >> >> > Signaling Port 1720<BR>>>> >> >> > media termination point required yes<BR>>>> >> >> > retry video call as auto yes<BR>>>> >> >> > wait for far end h.245 terminal capability set yes<BR>>>> >> >> > transmit utf-8 calling party name no<BR>>>> >> >> > h.235 pass through allowed no<BR>>>> >> >> >
significant digits all<BR>>>> >> >> > redirect number IT deliver - inbound no<BR>>>> >> >> > enable inbound faststart yes<BR>>>> >> >> > display IE deliver no<BR>>>> >> >> > redirect nunmber IT deliver - outbound no<BR>>>> >> >> > enable outbound faststart yes<BR>>>> >> >> ><BR>>>> >> >> ><BR>>>> >> >> > voice service voip<BR>>>> >> >> > allow-connections h323 to h323<BR>>>> >> >> > allow-connections h323 to sip<BR>>>> >> >> > allow-connections sip to h323<BR>>>> >> >> > allow-connections sip to sip<BR>>>> >> >> > fax protocol pass-through g711ulaw<BR>>>> >> >> > h323<BR>>>>
>> >> > emptycapability<BR>>>> >> >> > h225 id-passthru<BR>>>> >> >> > h245 passthru tcsnonstd-passthru<BR>>>> >> >> > sip<BR>>>> >> >> ><BR>>>> >> >> ><BR>>>> >> >> > voice class h323 50<BR>>>> >> >> > h225 timeout tcp establish 3<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > voice translation-rule
1<BR>>>> >> >> > rule 1 /.*/ /190/<BR>>>> >> >> > !<BR>>>> >> >> > voice translation-rule 2<BR>>>> >> >> > rule 1 /.*/ /1&/<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > voice translation-profile aa<BR>>>> >> >> > translate called 1<BR>>>> >> >> > !<BR>>>> >> >> > voice translation-profile addone<BR>>>> >> >> > translate called 2<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > voice-card 0<BR>>>> >> >> > dspfarm<BR>>>> >> >> > dsp services dspfarm<BR>>>> >> >> > !<BR>>>> >> >> >
!<BR>>>> >> >> > sccp local GigabitEthernet0/1<BR>>>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>>> >> >> > sccp<BR>>>> >> >> > !<BR>>>> >> >> > sccp ccm group 1<BR>>>> >> >> > associate ccm 1 priority 1<BR>>>> >> >> > associate ccm 2 priority 2<BR>>>> >> >> > associate profile 1 register 2821transcode<BR>>>> >> >> > !<BR>>>> >> >> > dspfarm profile 1 transcode<BR>>>> >> >> > codec g711ulaw<BR>>>> >> >> > codec g711alaw<BR>>>> >> >> > codec g729ar8<BR>>>> >> >> > codec
g729abr8<BR>>>> >> >> > codec g729r8<BR>>>> >> >> > maximum sessions 4<BR>>>> >> >> > associate application SCCP<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > dial-peer voice 100 voip<BR>>>> >> >> > description AA Publisher<BR>>>> >> >> > preference 1<BR>>>> >> >> > destination-pattern 1..<BR>>>> >> >> > voice-class h323 50<BR>>>> >> >> > session target ipv4:10.1.80.10<BR>>>> >> >> > dtmf-relay h245-alphanumeric<BR>>>> >> >> > codec g711ulaw<BR>>>> >> >> > no vad<BR>>>> >> >> > !<BR>>>> >> >> > dial-peer
voice 1000 voip<BR>>>> >> >> > description incoming Call<BR>>>> >> >> > translation-profile incoming aa<BR>>>> >> >> > preference 1<BR>>>> >> >> > rtp payload-type nse 101<BR>>>> >> >> > rtp payload-type nte 100<BR>>>> >> >> > incoming called-number 6782282221<BR>>>> >> >> > dtmf-relay rtp-nte<BR>>>> >> >> > codec g711ulaw<BR>>>> >> >> > ip qos dscp cs5 media<BR>>>> >> >> > ip qos dscp cs5 signaling<BR>>>> >> >> > no vad<BR>>>> >> >> > !<BR>>>> >> >> > dial-peer voice 101 voip<BR>>>> >> >> > description AA Subscriber<BR>>>> >> >>
> preference 2<BR>>>> >> >> > destination-pattern 1..<BR>>>> >> >> > voice-class h323 50<BR>>>> >> >> > session target ipv4:10.1.80.11<BR>>>> >> >> > dtmf-relay h245-alphanumeric<BR>>>> >> >> > codec g711ulaw<BR>>>> >> >> > no vad<BR>>>> >> >> > !<BR>>>> >> >> > dial-peer voice 2000 voip<BR>>>> >> >> > description outbound<BR>>>> >> >> > translation-profile outgoing addone<BR>>>> >> >> > preference 1<BR>>>> >> >> > destination-pattern .T<BR>>>> >> >> > rtp payload-type nse 101<BR>>>> >> >> > rtp payload-type nte 100<BR>>>> >>
>> > voice-class sip asymmetric payload dtmf<BR>>>> >> >> > session protocol sipv2<BR>>>> >> >> > session target ipv4:64.154.41.200<BR>>>> >> >> > dtmf-relay rtp-nte<BR>>>> >> >> > codec g711ulaw<BR>>>> >> >> > no vad<BR>>>> >> >> > !<BR>>>> >> >> > !<BR>>>> >> >> > sip-ua<BR>>>> >> >> > credentials username ***** password 7 ***** realm<BR>>>> sip.talkinip.net<BR>>>> >> >> > authentication username ***** password 7 *****<BR>>>> >> >> > authentication username ***** password 7 ***** realm<BR>>>> >> >> > sip.talkinip.net<BR>>>> >> >>
> set pstn-cause 3 sip-status 486<BR>>>> >> >> > set pstn-cause 34 sip-status 486<BR>>>> >> >> > set pstn-cause 47 sip-status 486<BR>>>> >> >> > registrar dns:sip.talkinip.net expires 60<BR>>>> >> >> > sip-server dns:sip.talkinip.net:5060<BR>>>> >> >> > _______________________________________________<BR>>>> >> >> > cisco-voip mailing list<BR>>>> >> >> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>> >> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>>> >> >> ><BR>>>> >> >> ><BR>>>> >>
><BR>>>> >> ><BR>>>> ><BR>>>> > _______________________________________________<BR>>>> > cisco-voip mailing list<BR>>>> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>>> ><BR>>>> ><BR>>>><BR>>><BR>>><BR>>> _______________________________________________<BR>>> cisco-voip mailing list<BR>>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip"
target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>><BR>>><BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1eb5b65a/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1eb5b65a/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 17<BR>Date: Tue, 27 Oct 2009 15:27:59 -0400<BR>From: "Jeff Cartier" <<A href="mailto:jcartier@acs.on.ca" ymailto="mailto:jcartier@acs.on.ca">jcartier@acs.on.ca</A>><BR>To: <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] Cisco 7961 - Wrong Time, No Local Directory, No<BR> Services<BR>Message-ID: <<A
href="mailto:BCD3E762F1767C42A5226BBACDE49BFB010DBD14@loki.acs.local" ymailto="mailto:BCD3E762F1767C42A5226BBACDE49BFB010DBD14@loki.acs.local">BCD3E762F1767C42A5226BBACDE49BFB010DBD14@loki.acs.local</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>I'm having an issue with a Cisco 7961 phone not showing the proper time,<BR>local directory and services. I think it is somehow related to the 'DNS<BR>Unknown Host' error I'm getting when I look at the status messages.<BR>Anyone seen anything similar? Odd thing is that I have DNS running.<BR><BR><BR><BR><BR><BR>jeff<BR><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/34ea31bc/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/34ea31bc/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 18<BR>Date: Tue, 27 Oct 2009 12:34:35 -0700<BR>From: Scott Voll <<A href="mailto:svoll.voip@gmail.com" ymailto="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</A>><BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] What am I missing with Background images?<BR>Message-ID:<BR> <<A href="mailto:f84a38d30910271234oe28769bp4548f3cb9b3db7b4@mail.gmail.com" ymailto="mailto:f84a38d30910271234oe28769bp4548f3cb9b3db7b4@mail.gmail.com">f84a38d30910271234oe28769bp4548f3cb9b3db7b4@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>I have uploaded both the thumb nail and full png file for the image I want<BR>to use for a background. (both to
the Desktops/320x196x4/ directory)<BR><BR>I have also added the list.xml file to both the root and the<BR>Desktops/320x196x4/ and restarted both phone and TFTP server without being<BR>able to get it to work. What am I missing?<BR><BR>Scott<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/cde88dc2/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/cde88dc2/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 19<BR>Date: Tue, 27 Oct 2009 15:37:03 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID: <<A href="mailto:7B9D12A7-CBDA-4833-9C07-20172A0C6204@cisco.com" ymailto="mailto:7B9D12A7-CBDA-4833-9C07-20172A0C6204@cisco.com">7B9D12A7-CBDA-4833-9C07-20172A0C6204@cisco.com</A>><BR>Content-Type: text/plain; charset="us-ascii"; Format="flowed";<BR> DelSp="yes"<BR><BR>It means the router can't use payload type 101 for that call. What is <BR>the config for the voip dial-peer getting used on the outbound call?<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 3:16 PM, Dane Newman wrote:<BR><BR>Yes the session progress is receviced by the router<BR><BR>In all my debugs I noticed I have the same thing<BR><BR>*Oct 27 20:25:37.558: //1528/003E40690D00/SIP/Info/ <BR>sipSPICheckDynPayloadUse: Dynamic payload(101) could not be
reserved.<BR>*Oct 27 20:25:37.558: //1528/003E40690D00/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option<BR>*Oct 27 20:25:37.562: //1528/003E40690D00/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in <BR>fmtp list of events.<BR>*Oct 27 20:25:37.562: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0<BR>*Oct 27 20:25:37.562: //1528/003E40690D00/SIP/Info/ <BR>sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem <BR>relay<BR><BR>Is Dynamic payload(101) could not be reserved telling me I have no <BR>dtmf support?<BR><BR>On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>I doubt that is related to your lack of DTMF but it's most likely the <BR>side sending the 183 is actually counting 1-16 and
printing the 0. <BR>The Session Progress is received by the router isn't it?<BR><BR>There are only 16 DTMF characters, the 12 on your keypad and 4 hidden <BR>ones A, B, C, and D.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:<BR><BR>The difference I see between the invite and the 183 session <BR>progression from the telco is<BR><BR>invite<BR>a=fmtp:101 0-15<BR><BR>session progression<BR>a=fmtp:101 0-16<BR><BR>Could this miss match in supported digits be what is causing all dtmf <BR>not to work? How can I make my cisco router support 0-16?<BR><BR>Dane<BR><BR>Invite<BR><BR><BR>v=0<BR>o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57<BR>s=SIP Call<BR>c=IN IP4 173.14.220.57<BR>t=0 0<BR>m=audio 18770 RTP/AVP 0 101 19<BR>c=IN IP4 173.14.220.57<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-15<BR>a=rtpmap:19 CN/8000<BR>a=ptime:20<BR><BR><BR><BR>session
progression<BR><BR><BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 17646 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>Sorry this part is the actual DTMF:<BR><BR>a=rtpmap:101 telephone-event/8000<BR><BR>The line you quoted is part of the SDP and references both RTP and DTMF.<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101 telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR><BR>The fist line means your RTP is on port 11680 and references the <BR>a:rtpmap entries for 0 and 101.<BR>The second line means your RTP is g.711.<BR>The 3rd line is the DTMF with a payload type of 101.<BR>The 4th line means it
can accept DTMF 0-16<BR>The last line is pretty self explanatory (silence suppression disabled).<BR><BR>This is a very basic interpretation of the SDP info. RFC 2327 is <BR>where you want to go to get into the nitty-gritty details.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR><BR>That is RFC2833 DTMF with a payload type of 101.<BR><BR>I do know that CUBE cannot do dynamic RFC2833 payload types. It can <BR>only send the payloadType defined in the voip dial-peer. So if <BR>inbound calls use a different payloadType than outbound calls you will <BR>want to update the dial-peers accordingly.<BR><BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR><BR>Well I tried to switch providers just to test it out and now I am <BR>getting something back in the 183 but still no dtmf hmm<BR><BR>I see they are sending me<BR><BR>m=audio 11680 RTP/AVP 0 101<BR><BR>How do I
interperate that line?<BR><BR><BR>Received:<BR>SIP/2.0 183 Session Progress<BR>Via: SIP/2.0/UDP <BR>173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57<BR>From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A>>;tag=419FE94-8A1<BR>To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A>>;tag=as5677a12c<BR>Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>CSeq: 101 INVITE<BR>User-Agent: LES.NET.VoIP<BR>Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY<BR>Contact: <sip:18774675464@64.34.181.47><BR>Content-Type: application/sdp<BR>Content-Length: 214<BR>v=0<BR>o=root 5115 5115 IN IP4 64.34.181.47<BR>s=session<BR>c=IN IP4 64.34.181.47<BR>t=0 0<BR>m=audio 11680 RTP/AVP 0 101<BR>a=rtpmap:0 PCMU/8000<BR>a=rtpmap:101
telephone-event/8000<BR>a=fmtp:101 0-16<BR>a=silenceSupp:off - - - -<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX<BR>*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: <BR>No GTD found in inbound container<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoMediaNegotiation: Number of m-lines = 1<BR>SIP: Attribute mid, level 1 instance 1 not found.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>resolve_media_ip_address_to_bind: Media already bound, use existing <BR>source_media_ip_addr<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/ <BR>sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on <BR>Static Payload for m-line 1<BR>*Oct 27 18:02:12.551:
//1345/0008DE602400/SIP/Info/ <BR>sipSPIDoPtimeNegotiation: No ptime present or multiple ptime <BR>attributes that can't be handled<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: m-line index 1<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.<BR>*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in <BR>fmtp list of events.<BR>*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem <BR>relay<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
<BR>sipSPIGetSDPDirectionAttribute: No direction attribute present or <BR>multiple direction attributes that can't be handled for m-line:1 and <BR>num-a-lines:0<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/ <BR>sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1<BR> payload_type=0, codec_bytes=160, codec=g711ulaw, <BR>dtmf_relay=rtp-nte<BR> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47, <BR>dest_port=11680<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/ <BR>sipSPIChangeStreamState: Stream (callid = -1) State changed from <BR>(STREAM_DEAD) to (STREAM_ADDING)<BR>*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/ <BR>sipSPIUpdCallWithSdpInfo:<BR> Preferred Codec : g711ulaw, bytes :160<BR> Preferred DTMF relay :
rtp-nte<BR> Preferred NTE payload : 101<BR> Early Media : No<BR> Delayed Media : No<BR> Bridge Done : No<BR> New Media : No<BR> DSP DNLD Reqd : No<BR><BR>On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> <BR>wrote:<BR>The 200 OK that you've pasted is confirming the CANCEL that we sent.<BR>You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>a 200 OK with the CSeq for 101 INVITE.<BR><BR>I've seen this for certain IVRs/providers - sometimes they don't<BR>properly
terminate a call with a 200 OK. If you were not sending an<BR>SDP in your original INVITE, then you would need the PRACK setting<BR>mentioned. You have two problems, either could fix the problem: They<BR>could advertise DTMF in their 183, or they could send you a 200 OK for<BR>the call. It is assumed you would get DTMF in the 200 OK. It's<BR>common for endpoints that support DTMF to not advertise it in the 183<BR>because you technically shouldn't need DTMF to hear ringback.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> <BR>wrote:<BR>> There is no SDP in that 200 OK so I would assume the media info is <BR>the same<BR>> as in the 183 Ringing message. You really need your ITSP to tell <BR>you what<BR>> dtmf method they want you to use on your outbound calls. As
Nick <BR>said they<BR>> don't appear to be advertising any dtmf method at all.<BR>> -Ryan<BR>> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>> Is the below the ok I should be getting?<BR>><BR>><BR>> They did send this with the first debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=32DA608-109A<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState:
3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 13:44:12.840:<BR>> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>><BR>> This with the 2nd debug<BR>><BR>> Received:<BR>> SIP/2.0 200 OK<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> To: <sip:18774675464@64.154.41.200><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 CANCEL<BR>> Content-Length: 0<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>> non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>HandleUdpIPv4SocketReads:<BR>> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>> *Oct 27 12:34:15.912:<BR>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>> ccsip_spi_get_msg_type returned: 2 for event 1<BR>> *Oct 27 12:34:15.912:<BR>>
//-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>> context=0x00000000<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>ccsip_new_msg_preprocessor:<BR>> Checking Invite Dialog<BR>> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>> Received:<BR>> SIP/2.0 487 Request Terminated<BR>> To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>> Contact: <sip:18774675464@64.154.41.200:5060><BR>> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>> CSeq: 102 INVITE<BR>> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>> Content-Length: 0<BR>><BR>> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <BR><<A href="mailto:matthnick@gmail.com"
ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> In the 183 Session Progress they're not advertising DTMF:<BR>>><BR>>> m=audio 45846 RTP/AVP 0<BR>>><BR>>> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>> You would want to pick up on the other side and they should send a <BR>200<BR>>> OK with a new SDP. If the other side did pick up, you need to tell<BR>>> the provider that they need to send a 200 OK, because they're not.<BR>>><BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Nick<BR>>> ><BR>>> > I removed voice-class sip asymmetric payload dtmf and added in <BR>the<BR>>> >
other<BR>>> > line<BR>>> ><BR>>> > Just to state incoming dtmf works but not outbound the ITSP has <BR>told me<BR>>> > they<BR>>> > are using two different sip servers/vendors for processing <BR>inbound and<BR>>> > outbound<BR>>> > How does this translate into what I should sent the following too?<BR>>> ><BR>>> > rtp payload-type nse<BR>>> > rtp payload-type nte<BR>>> ><BR>>> > In the debug trhe following where set<BR>>> ><BR>>> > rtp payload-type nse 101<BR>>> > rtp payload-type nte 100<BR>>> ><BR>>> > In the debug of ccsip If I am looking at it correctly I see me <BR>sending<BR>>> > this<BR>>> ><BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>> > Preferred method of dtmf relay is: 6,
with payload: 100<BR>>> > *Oct 27 12:34:09.128:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>> > max_event 15<BR>>> ><BR>>> > and<BR>>> ><BR>>> ><BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> ><BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>> > Remote-Party-ID:<BR>>> > <sip: <BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>>
> From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 101 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> >
Allow-Events: telephone-event<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100 0-15<BR>>> > a=ptime:20<BR>>> ><BR>>> ><BR>>> > Then when I do a search for fmtp again further down I see<BR>>> ><BR>>> > Sent:<BR>>> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Remote-Party-ID:<BR>>> > <sip:
<BR>6782282221@173.14.220.57>;party=calling;screen=yes;privacy=off<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>> > Min-SE: 1800<BR>>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>> > SUBSCRIBE,<BR>>> > NOTIFY, INFO, REGISTER<BR>>> > CSeq: 102 INVITE<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646849<BR>>> > Contact:
<sip:6782282221@173.14.220.57:5060><BR>>> > Expires: 180<BR>>> > Allow-Events: telephone-event<BR>>> > Proxy-Authorization: Digest<BR>>> ><BR>>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464@64.154.41.200:5060 <BR>",response <BR>= <BR>"ab63d4755ff4182631ad2db0f9ed0e44 <BR>",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>> > Content-Type: application/sdp<BR>>> > Content-Disposition: session;handling=required<BR>>> > Content-Length: 250<BR>>> > v=0<BR>>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>> > s=SIP Call<BR>>> > c=IN IP4 173.14.220.57<BR>>> > t=0 0<BR>>> > m=audio 16462 RTP/AVP 0 100<BR>>> > c=IN IP4 173.14.220.57<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > a=rtpmap:100 telephone-event/8000<BR>>> > a=fmtp:100
0-15<BR>>> > a=ptime:20<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:09.332:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 100 Trying<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A
href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_SENT_INVITE, <BR>SUBSTATE_NONE) to<BR>>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>
> *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:10.832:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 183 Session Progress<BR>>> > To: <sip:18774675464@64.154.41.200>;tag=3465630735-938664<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 INVITE<BR>>> > Content-Type: application/sdp<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > Content-Length: 146<BR>>> > v=0<BR>>> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>> > s=sip call<BR>>> > c=IN IP4 64.154.41.101<BR>>> > t=0 0<BR>>> > m=audio 45846 RTP/AVP 0<BR>>> > a=ptime:20<BR>>> > a=rtpmap:0 PCMU/8000<BR>>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/ <BR>sipSPICheckResponse:<BR>>> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentGTD: No<BR>>> > GTD<BR>>> > found in inbound container<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>> > Number of m-lines = 1<BR>>> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m- <BR>line 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>> > One ptime attribute found - value:20<BR>>> > *Oct 27 12:34:10.836:<BR>>>
> //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: <BR>Values :Codec:<BR>>> > g711ulaw ptime :20, codecbytes: 160<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: <BR>160 for<BR>>> > codec<BR>>> > g711ulaw<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line <BR>index 1<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>> > Dynamic payload(100) could not be reserved.<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case <BR>of full<BR>>> > named<BR>>> > event(NE) match in fmtp list of events.<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>> > payload<BR>>> > from X-cap = 0<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr <BR>not<BR>>> > present<BR>>> > in SDP. Disable modem relay<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No <BR>direction<BR>>> > attribute present or multiple direction attributes that can't be <BR>handled<BR>>> > for<BR>>> > m-line:1 and num-a-lines:0<BR>>> > *Oct 27 12:34:10.836:<BR>>> >
//846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>> > Codec negotiation successful for media line 1<BR>>> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>> > dtmf_relay=rtp-nte<BR>>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>> > dest_port=45846<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>> > (STREAM_ADDING)<BR>>> > *Oct 27 12:34:10.836:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Preferred Codec : g711ulaw, bytes :160<BR>>> > Preferred DTMF relay : rtp-nte<BR>>> >
Preferred NTE payload : 100<BR>>> > Early Media : No<BR>>> > Delayed Media : No<BR>>> > Bridge Done : No<BR>>> > New Media : No<BR>>> > DSP DNLD Reqd : No<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27
12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4A170B28)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Hndl ptype 0 mline 1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Selecting<BR>>> > codec g711ulaw<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:<BR>>> > Codec to be matched:
5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>ADD<BR>>> > AUDIO<BR>>> > CODEC 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: <BR>Values :Codec:<BR>>> > g711ulaw codecbytes :160, ptime: 20<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Media<BR>>> > negotiation done:<BR>>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160, <BR>coverted<BR>>> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 <BR>ss 1<BR>>> >
64.154.41.101:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: <BR>Copy<BR>>> > sdp to<BR>>> > channel- AFTER CODEC FILTERING:<BR>>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>> > Report initial call media<BR>>> > *Oct 27
12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: <BR>ccb->flags<BR>>> > 0x400018, ccb->pld.flags_ipip 0x200005<BR>>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>> > callId 846 size 240 ptr 0x4DEC000C)<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>> > 5030: Posting Remote SRTP caps to other callleg.<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>> > cc_api_caps_ind()<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>> > Stream type : voice+dtmf<BR>>> > Media line
: 1<BR>>> > State : STREAM_ADDING (2)<BR>>> > Stream address type : 1<BR>>> > Callid : 846<BR>>> > Negotiated Codec : g711ulaw, bytes :160<BR>>> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>> > Negotiated DTMF relay : rtp-nte<BR>>> > Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>> > Negotiated CN payload : 0<BR>>> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>> >
Media Dest Addr/Port : [64.154.41.101]:45846<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>> > headers<BR>>> > recvd from app container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQSIG:<BR>>> > No<BR>>> > QSIG Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPIGetContentQ931:<BR>>> > No<BR>>> > RawMsg Body found in inbound container<BR>>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/ <BR>sipSPICreateNewRawMsg:<BR>>> > No<BR>>> > Data to form The Raw Message<BR>>> > *Oct 27 12:34:10.840:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>> > *Oct
27 12:34:10.840: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>> > SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: <BR>Transaction<BR>>> > Complete. Lock on Facilities released.<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>confID =<BR>>> > 6,<BR>>> > srcCallID = 846, dstCallID = 845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>> > Old streamcallid=846, new
streamcallid=846<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>> > Setting SPI mode to SIP-H323<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = <BR>1131891908<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>> > sipSPIProcessRtpSessions<BR>>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/ <BR>sipSPIAddStream:<BR>>> > Adding<BR>>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: <BR>Media<BR>>> > already<BR>>> > bound, use existing source_media_ip_addr<BR>>> > *Oct 27 12:34:10.844:<BR>>>
> //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>> > Media src addr for stream 1 = 173.14.220.57<BR>>> > *Oct 27 12:34:10.844:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > sipSPIUpdateRtcpSession for m-line 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > rtcp_session info<BR>>> > laddr = 173.14.220.57, lport = 16462, raddr = <BR>64.154.41.101,<BR>>> > rport=45846, do_rtcp=TRUE<BR>>> > src_callid = 846, dest_callid = 845, stream type = voice <BR>+dtmf,<BR>>> > stream direction = SENDRECV<BR>>> > media_ip_addr = 64.154.41.101, vrf tableid = 0 <BR>media_addr_type =<BR>>> > 1<BR>>> > *Oct 27 12:34:10.848:<BR>>> >
//846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>> > RTP session already created - update<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>> > New Remote Media Direction = SENDRECV<BR>>> > Present Local Media Direction = SENDRECV<BR>>> > New Local Media Direction = SENDRECV<BR>>> > retVal = 0<BR>>> > *Oct 27 12:34:10.848:<BR>>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>> > (STREAM_ACTIVE)<BR>>> > *Oct 27 12:34:10.848:
//846/8094E28C1800/SIP/Info/ccsip_bridge: <BR>really<BR>>> > can't<BR>>> > find peer_stream for<BR>>> > dtmf-relay <BR>interworking<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> >
DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.140:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated Modem caps and generate
<BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> >
caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.144:
//846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Setting<BR>>> > CAPS_RECEIVED flag<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > Calling<BR>>> > cc_api_caps_ack()<BR>>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ack: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Entry<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: <BR>CURRENT<BR>>> > VALUES: stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>> > VALUES:<BR>>> > stream_callid=846, current_seq_num=0x11D9<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
<BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with negotiated codec: g711ulaw, Bytes=160<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Set<BR>>> > forking flag to 0x0<BR>>> > *Oct 27 12:34:11.168:<BR>>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx <BR>payload =<BR>>> > 100, tx payload = 100<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>> > config=0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Disabling Modem Relay...<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Negotiation already Done. Set negotiated
Modem caps and generate <BR>SDP<BR>>> > Xcap<BR>>> > list<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > Modem<BR>>> > Relay & Passthru both disabled<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>sip_set_modem_caps:<BR>>> > nse<BR>>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0, <BR>relay=0,<BR>>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 1<BR>>> > Active Streams<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > Adding stream type (voice+dtmf) from media<BR>>> > line 1 codec g711ulaw<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
<BR>sipSPISetStreamInfo:<BR>>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>> > caps.stream_list.xmitFunc=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > voip_rtp_xmit, caps.stream_list.context=<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/ <BR>sipSPISetStreamInfo:<BR>>> > 0x497E0B60 (gccb)<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Load<BR>>> > DSP<BR>>> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: No<BR>>> > video<BR>>> > caps detected in the caps posted by peer leg<BR>>> > *Oct 27 12:34:11.172:
//846/8094E28C1800/SIP/Info/ <BR>ccsip_caps_ind: Second<BR>>> > TCS<BR>>> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>> > *Oct 27 12:34:15.876:<BR>>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>> > stun is disabled for stream:4A1709F8<BR>>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/ <BR>ccsip_call_statistics:<BR>>> > Stats are not supported for IPIP call.<BR>>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>> > Queued<BR>>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/ <BR>sipSPISendCancel:<BR>>> > Associated container=0x4E310C1C to
Cancel<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/ <BR>sipSPISendCancel:<BR>>> > Sending CANCEL to the transport layer<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>> > msg=0x4DF0D994,<BR>>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, <BR>transport=1,<BR>>> > switch=0, callBack=0x419703BC<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage: <BR>Proceedable<BR>>> > for<BR>>> > sending msg immediately<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>> > transport<BR>>> > is 0<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set <BR>to
send<BR>>> > the<BR>>> > msg=0x4DF0D994<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: <BR>Posting<BR>>> > send<BR>>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for <BR>UDP<BR>>> > *Oct 27 12:34:15.880:<BR>>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/ <BR>sipSPIChangeState:<BR>>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, <BR>SUBSTATE_NONE)<BR>>> > to<BR>>> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Sent:<BR>>> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>> > Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Max-Forwards: 70<BR>>> > Timestamp: 1256646855<BR>>> > Reason: Q.850;cause=16<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> >
*Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.900:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> > Received:<BR>>> > SIP/2.0 200 OK<BR>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A>>;tag=2EDA9C8-25D6<BR>>> > To: <sip:18774675464@64.154.41.200><BR>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>> > CSeq: 102 CANCEL<BR>>> > Content-Length: 0<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
<BR>sipSPICheckResponse:<BR>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/ <BR>sipSPIIcpifUpdate:<BR>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>> > context=0x00000000<BR>>> > *Oct 27 12:34:15.912:<BR>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>> > Checking Invite Dialog<BR>>> > *Oct 27
12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>> ><BR>>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A> <BR>><BR>>> > wrote:<BR>>> >><BR>>> >> You would want to check the SDP of 200 OK the provider sends <BR>for your<BR>>> >> outgoing call. It will list the payload type for the dtmf in the<BR>>> >> format a=fmtp 101 1-16, or something similar. You want to find <BR>out<BR>>> >> what payload type they are advertising (or if they are at <BR>all). It<BR>>> >> would be worth checking the incoming INVITE from them to see what<BR>>> >> they're using when they send the first SDP.<BR>>> >><BR>>> >> On that note, I would also remove the asymmetric payload <BR>command -
to<BR>>> >> my knowledge it doesn't do what you're expecting it to. You <BR>may want<BR>>> >> to try this command:<BR>>> >> voice-class sip dtmf-relay force rtp-nte<BR>>> >><BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A> <BR>><BR>>> >> wrote:<BR>>> >> > Hello,<BR>>> >> ><BR>>> >> > I am having an issue with dtmf working outbound. Inbound <BR>dtmf works<BR>>> >> > fine.<BR>>> >> > It took some playing around with it. At first it didnt work <BR>till the<BR>>> >> > payload was ajusted. I am now trying to get outbound dtmf <BR>working<BR>>> >> >
properly.<BR>>> >> ><BR>>> >> > On my 2821 I debugged voip rtp session named-events and then <BR>made a<BR>>> >> > call<BR>>> >> > to<BR>>> >> > a 1800 number and hit digits. I didn't see any dtmf output <BR>on the<BR>>> >> > router<BR>>> >> > nothing showed up in the debug. Does this mean I can safely <BR>asume<BR>>> >> > that<BR>>> >> > the<BR>>> >> > problem for right now is not on the ITSP side but on my side <BR>since<BR>>> >> > dtmf<BR>>> >> > is<BR>>> >> > not being sent down the sip trunk?<BR>>> >> ><BR>>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>> >> > configuration<BR>>> >> > of the cisco 2821 is shown below. Does
anyone have any ideas <BR>what I<BR>>> >> > can<BR>>> >> > do<BR>>> >> > so dtmf digits process properly outbound?<BR>>> >> ><BR>>> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>> >> ><BR>>> >> > h323 cucm gateway configuratration<BR>>> >> > Signaling Port 1720<BR>>> >> > media termination point required yes<BR>>> >> > retry video call as auto yes<BR>>> >> > wait for far end h.245 terminal capability set yes<BR>>> >> > transmit utf-8 calling party name no<BR>>> >> > h.235 pass through allowed no<BR>>> >> > significant digits all<BR>>> >> > redirect number IT deliver - inbound no<BR>>> >> > enable inbound faststart yes<BR>>> >> > display IE deliver no<BR>>> >> >
redirect nunmber IT deliver - outbound no<BR>>> >> > enable outbound faststart yes<BR>>> >> ><BR>>> >> ><BR>>> >> > voice service voip<BR>>> >> > allow-connections h323 to h323<BR>>> >> > allow-connections h323 to sip<BR>>> >> > allow-connections sip to h323<BR>>> >> > allow-connections sip to sip<BR>>> >> > fax protocol pass-through g711ulaw<BR>>> >> > h323<BR>>> >> > emptycapability<BR>>> >> > h225 id-passthru<BR>>> >> > h245 passthru tcsnonstd-passthru<BR>>> >> > sip<BR>>> >> ><BR>>> >> ><BR>>> >> > voice class h323 50<BR>>> >> > h225 timeout tcp establish 3<BR>>> >> > !<BR>>> >> >
!<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-rule 1<BR>>> >> > rule 1 /.*/ /190/<BR>>> >> > !<BR>>> >> > voice translation-rule 2<BR>>> >> > rule 1 /.*/ /1&/<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice translation-profile aa<BR>>> >> > translate called 1<BR>>> >> > !<BR>>> >> > voice translation-profile addone<BR>>> >> > translate called 2<BR>>> >> > !<BR>>> >> > !<BR>>> >> > voice-card 0<BR>>> >> > dspfarm<BR>>> >> > dsp services
dspfarm<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sccp local GigabitEthernet0/1<BR>>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>> >> > sccp<BR>>> >> > !<BR>>> >> > sccp ccm group 1<BR>>> >> > associate ccm 1 priority 1<BR>>> >> > associate ccm 2 priority 2<BR>>> >> > associate profile 1 register 2821transcode<BR>>> >> > !<BR>>> >> > dspfarm profile 1 transcode<BR>>> >> > codec g711ulaw<BR>>> >> > codec g711alaw<BR>>> >> > codec g729ar8<BR>>> >> > codec g729abr8<BR>>> >> > codec g729r8<BR>>> >> > maximum sessions 4<BR>>> >> > associate
application SCCP<BR>>> >> > !<BR>>> >> > !<BR>>> >> > dial-peer voice 100 voip<BR>>> >> > description AA Publisher<BR>>> >> > preference 1<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.10<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > description incoming Call<BR>>> >> > translation-profile incoming aa<BR>>> >> > preference 1<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > incoming called-number
6782282221<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > ip qos dscp cs5 media<BR>>> >> > ip qos dscp cs5 signaling<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > description AA Subscriber<BR>>> >> > preference 2<BR>>> >> > destination-pattern 1..<BR>>> >> > voice-class h323 50<BR>>> >> > session target ipv4:10.1.80.11<BR>>> >> > dtmf-relay h245-alphanumeric<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > description outbound<BR>>> >> > translation-profile outgoing
addone<BR>>> >> > preference 1<BR>>> >> > destination-pattern .T<BR>>> >> > rtp payload-type nse 101<BR>>> >> > rtp payload-type nte 100<BR>>> >> > voice-class sip asymmetric payload dtmf<BR>>> >> > session protocol sipv2<BR>>> >> > session target ipv4:64.154.41.200<BR>>> >> > dtmf-relay rtp-nte<BR>>> >> > codec g711ulaw<BR>>> >> > no vad<BR>>> >> > !<BR>>> >> > !<BR>>> >> > sip-ua<BR>>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net<BR>>> >> > authentication username ***** password 7 *****<BR>>> >> > authentication username ***** password 7 ***** realm<BR>>>
>> > sip.talkinip.net<BR>>> >> > set pstn-cause 3 sip-status 486<BR>>> >> > set pstn-cause 34 sip-status 486<BR>>> >> > set pstn-cause 47 sip-status 486<BR>>> >> > registrar dns:sip.talkinip.net expires 60<BR>>> >> > sip-server dns:sip.talkinip.net:5060<BR>>> >> > _______________________________________________<BR>>> >> > cisco-voip mailing list<BR>>> >> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>> >> ><BR>>> >> ><BR>>> ><BR>>> ><BR>><BR>> _______________________________________________<BR>> cisco-voip
mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR><BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/8a3fd6d4/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/8a3fd6d4/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 20<BR>Date: Tue, 27 Oct 2009 15:38:59 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Jeff Cartier <<A href="mailto:jcartier@acs.on.ca" ymailto="mailto:jcartier@acs.on.ca">jcartier@acs.on.ca</A>><BR>Cc: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] Cisco 7961 - Wrong Time, No Local Directory,<BR> No Services<BR>Message-ID: <<A href="mailto:7D5EAED9-A0A4-45D1-9E94-422BE71EF24D@cisco.com" ymailto="mailto:7D5EAED9-A0A4-45D1-9E94-422BE71EF24D@cisco.com">7D5EAED9-A0A4-45D1-9E94-422BE71EF24D@cisco.com</A>><BR>Content-Type: text/plain; charset="windows-1252";
Format="flowed";<BR> DelSp="yes"<BR><BR>Regarding the DNS Unknown Host error it's not affecting your time, but <BR>is breaking your services/directories. What version of CUCM are you <BR>using?<BR><BR>Keep in mind that just because you have DNS configured doesn't mean <BR>the phone is able to resolve whatever it is trying to.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 3:27 PM, Jeff Cartier wrote:<BR><BR>I?m having an issue with a Cisco 7961 phone not showing the proper <BR>time, local directory and services. I think it is somehow related to <BR>the ?DNS Unknown Host? error I?m getting when I look at the status <BR>messages. Anyone seen anything similar? Odd thing is that I have DNS <BR>running.<BR><BR><BR>jeff<BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/27bbfea4/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/27bbfea4/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 21<BR>Date: Tue, 27 Oct 2009 15:39:52 -0400<BR>From: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>To: Scott Voll <<A href="mailto:svoll.voip@gmail.com" ymailto="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</A>><BR>Cc: <A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] What am I missing with Background images?<BR>Message-ID: <<A href="mailto:02E27121-B64C-43EE-B0A8-1888867A3462@cisco.com" ymailto="mailto:02E27121-B64C-43EE-B0A8-1888867A3462@cisco.com">02E27121-B64C-43EE-B0A8-1888867A3462@cisco.com</A>><BR>Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes<BR><BR>Get a packet capture from behind the phone, is it getting all of the <BR>files it is asking for? If so do cmd-line tftp requests for the same <BR>files and make sure they are valid.<BR><BR>-Ryan<BR><BR>On Oct 27, 2009, at 3:34 PM, Scott Voll wrote:<BR><BR>I have uploaded both the thumb nail and full png file for the image I <BR>want to use for a background. (both to the Desktops/320x196x4/ <BR>directory)<BR><BR>I have also added the list.xml file to both the root and the Desktops/ <BR>320x196x4/ and
restarted both phone and TFTP server without being able <BR>to get it to work. What am I missing?<BR><BR>Scott<BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR><BR>------------------------------<BR><BR>Message: 22<BR>Date: Tue, 27 Oct 2009 15:38:50 -0400<BR>From: "Joe Pollere (US)" <<A href="mailto:Joe.Pollere@us.didata.com" ymailto="mailto:Joe.Pollere@us.didata.com">Joe.Pollere@us.didata.com</A>><BR>To: "Scott Voll" <<A href="mailto:svoll.voip@gmail.com" ymailto="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</A>>, <<A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] What am I missing with Background images?<BR>Message-ID:<BR> <<A href="mailto:C65033A817B5734392E55CB9DF4461041B9E4741@USNAEXCH.na.didata.local" ymailto="mailto:C65033A817B5734392E55CB9DF4461041B9E4741@USNAEXCH.na.didata.local">C65033A817B5734392E55CB9DF4461041B9E4741@USNAEXCH.na.didata.local</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>It is case sensitive. list.xml should be List.xml <BR><BR><BR><BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><BR>[mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Scott Voll<BR>Sent: Tuesday, October 27, 2009 3:35 PM<BR>To: <A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] What am I missing with Background images?<BR><BR><BR><BR>I have uploaded both the thumb nail and full png file for the image I<BR>want to use for a background. (both to the Desktops/320x196x4/<BR>directory)<BR><BR><BR><BR>I have also added the list.xml file to both the root and the<BR>Desktops/320x196x4/ and restarted both phone and TFTP server without<BR>being able to get it to work. What am I missing?<BR><BR><BR><BR>Scott<BR><BR><BR><BR><BR>-----------------------------------------<BR>Disclaimer:<BR><BR>This e-mail communication and any attachments may contain<BR>confidential and privileged information and is for use by the<BR>designated addressee(s) named above only. If you are not the<BR>intended addressee, you are hereby notified that you have received<BR>this communication in error and that any
use or reproduction of<BR>this email or its contents is strictly prohibited and may be<BR>unlawful. If you have received this communication in error, please<BR>notify us immediately by replying to this message and deleting it<BR>from your computer. Thank you.<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/baa97e31/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/baa97e31/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 23<BR>Date: Tue, 27 Oct 2009 15:45:46 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: cisco-voip <<A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271245m17958ab6i8976410b64f45294@mail.gmail.com" ymailto="mailto:a54820e50910271245m17958ab6i8976410b64f45294@mail.gmail.com">a54820e50910271245m17958ab6i8976410b64f45294@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Hmm that does not sound good<BR><BR>This is with the default settings<BR><BR>rtp payload-type nte 101<BR>rtp payload-type nse 100<BR><BR>which don't show up in the config. Could there be any reason why the router<BR>is not able to use 101 below are my dial peers<BR><BR>dial-peer voice 100 voip<BR>description AA Publisher<BR>preference 1<BR>destination-pattern 1..<BR>voice-class h323 50<BR>session target ipv4:10.1.80.10<BR>dtmf-relay
h245-alphanumeric<BR>codec g711ulaw<BR>no vad<BR>!<BR>dial-peer voice 1000 voip<BR>description incoming Call<BR>translation-profile incoming aa<BR>preference 1<BR><BR>incoming called-number 6784442454<BR><BR>dtmf-relay rtp-nte<BR>codec g711ulaw<BR>ip qos dscp cs5 media<BR>ip qos dscp cs5 signaling<BR>no vad<BR>!<BR>dial-peer voice 101 voip<BR>description AA Subscriber<BR>preference 2<BR>destination-pattern 1..<BR>voice-class h323 50<BR>session target ipv4:10.1.80.11<BR>dtmf-relay h245-alphanumeric<BR>codec g711ulaw<BR>no vad<BR>!<BR>dial-peer voice 2000 voip<BR>description outbound<BR>translation-profile outgoing addone<BR>preference 1<BR>destination-pattern .T<BR><BR>progress_ind setup enable 3<BR>progress_ind progress enable 8<BR>session protocol sipv2<BR>session target dns:did.voip.les.net<BR><BR>dtmf-relay rtp-nte<BR>codec g711ulaw<BR><BR>!<BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A
href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/0d809b65/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/0d809b65/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 24<BR>Date: Tue, 27 Oct 2009 16:30:02 -0400<BR>From: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:56c3b48b0910271330m5895ceco6ab5315dd410c29a@mail.gmail.com"
ymailto="mailto:56c3b48b0910271330m5895ceco6ab5315dd410c29a@mail.gmail.com">56c3b48b0910271330m5895ceco6ab5315dd410c29a@mail.gmail.com</A>><BR>Content-Type: text/plain; charset=ISO-8859-1<BR><BR>That shows up in the debugs in working scenarios too. Not sure what<BR>the importance of those statements are, but it's the type of thing you<BR>see when you add 'all' to a debug.<BR><BR>It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>your INVITE. And you want a 200 OK. I've seen it where the debugs<BR>will show that we're sending DTMF but the provider won't use it, which<BR>is a conversation you would need to have with the provider.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>> wrote:<BR>> Hmm that does not sound good<BR>><BR>> This is with the default settings<BR>><BR>>
rtp payload-type nte 101<BR>> rtp payload-type nse 100<BR>><BR>> which don't show up in the config.? Could there be any reason why the router<BR>> is not able to use 101 below are my dial peers<BR>><BR>> dial-peer voice 100 voip<BR>> ?description AA Publisher<BR>> ?preference 1<BR>> ?destination-pattern 1..<BR>> ?voice-class h323 50<BR>> ?session target ipv4:10.1.80.10<BR>> ?dtmf-relay h245-alphanumeric<BR>> ?codec g711ulaw<BR>> ?no vad<BR>> !<BR>> dial-peer voice 1000 voip<BR>> ?description incoming Call<BR>> ?translation-profile incoming aa<BR>> ?preference 1<BR>><BR>> ?incoming called-number 6784442454<BR>><BR>> ?dtmf-relay rtp-nte<BR>> ?codec g711ulaw<BR>> ?ip qos dscp cs5 media<BR>> ?ip qos dscp cs5 signaling<BR>> ?no vad<BR>> !<BR>> dial-peer voice 101 voip<BR>> ?description AA Subscriber<BR>> ?preference 2<BR>> ?destination-pattern 1..<BR>>
?voice-class h323 50<BR>> ?session target ipv4:10.1.80.11<BR>> ?dtmf-relay h245-alphanumeric<BR>> ?codec g711ulaw<BR>> ?no vad<BR>> !<BR>> dial-peer voice 2000 voip<BR>> ?description outbound<BR>> ?translation-profile outgoing addone<BR>> ?preference 1<BR>> ?destination-pattern .T<BR>><BR>> ?progress_ind setup enable 3<BR>> ?progress_ind progress enable 8<BR>> ?session protocol sipv2<BR>> ?session target dns:did.voip.les.net<BR>><BR>> ?dtmf-relay rtp-nte<BR>> ?codec g711ulaw<BR>><BR>> !<BR><BR><BR>------------------------------<BR><BR>Message: 25<BR>Date: Tue, 27 Oct 2009 15:42:34 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>Cc: cisco-voip <<A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271242w6cf18450v4551dd5e7237855@mail.gmail.com" ymailto="mailto:a54820e50910271242w6cf18450v4551dd5e7237855@mail.gmail.com">a54820e50910271242w6cf18450v4551dd5e7237855@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Hmm that does not sound good<BR><BR>This is with the default settings<BR><BR>rtp payload-type nte 101<BR>rtp payload-type nse 100<BR><BR>which don't show up in the config. Could there be any reason why the router<BR>is not able to use 101 below are my dial peers<BR><BR>dial-peer voice 100 voip<BR>description AA Publisher<BR>preference 1<BR>destination-pattern 1..<BR>voice-class h323 50<BR>session target ipv4:10.1.80.10<BR>dtmf-relay
h245-alphanumeric<BR>codec g711ulaw<BR>no vad<BR>!<BR>dial-peer voice 1000 voip<BR>description incoming Call<BR>translation-profile incoming aa<BR>preference 1<BR>incoming called-number 6784442454<BR>dtmf-relay rtp-nte<BR>codec g711ulaw<BR>ip qos dscp cs5 media<BR>ip qos dscp cs5 signaling<BR>no vad<BR>!<BR>dial-peer voice 101 voip<BR>description AA Subscriber<BR>preference 2<BR>destination-pattern 1..<BR>voice-class h323 50<BR>session target ipv4:10.1.80.11<BR>dtmf-relay h245-alphanumeric<BR>codec g711ulaw<BR>no vad<BR>!<BR>dial-peer voice 2000 voip<BR>description outbound<BR>translation-profile outgoing addone<BR>preference 1<BR>destination-pattern .T<BR>progress_ind setup enable 3<BR>progress_ind progress enable 8<BR>session protocol sipv2<BR>session target dns:did.voip.les.net<BR>dtmf-relay rtp-nte<BR>codec g711ulaw<BR>!<BR>!<BR><BR>On Tue, Oct 27, 2009 at 3:37 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com"
ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR><BR>> It means the router can't use payload type 101 for that call. What is the<BR>> config for the voip dial-peer getting used on the outbound call?<BR>><BR>> -Ryan<BR>><BR>> On Oct 27, 2009, at 3:16 PM, Dane Newman wrote:<BR>><BR>> Yes the session progress is receviced by the router<BR>><BR>> In all my debugs I noticed I have the same thing<BR>><BR>> *Oct 27 20:25:37.558:<BR>> //1528/003E40690D00/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)<BR>> could not be reserved.<BR>> *Oct 27 20:25:37.558:<BR>> //1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>> relay option<BR>> *Oct 27 20:25:37.562:<BR>> //1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>> named event(NE) match in fmtp list of events.<BR>> *Oct 27 20:25:37.562:<BR>>
//-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload<BR>> from X-cap = 0<BR>> *Oct 27 20:25:37.562:<BR>> //1528/003E40690D00/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>> present in SDP. Disable modem relay<BR>><BR>> Is Dynamic payload(101) could not be reserved telling me I have no dtmf<BR>> support?<BR>><BR>> On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR>><BR>>> I doubt that is related to your lack of DTMF but it's most likely the side<BR>>> sending the 183 is actually counting 1-16 and printing the 0. The Session<BR>>> Progress is received by the router isn't it?<BR>>><BR>>> There are only 16 DTMF characters, the 12 on your keypad and 4 hidden ones<BR>>> A, B, C, and D.<BR>>><BR>>>
-Ryan<BR>>><BR>>> On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:<BR>>><BR>>> The difference I see between the invite and the 183 session progression<BR>>> from the telco is<BR>>><BR>>> invite<BR>>> a=fmtp:101 0-15<BR>>><BR>>> session progression<BR>>> a=fmtp:101 0-16<BR>>><BR>>> Could this miss match in supported digits be what is causing all dtmf not<BR>>> to work? How can I make my cisco router support 0-16?<BR>>><BR>>> Dane<BR>>><BR>>> *Invite*<BR>>> **<BR>>> **<BR>>> v=0<BR>>> o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57<BR>>> s=SIP Call<BR>>> c=IN IP4 173.14.220.57<BR>>> t=0 0<BR>>> m=audio 18770 RTP/AVP 0 101 19<BR>>> c=IN IP4 173.14.220.57<BR>>> a=rtpmap:0 PCMU/8000<BR>>> a=rtpmap:101 telephone-event/8000<BR>>> a=fmtp:101 0-15<BR>>>
a=rtpmap:19 CN/8000<BR>>> a=ptime:20<BR>>><BR>>><BR>>><BR>>> *session progression*<BR>>><BR>>><BR>>> v=0<BR>>> o=root 5115 5115 IN IP4 64.34.181.47<BR>>> s=session<BR>>> c=IN IP4 64.34.181.47<BR>>> t=0 0<BR>>> m=audio 17646 RTP/AVP 0 101<BR>>> a=rtpmap:0 PCMU/8000<BR>>> a=rtpmap:101 telephone-event/8000<BR>>> a=fmtp:101 0-16<BR>>> a=silenceSupp:off - - - -<BR>>><BR>>> On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>> wrote:<BR>>><BR>>>> Sorry this part is the actual DTMF:<BR>>>><BR>>>> a=rtpmap:101 telephone-event/8000<BR>>>><BR>>>> The line you quoted is part of the SDP and references both RTP and DTMF.<BR>>>> m=audio 11680 RTP/AVP 0 101<BR>>>> a=rtpmap:0
PCMU/8000<BR>>>> a=rtpmap:101 telephone-event/8000<BR>>>> a=fmtp:101 0-16<BR>>>> a=silenceSupp:off - - - -<BR>>>><BR>>>> The fist line means your RTP is on port 11680 and references the a:rtpmap<BR>>>> entries for 0 and 101.<BR>>>> The second line means your RTP is g.711.<BR>>>> The 3rd line is the DTMF with a payload type of 101.<BR>>>> The 4th line means it can accept DTMF 0-16<BR>>>> The last line is pretty self explanatory (silence suppression disabled).<BR>>>><BR>>>> This is a very basic interpretation of the SDP info. RFC 2327 is where<BR>>>> you want to go to get into the nitty-gritty details.<BR>>>><BR>>>> -Ryan<BR>>>><BR>>>> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:<BR>>>><BR>>>> That is RFC2833 DTMF with a payload type of
101.<BR>>>><BR>>>> I do know that CUBE cannot do dynamic RFC2833 payload types. It can only<BR>>>> send the payloadType defined in the voip dial-peer. So if inbound calls use<BR>>>> a different payloadType than outbound calls you will want to update the<BR>>>> dial-peers accordingly.<BR>>>><BR>>>><BR>>>> -Ryan<BR>>>><BR>>>> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:<BR>>>><BR>>>> Well I tried to switch providers just to test it out and now I am getting<BR>>>> something back in the 183 but still no dtmf hmm<BR>>>><BR>>>> I see they are sending me<BR>>>><BR>>>> m=audio 11680 RTP/AVP 0 101<BR>>>><BR>>>> How do I interperate that line?<BR>>>><BR>>>><BR>>>> Received:<BR>>>> SIP/2.0 183 Session Progress<BR>>>> Via:
SIP/2.0/UDP 173.14.220.57:5060<BR>>>> ;branch=z9hG4bK749136B;received=173.14.220.57<BR>>>> From: <sip:<A href="mailto:6782282221@did.voip.les.net" ymailto="mailto:6782282221@did.voip.les.net">6782282221@did.voip.les.net</A><sip%<A href="mailto:3A6782282221@did.voip.les.net" ymailto="mailto:3A6782282221@did.voip.les.net">3A6782282221@did.voip.les.net</A>><BR>>>> >;tag=419FE94-8A1<BR>>>> To: <sip:<A href="mailto:18774675464@did.voip.les.net" ymailto="mailto:18774675464@did.voip.les.net">18774675464@did.voip.les.net</A><sip%<A href="mailto:3A18774675464@did.voip.les.net" ymailto="mailto:3A18774675464@did.voip.les.net">3A18774675464@did.voip.les.net</A>><BR>>>> >;tag=as5677a12c<BR>>>> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7@173.14.220.57<BR>>>> CSeq: 101 INVITE<BR>>>> User-Agent: LES.NET.VoIP<BR>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER,
SUBSCRIBE, NOTIFY<BR>>>> Contact: <sip:18774675464@64.34.181.47 <sip%3A18774675464@64.34.181.47>><BR>>>> Content-Type: application/sdp<BR>>>> Content-Length: 214<BR>>>> v=0<BR>>>> o=root 5115 5115 IN IP4 64.34.181.47<BR>>>> s=session<BR>>>> c=IN IP4 64.34.181.47<BR>>>> t=0 0<BR>>>> m=audio 11680 RTP/AVP 0 101<BR>>>> a=rtpmap:0 PCMU/8000<BR>>>> a=rtpmap:101 telephone-event/8000<BR>>>> a=fmtp:101 0-16<BR>>>> a=silenceSupp:off - - - -<BR>>>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:<BR>>>> INVITE response with no RSEQ - disable IS_REL1XX<BR>>>> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No<BR>>>> GTD found in inbound container<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation:
Number of m-lines = 1<BR>>>> SIP: Attribute mid, level 1 instance 1 not found.<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already<BR>>>> bound, use existing source_media_ip_addr<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr: Media src addr for<BR>>>> stream 1 = 173.14.220.57<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)<BR>>>> Negotiation Successful on Static Payload for m-line 1<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or<BR>>>> multiple ptime attributes that can't be handled<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index
1<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)<BR>>>> could not be reserved.<BR>>>> *Oct 27 18:02:12.551:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF<BR>>>> relay option<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full<BR>>>> named event(NE) match in fmtp list of events.<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload<BR>>>> from X-cap = 0<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not<BR>>>> present in SDP. Disable modem relay<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No
direction<BR>>>> attribute present or multiple direction attributes that can't be handled for<BR>>>> m-line:1 and num-a-lines:0<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation<BR>>>> successful for media line 1<BR>>>> payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>>> dtmf_relay=rtp-nte<BR>>>> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,<BR>>>> dest_port=11680<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =<BR>>>> -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)<BR>>>> *Oct 27 18:02:12.555:<BR>>>> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>>> Preferred Codec
: g711ulaw, bytes :160<BR>>>> Preferred DTMF relay : rtp-nte<BR>>>> Preferred NTE payload : 101<BR>>>> Early Media : No<BR>>>> Delayed Media : No<BR>>>> Bridge Done : No<BR>>>> New Media : No<BR>>>> DSP DNLD Reqd : No<BR>>>><BR>>>> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>>wrote:<BR>>>><BR>>>>> The 200 OK that you've pasted is
confirming the CANCEL that we sent.<BR>>>>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see<BR>>>>> a 200 OK with the CSeq for 101 INVITE.<BR>>>>><BR>>>>> I've seen this for certain IVRs/providers - sometimes they don't<BR>>>>> properly terminate a call with a 200 OK. If you were not sending an<BR>>>>> SDP in your original INVITE, then you would need the PRACK setting<BR>>>>> mentioned. You have two problems, either could fix the problem: They<BR>>>>> could advertise DTMF in their 183, or they could send you a 200 OK for<BR>>>>> the call. It is assumed you would get DTMF in the 200 OK. It's<BR>>>>> common for endpoints that support DTMF to not advertise it in the 183<BR>>>>> because you technically shouldn't need DTMF to hear
ringback.<BR>>>>><BR>>>>> -nick<BR>>>>><BR>>>>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <<A href="mailto:rratliff@cisco.com" ymailto="mailto:rratliff@cisco.com">rratliff@cisco.com</A>><BR>>>>> wrote:<BR>>>>> > There is no SDP in that 200 OK so I would assume the media info is the<BR>>>>> same<BR>>>>> > as in the 183 Ringing message. You really need your ITSP to tell you<BR>>>>> what<BR>>>>> > dtmf method they want you to use on your outbound calls. As Nick<BR>>>>> said they<BR>>>>> > don't appear to be advertising any dtmf method at all.<BR>>>>> > -Ryan<BR>>>>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:<BR>>>>> > Is the below the ok I should be getting?<BR>>>>> ><BR>>>>>
><BR>>>>> > They did send this with the first debug<BR>>>>> ><BR>>>>> > Received:<BR>>>>> > SIP/2.0 200 OK<BR>>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC<BR>>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=32DA608-109A<BR>>>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>>>>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7@173.14.220.57<BR>>>>> > CSeq: 102 CANCEL<BR>>>>> > Content-Length: 0<BR>>>>> > *Oct 27 13:44:12.828:
//922/009B1B501B00/SIP/Info/sipSPICheckResponse:<BR>>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:<BR>>>>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0<BR>>>>> > *Oct 27 13:44:12.836:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> > *Oct 27 13:44:12.840:<BR>>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> > *Oct 27 13:44:12.840:<BR>>>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> > context=0x00000000<BR>>>>> > *Oct 27 13:44:12.840:<BR>>>>>
//-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> > Checking Invite Dialog<BR>>>>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> ><BR>>>>> > This with the 2nd debug<BR>>>>> ><BR>>>>> > Received:<BR>>>>> > SIP/2.0 200 OK<BR>>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200>><BR>>>>> > Call-ID:
DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> > CSeq: 102 CANCEL<BR>>>>> > Content-Length: 0<BR>>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>>>> > *Oct 27 12:34:15.912:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> > *Oct 27 12:34:15.912:<BR>>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> > *Oct 27 12:34:15.912:<BR>>>>> >
//-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> > context=0x00000000<BR>>>>> > *Oct 27 12:34:15.912:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> > Checking Invite Dialog<BR>>>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> > Received:<BR>>>>> > SIP/2.0 487 Request Terminated<BR>>>>> > To: <sip:18774675464@64.154.41.200 <sip%3A18774675464@64.154.41.200><BR>>>>> >;tag=3465630735-938664<BR>>>>> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>>
>;tag=2EDA9C8-25D6<BR>>>>> > Contact: <sip:18774675464@64.154.41.200:5060><BR>>>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> > CSeq: 102 INVITE<BR>>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> > Content-Length: 0<BR>>>>> ><BR>>>>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>>>> wrote:<BR>>>>> >><BR>>>>> >> In the 183 Session Progress they're not advertising DTMF:<BR>>>>> >><BR>>>>> >> m=audio 45846 RTP/AVP 0<BR>>>>> >><BR>>>>> >> There should be a 100 or 101 there. Although, 183 is just ringback.<BR>>>>> >> You would want to pick up on
the other side and they should send a<BR>>>>> 200<BR>>>>> >> OK with a new SDP. If the other side did pick up, you need to tell<BR>>>>> >> the provider that they need to send a 200 OK, because they're not.<BR>>>>> >><BR>>>>> >><BR>>>>> >> -nick<BR>>>>> >><BR>>>>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>>>> >> wrote:<BR>>>>> >> > Nick<BR>>>>> >> ><BR>>>>> >> > I removed voice-class sip asymmetric payload dtmf and added in the<BR>>>>> >> > other<BR>>>>> >> > line<BR>>>>> >> ><BR>>>>> >> > Just to state incoming dtmf works
but not outbound the ITSP has<BR>>>>> told me<BR>>>>> >> > they<BR>>>>> >> > are using two different sip servers/vendors for processing inbound<BR>>>>> and<BR>>>>> >> > outbound<BR>>>>> >> > How does this translate into what I should sent the following too?<BR>>>>> >> ><BR>>>>> >> > rtp payload-type nse<BR>>>>> >> > rtp payload-type nte<BR>>>>> >> ><BR>>>>> >> > In the debug trhe following where set<BR>>>>> >> ><BR>>>>> >> > rtp payload-type nse 101<BR>>>>> >> > rtp payload-type nte 100<BR>>>>> >> ><BR>>>>> >> > In the debug of ccsip If I am looking at it correctly I see me<BR>>>>> sending<BR>>>>> >> >
this<BR>>>>> >> ><BR>>>>> >> > *Oct 27 12:34:09.128:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:<BR>>>>> >> > Preferred method of dtmf relay is: 6, with payload: 100<BR>>>>> >> > *Oct 27 12:34:09.128:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:<BR>>>>> >> > max_event 15<BR>>>>> >> ><BR>>>>> >> > and<BR>>>>> >> ><BR>>>>> >> ><BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>>>> >> > payload<BR>>>>> >> > from X-cap = 0<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> >
//846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr<BR>>>>> not<BR>>>>> >> > present<BR>>>>> >> > in SDP. Disable modem relay<BR>>>>> >> ><BR>>>>> >> ><BR>>>>> >> > Sent:<BR>>>>> >> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD<BR>>>>> >> > Remote-Party-ID:<BR>>>>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>>>>> >;party=calling;screen=yes;privacy=off<BR>>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net"
ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> ><BR>>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>>>> >> > Min-SE: 1800<BR>>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,<BR>>>>> >> > SUBSCRIBE,<BR>>>>> >> > NOTIFY, INFO, REGISTER<BR>>>>> >> >
CSeq: 101 INVITE<BR>>>>> >> > Max-Forwards: 70<BR>>>>> >> > Timestamp: 1256646849<BR>>>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>>>> >> > Expires: 180<BR>>>>> >> > Allow-Events: telephone-event<BR>>>>> >> > Content-Type: application/sdp<BR>>>>> >> > Content-Disposition: session;handling=required<BR>>>>> >> > Content-Length: 250<BR>>>>> >> > v=0<BR>>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>>>> >> > s=SIP Call<BR>>>>> >> > c=IN IP4 173.14.220.57<BR>>>>> >> > t=0 0<BR>>>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>>>> >> > c=IN IP4 173.14.220.57<BR>>>>> >> > a=rtpmap:0
PCMU/8000<BR>>>>> >> > a=rtpmap:100 telephone-event/8000<BR>>>>> >> > a=fmtp:100 0-15<BR>>>>> >> > a=ptime:20<BR>>>>> >> ><BR>>>>> >> ><BR>>>>> >> > Then when I do a search for fmtp again further down I see<BR>>>>> >> ><BR>>>>> >> > Sent:<BR>>>>> >> > INVITE sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> >> > Remote-Party-ID:<BR>>>>> >> > <sip:6782282221@173.14.220.57 <sip%3A6782282221@173.14.220.57><BR>>>>> >;party=calling;screen=yes;privacy=off<BR>>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net"
ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> ><BR>>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat<BR>>>>> >> > Min-SE: 1800<BR>>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941<BR>>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x<BR>>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE,
REFER,<BR>>>>> >> > SUBSCRIBE,<BR>>>>> >> > NOTIFY, INFO, REGISTER<BR>>>>> >> > CSeq: 102 INVITE<BR>>>>> >> > Max-Forwards: 70<BR>>>>> >> > Timestamp: 1256646849<BR>>>>> >> > Contact: <sip:6782282221@173.14.220.57:5060><BR>>>>> >> > Expires: 180<BR>>>>> >> > Allow-Events: telephone-event<BR>>>>> >> > Proxy-Authorization: Digest<BR>>>>> >> ><BR>>>>> >> > username="1648245954",realm="64.154.41.110",uri="<BR>>>>> sip:18774675464@64.154.41.200:5060<BR>>>>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5<BR>>>>> >> > Content-Type: application/sdp<BR>>>>> >> > Content-Disposition:
session;handling=required<BR>>>>> >> > Content-Length: 250<BR>>>>> >> > v=0<BR>>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57<BR>>>>> >> > s=SIP Call<BR>>>>> >> > c=IN IP4 173.14.220.57<BR>>>>> >> > t=0 0<BR>>>>> >> > m=audio 16462 RTP/AVP 0 100<BR>>>>> >> > c=IN IP4 173.14.220.57<BR>>>>> >> > a=rtpmap:0 PCMU/8000<BR>>>>> >> > a=rtpmap:100 telephone-event/8000<BR>>>>> >> > a=fmtp:100 0-15<BR>>>>> >> > a=ptime:20<BR>>>>> >> > *Oct 27 12:34:09.332:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> >> > *Oct 27
12:34:09.332:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> >> > *Oct 27 12:34:09.332:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> >> > context=0x00000000<BR>>>>> >> > *Oct 27 12:34:09.332:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> >> > Checking Invite Dialog<BR>>>>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> >> > Received:<BR>>>>> >> > SIP/2.0 100 Trying<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> >> > From: <sip:<A
href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> ><BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > CSeq: 102 INVITE<BR>>>>> >> > Content-Length: 0<BR>>>>> >> > *Oct 27 12:34:09.332:<BR>>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>>> >> > INVITE response with no RSEQ - disable IS_REL1XX<BR>>>>> >> > *Oct 27 12:34:09.332:<BR>>>>>
//846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE)<BR>>>>> to<BR>>>>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)<BR>>>>> >> > *Oct 27 12:34:10.832:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> >> > *Oct 27 12:34:10.832:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> >> > *Oct 27 12:34:10.832:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> >> > context=0x00000000<BR>>>>> >> >
*Oct 27 12:34:10.836:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> >> > Checking Invite Dialog<BR>>>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> >> > Received:<BR>>>>> >> > SIP/2.0 183 Session Progress<BR>>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> >;tag=3465630735-938664<BR>>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > Contact:
<sip:18774675464@64.154.41.200:5060><BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > CSeq: 102 INVITE<BR>>>>> >> > Content-Type: application/sdp<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> >> > Content-Length: 146<BR>>>>> >> > v=0<BR>>>>> >> > o=msx71 490 6110 IN IP4 64.154.41.200<BR>>>>> >> > s=sip call<BR>>>>> >> > c=IN IP4 64.154.41.101<BR>>>>> >> > t=0 0<BR>>>>> >> > m=audio 45846 RTP/AVP 0<BR>>>>> >> > a=ptime:20<BR>>>>> >> > a=rtpmap:0 PCMU/8000<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>>> >> >
INVITE response with no RSEQ - disable IS_REL1XX<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No<BR>>>>> >> > GTD<BR>>>>> >> > found in inbound container<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:<BR>>>>> >> > Number of m-lines = 1<BR>>>>> >> > SIP: Attribute mid, level 1 instance 1 not found.<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>>> >> > already<BR>>>>> >> > bound, use existing source_media_ip_addr<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> >
//846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>>>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for<BR>>>>> m-line 1<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:<BR>>>>> >> > One ptime attribute found - value:20<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values<BR>>>>> :Codec:<BR>>>>> >> > g711ulaw ptime :20, codecbytes: 160<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> >
//-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>>>> :Codec:<BR>>>>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:<BR>>>>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160<BR>>>>> for<BR>>>>> >> > codec<BR>>>>> >> > g711ulaw<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line<BR>>>>> index 1<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:<BR>>>>> >> > Dynamic payload(100) could not be reserved.<BR>>>>> >> > *Oct 27
12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of<BR>>>>> full<BR>>>>> >> > named<BR>>>>> >> > event(NE) match in fmtp list of events.<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE<BR>>>>> >> > payload<BR>>>>> >> > from X-cap = 0<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr<BR>>>>> not<BR>>>>> >> > present<BR>>>>> >> > in SDP. Disable modem relay<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No<BR>>>>>
direction<BR>>>>> >> > attribute present or multiple direction attributes that can't be<BR>>>>> handled<BR>>>>> >> > for<BR>>>>> >> > m-line:1 and num-a-lines:0<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:<BR>>>>> >> > Codec negotiation successful for media line 1<BR>>>>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,<BR>>>>> >> > dtmf_relay=rtp-nte<BR>>>>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,<BR>>>>> >> > dest_port=45846<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>>>> >>
> Stream (callid = -1) State changed from (STREAM_DEAD) to<BR>>>>> >> > (STREAM_ADDING)<BR>>>>> >> > *Oct 27 12:34:10.836:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>>>> >> > Preferred Codec : g711ulaw, bytes :160<BR>>>>> >> > Preferred DTMF relay : rtp-nte<BR>>>>> >> > Preferred NTE payload : 100<BR>>>>> >> > Early Media : No<BR>>>>> >> > Delayed Media : No<BR>>>>> >> > Bridge Done : No<BR>>>>>
>> > New Media : No<BR>>>>> >> > DSP DNLD Reqd : No<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>>> >> > already<BR>>>>> >> > bound, use existing source_media_ip_addr<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>>> >> > callId 846 peer 845 flags 0x200005 state
STATE_RECD_PROCEEDING<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C<BR>>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>>>> >> > callId 846 size 240 ptr 0x4A170B28)<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> >> > Hndl ptype 0 mline 1<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> >> > Selecting<BR>>>>> >> > codec g711ulaw<BR>>>>> >> > *Oct 27 12:34:10.840:
//846/8094E28C1800/SIP/Info/codec_found:<BR>>>>> >> > Codec to be matched: 5<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> ADD<BR>>>>> >> > AUDIO<BR>>>>> >> > CODEC 5<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values<BR>>>>> :Codec:<BR>>>>> >> > g711ulaw codecbytes :160, ptime: 20<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> Media<BR>>>>> >> > negotiation done:<BR>>>>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,<BR>>>>>
coverted<BR>>>>> >> > ptime=20 stream->mline_index=1, media_ndx=1<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss<BR>>>>> 1<BR>>>>> >> > 64.154.41.101:45846<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> Copy<BR>>>>> >> > sdp to<BR>>>>> >> > channel- AFTER CODEC FILTERING:<BR>>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> >
//846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:<BR>>>>> Copy<BR>>>>> >> > sdp to<BR>>>>> >> > channel- AFTER CODEC FILTERING:<BR>>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>>> >> > Report initial call media<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:<BR>>>>> ccb->flags<BR>>>>> >> >
0x400018, ccb->pld.flags_ipip 0x200005<BR>>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:<BR>>>>> >> > callId 846 size 240 ptr 0x4DEC000C)<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:<BR>>>>> >> > 5030: Posting Remote SRTP caps to other callleg.<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do<BR>>>>> >> > cc_api_caps_ind()<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:<BR>>>>> >> > Stream type : voice+dtmf<BR>>>>> >> >
Media line : 1<BR>>>>> >> > State : STREAM_ADDING (2)<BR>>>>> >> > Stream address type : 1<BR>>>>> >> > Callid : 846<BR>>>>> >> > Negotiated Codec : g711ulaw, bytes :160<BR>>>>> >> > Nego. Codec payload : 0 (tx), 0 (rx)<BR>>>>> >> > Negotiated DTMF relay : rtp-nte<BR>>>>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)<BR>>>>>
>> > Negotiated CN payload : 0<BR>>>>> >> > Media Srce Addr/Port : [173.14.220.57]:16462<BR>>>>> >> > Media Dest Addr/Port : [64.154.41.101]:45846<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI<BR>>>>> >> > headers<BR>>>>> >> > recvd from app container<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:<BR>>>>> >> > No<BR>>>>> >> > QSIG Body found in inbound container<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:<BR>>>>> >> >
No<BR>>>>> >> > RawMsg Body found in inbound container<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:<BR>>>>> >> > No<BR>>>>> >> > Data to form The Raw Message<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>>>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS<BR>>>>> >> > *Oct 27 12:34:10.840:<BR>>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,<BR>>>>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,<BR>>>>> >> > SUBSTATE_NONE)<BR>>>>> >> > *Oct 27
12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:<BR>>>>> Transaction<BR>>>>> >> > Complete. Lock on Facilities released.<BR>>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>>> confID =<BR>>>>> >> > 6,<BR>>>>> >> > srcCallID = 846, dstCallID = 845<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>>>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:<BR>>>>> >> > Old streamcallid=846, new streamcallid=846<BR>>>>> >> > *Oct 27
12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:<BR>>>>> >> > Setting SPI mode to SIP-H323<BR>>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =<BR>>>>> 1131891908<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:<BR>>>>> >> > sipSPIProcessRtpSessions<BR>>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:<BR>>>>> >> > Adding<BR>>>>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> >
//846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media<BR>>>>> >> > already<BR>>>>> >> > bound, use existing source_media_ip_addr<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:<BR>>>>> >> > Media src addr for stream 1 = 173.14.220.57<BR>>>>> >> > *Oct 27 12:34:10.844:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>>> >> > sipSPIUpdateRtcpSession for m-line 1<BR>>>>> >> > *Oct 27 12:34:10.848:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>>> >> > rtcp_session info<BR>>>>> >> > laddr = 173.14.220.57, lport = 16462, raddr =<BR>>>>>
64.154.41.101,<BR>>>>> >> > rport=45846, do_rtcp=TRUE<BR>>>>> >> > src_callid = 846, dest_callid = 845, stream type =<BR>>>>> voice+dtmf,<BR>>>>> >> > stream direction = SENDRECV<BR>>>>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0<BR>>>>> media_addr_type =<BR>>>>> >> > 1<BR>>>>> >> > *Oct 27 12:34:10.848:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:<BR>>>>> >> > RTP session already created - update<BR>>>>> >> > *Oct 27 12:34:10.848:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>>>> >> > stun is disabled for stream:4A1709F8<BR>>>>> >> > *Oct 27 12:34:10.848:<BR>>>>>
>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:<BR>>>>> >> > New Remote Media Direction = SENDRECV<BR>>>>> >> > Present Local Media Direction = SENDRECV<BR>>>>> >> > New Local Media Direction = SENDRECV<BR>>>>> >> > retVal = 0<BR>>>>> >> > *Oct 27 12:34:10.848:<BR>>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:<BR>>>>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to<BR>>>>> >> > (STREAM_ACTIVE)<BR>>>>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:<BR>>>>> really<BR>>>>> >> > can't<BR>>>>> >> > find peer_stream
for<BR>>>>> >> > dtmf-relay<BR>>>>> interworking<BR>>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Entry<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>>>> CURRENT<BR>>>>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>>>> >> > VALUES:<BR>>>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>>>> >> > *Oct 27
12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Load<BR>>>>> >> > DSP<BR>>>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Set<BR>>>>> >> > forking flag to 0x0<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx<BR>>>>> payload =<BR>>>>> >> > 100, tx payload = 100<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>>>> >> >
config=0<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Disabling Modem Relay...<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate<BR>>>>> SDP<BR>>>>> >> > Xcap<BR>>>>> >> > list<BR>>>>> >> > *Oct 27 12:34:11.140:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Modem<BR>>>>> >> > Relay & Passthru both disabled<BR>>>>> >> > *Oct 27 12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > nse<BR>>>>> >> > payload = 0, ptru
mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>>>> relay=0,<BR>>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>>>> >> > *Oct 27 12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > 1<BR>>>>> >> > Active Streams<BR>>>>> >> > *Oct 27 12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > Adding stream type (voice+dtmf) from media<BR>>>>> >> > line 1 codec g711ulaw<BR>>>>> >> > *Oct 27 12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>>>> >> > caps.stream_list.xmitFunc=<BR>>>>> >> > *Oct 27
12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>>>>> >> > *Oct 27 12:34:11.144:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > 0x497E0B60 (gccb)<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Load<BR>>>>> >> > DSP<BR>>>>> >> > with codec : g711ulaw, Bytes=160, payload = 0<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> No<BR>>>>> >> > video<BR>>>>> >> > caps
detected in the caps posted by peer leg<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> >> > Setting<BR>>>>> >> > CAPS_RECEIVED flag<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> >> > Calling<BR>>>>> >> > cc_api_caps_ack()<BR>>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack:<BR>>>>> Set<BR>>>>> >> > forking flag to 0x0<BR>>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Entry<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:<BR>>>>> CURRENT<BR>>>>> >> > VALUES:
stream_callid=846, current_seq_num=0x11D9<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW<BR>>>>> >> > VALUES:<BR>>>>> >> > stream_callid=846, current_seq_num=0x11D9<BR>>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Load<BR>>>>> >> > DSP<BR>>>>> >> > with negotiated codec: g711ulaw, Bytes=160<BR>>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Set<BR>>>>> >> > forking flag to 0x0<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:<BR>>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB
with rx<BR>>>>> payload =<BR>>>>> >> > 100, tx payload = 100<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI<BR>>>>> >> > config=0<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Disabling Modem Relay...<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate<BR>>>>> SDP<BR>>>>> >> > Xcap<BR>>>>> >> > list<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>>
//846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > Modem<BR>>>>> >> > Relay & Passthru both disabled<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:<BR>>>>> >> > nse<BR>>>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,<BR>>>>> relay=0,<BR>>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > 1<BR>>>>> >> > Active Streams<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > Adding stream type (voice+dtmf) from
media<BR>>>>> >> > line 1 codec g711ulaw<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,<BR>>>>> >> > caps.stream_list.xmitFunc=<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > voip_rtp_xmit, caps.stream_list.context=<BR>>>>> >> > *Oct 27 12:34:11.168:<BR>>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:<BR>>>>> >> > 0x497E0B60 (gccb)<BR>>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Load<BR>>>>> >> > DSP<BR>>>>> >> > with codec : g711ulaw, Bytes=160, payload =
0<BR>>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425<BR>>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> No<BR>>>>> >> > video<BR>>>>> >> > caps detected in the caps posted by peer leg<BR>>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:<BR>>>>> Second<BR>>>>> >> > TCS<BR>>>>> >> > received for transfers across trunk - set CAPS2_RECEIVED<BR>>>>> >> > *Oct 27 12:34:15.876:<BR>>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:<BR>>>>> >> > stun is disabled for stream:4A1709F8<BR>>>>> >> > *Oct 27
12:34:15.876:<BR>>>>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:<BR>>>>> >> > Stats are not supported for IPIP call.<BR>>>>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:<BR>>>>> >> > Queued<BR>>>>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> >> > ccsip_spi_get_msg_type returned: 3 for event 7<BR>>>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:<BR>>>>> >> > Associated container=0x4E310C1C to Cancel<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:<BR>>>>> >> > Sending
CANCEL to the transport layer<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>>>> >> > msg=0x4DF0D994,<BR>>>>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,<BR>>>>> transport=1,<BR>>>>> >> > switch=0, callBack=0x419703BC<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:<BR>>>>> Proceedable<BR>>>>> >> > for<BR>>>>> >> > sending msg immediately<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch<BR>>>>> >> > transport<BR>>>>> >> > is 0<BR>>>>> >>
> *Oct 27 12:34:15.880:<BR>>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to<BR>>>>> send<BR>>>>> >> > the<BR>>>>> >> > msg=0x4DF0D994<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:<BR>>>>> Posting<BR>>>>> >> > send<BR>>>>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:<BR>>>>> >> > Sent Cancel Request, starting CancelWaitResponseTimer<BR>>>>> >> > *Oct 27 12:34:15.880:<BR>>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:<BR>>>>> >> > 0x4A357FCC : State
change from (STATE_RECD_PROCEEDING,<BR>>>>> SUBSTATE_NONE)<BR>>>>> >> > to<BR>>>>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)<BR>>>>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> >> > Sent:<BR>>>>> >> > CANCEL sip:18774675464@64.154.41.200:5060 SIP/2.0<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net" ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > To:
<sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> ><BR>>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT<BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > CSeq: 102 CANCEL<BR>>>>> >> > Max-Forwards: 70<BR>>>>> >> > Timestamp: 1256646855<BR>>>>> >> > Reason: Q.850;cause=16<BR>>>>> >> > Content-Length: 0<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> >> >
ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> >> > context=0x00000000<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> >> > Checking Invite Dialog<BR>>>>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> >> > Received:<BR>>>>> >> > SIP/2.0 200 OK<BR>>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE<BR>>>>> >> > From: <sip:<A href="mailto:6782282221@sip.talkinip.net" ymailto="mailto:6782282221@sip.talkinip.net">6782282221@sip.talkinip.net</A><sip%<A href="mailto:3A6782282221@sip.talkinip.net"
ymailto="mailto:3A6782282221@sip.talkinip.net">3A6782282221@sip.talkinip.net</A>><BR>>>>> >;tag=2EDA9C8-25D6<BR>>>>> >> > To: <sip:18774675464@64.154.41.200<sip%3A18774675464@64.154.41.200><BR>>>>> ><BR>>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7@173.14.220.57<BR>>>>> >> > CSeq: 102 CANCEL<BR>>>>> >> > Content-Length: 0<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:<BR>>>>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX<BR>>>>> >> > *Oct 27 12:34:15.900:<BR>>>>> //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:<BR>>>>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0<BR>>>>> >> > *Oct 27 12:34:15.912:<BR>>>>>
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:<BR>>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060<BR>>>>> >> > *Oct 27 12:34:15.912:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:<BR>>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1<BR>>>>> >> > *Oct 27 12:34:15.912:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:<BR>>>>> >> > context=0x00000000<BR>>>>> >> > *Oct 27 12:34:15.912:<BR>>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:<BR>>>>> >> > Checking Invite Dialog<BR>>>>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:<BR>>>>> >> ><BR>>>>> >> >
On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <<BR>>>>> <A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>>>> >> > wrote:<BR>>>>> >> >><BR>>>>> >> >> You would want to check the SDP of 200 OK the provider sends for<BR>>>>> your<BR>>>>> >> >> outgoing call. It will list the payload type for the dtmf in the<BR>>>>> >> >> format a=fmtp 101 1-16, or something similar. You want to find<BR>>>>> out<BR>>>>> >> >> what payload type they are advertising (or if they are at all).<BR>>>>> It<BR>>>>> >> >> would be worth checking the incoming INVITE from them to see what<BR>>>>> >> >> they're using when they send the first SDP.<BR>>>>> >>
>><BR>>>>> >> >> On that note, I would also remove the asymmetric payload command -<BR>>>>> to<BR>>>>> >> >> my knowledge it doesn't do what you're expecting it to. You may<BR>>>>> want<BR>>>>> >> >> to try this command:<BR>>>>> >> >> voice-class sip dtmf-relay force rtp-nte<BR>>>>> >> >><BR>>>>> >> >><BR>>>>> >> >> -nick<BR>>>>> >> >><BR>>>>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <<BR>>>>> <A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>>>> >> >> wrote:<BR>>>>> >> >> > Hello,<BR>>>>> >> >> ><BR>>>>> >> >> > I am
having an issue with dtmf working outbound. Inbound dtmf<BR>>>>> works<BR>>>>> >> >> > fine.<BR>>>>> >> >> > It took some playing around with it. At first it didnt work<BR>>>>> till the<BR>>>>> >> >> > payload was ajusted. I am now trying to get outbound dtmf<BR>>>>> working<BR>>>>> >> >> > properly.<BR>>>>> >> >> ><BR>>>>> >> >> > On my 2821 I debugged voip rtp session named-events and then<BR>>>>> made a<BR>>>>> >> >> > call<BR>>>>> >> >> > to<BR>>>>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on<BR>>>>> the<BR>>>>> >> >> > router<BR>>>>> >> >> >
nothing showed up in the debug. Does this mean I can safely<BR>>>>> asume<BR>>>>> >> >> > that<BR>>>>> >> >> > the<BR>>>>> >> >> > problem for right now is not on the ITSP side but on my side<BR>>>>> since<BR>>>>> >> >> > dtmf<BR>>>>> >> >> > is<BR>>>>> >> >> > not being sent down the sip trunk?<BR>>>>> >> >> ><BR>>>>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The<BR>>>>> >> >> > configuration<BR>>>>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas<BR>>>>> what I<BR>>>>> >> >> > can<BR>>>>> >> >> > do<BR>>>>> >> >>
> so dtmf digits process properly outbound?<BR>>>>> >> >> ><BR>>>>> >> >> > The settings in my cuc 7.x to add the gateway h323 are<BR>>>>> >> >> ><BR>>>>> >> >> > h323 cucm gateway configuratration<BR>>>>> >> >> > Signaling Port 1720<BR>>>>> >> >> > media termination point required yes<BR>>>>> >> >> > retry video call as auto yes<BR>>>>> >> >> > wait for far end h.245 terminal capability set yes<BR>>>>> >> >> > transmit utf-8 calling party name no<BR>>>>> >> >> > h.235 pass through allowed no<BR>>>>> >> >> > significant digits all<BR>>>>> >> >> > redirect number IT deliver - inbound no<BR>>>>> >> >> >
enable inbound faststart yes<BR>>>>> >> >> > display IE deliver no<BR>>>>> >> >> > redirect nunmber IT deliver - outbound no<BR>>>>> >> >> > enable outbound faststart yes<BR>>>>> >> >> ><BR>>>>> >> >> ><BR>>>>> >> >> > voice service voip<BR>>>>> >> >> > allow-connections h323 to h323<BR>>>>> >> >> > allow-connections h323 to sip<BR>>>>> >> >> > allow-connections sip to h323<BR>>>>> >> >> > allow-connections sip to sip<BR>>>>> >> >> > fax protocol pass-through g711ulaw<BR>>>>> >> >> > h323<BR>>>>> >> >> > emptycapability<BR>>>>> >> >> >
h225 id-passthru<BR>>>>> >> >> > h245 passthru tcsnonstd-passthru<BR>>>>> >> >> > sip<BR>>>>> >> >> ><BR>>>>> >> >> ><BR>>>>> >> >> > voice class h323 50<BR>>>>> >> >> > h225 timeout tcp establish 3<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > voice translation-rule 1<BR>>>>>
>> >> > rule 1 /.*/ /190/<BR>>>>> >> >> > !<BR>>>>> >> >> > voice translation-rule 2<BR>>>>> >> >> > rule 1 /.*/ /1&/<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > voice translation-profile aa<BR>>>>> >> >> > translate called 1<BR>>>>> >> >> > !<BR>>>>> >> >> > voice translation-profile addone<BR>>>>> >> >> > translate called 2<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > voice-card 0<BR>>>>> >> >> > dspfarm<BR>>>>> >> >> > dsp services dspfarm<BR>>>>> >> >> >
!<BR>>>>> >> >> > !<BR>>>>> >> >> > sccp local GigabitEthernet0/1<BR>>>>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0<BR>>>>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0<BR>>>>> >> >> > sccp<BR>>>>> >> >> > !<BR>>>>> >> >> > sccp ccm group 1<BR>>>>> >> >> > associate ccm 1 priority 1<BR>>>>> >> >> > associate ccm 2 priority 2<BR>>>>> >> >> > associate profile 1 register 2821transcode<BR>>>>> >> >> > !<BR>>>>> >> >> > dspfarm profile 1 transcode<BR>>>>> >> >> > codec g711ulaw<BR>>>>> >> >> > codec g711alaw<BR>>>>> >>
>> > codec g729ar8<BR>>>>> >> >> > codec g729abr8<BR>>>>> >> >> > codec g729r8<BR>>>>> >> >> > maximum sessions 4<BR>>>>> >> >> > associate application SCCP<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > dial-peer voice 100 voip<BR>>>>> >> >> > description AA Publisher<BR>>>>> >> >> > preference 1<BR>>>>> >> >> > destination-pattern 1..<BR>>>>> >> >> > voice-class h323 50<BR>>>>> >> >> > session target ipv4:10.1.80.10<BR>>>>> >> >> > dtmf-relay h245-alphanumeric<BR>>>>> >> >> > codec
g711ulaw<BR>>>>> >> >> > no vad<BR>>>>> >> >> > !<BR>>>>> >> >> > dial-peer voice 1000 voip<BR>>>>> >> >> > description incoming Call<BR>>>>> >> >> > translation-profile incoming aa<BR>>>>> >> >> > preference 1<BR>>>>> >> >> > rtp payload-type nse 101<BR>>>>> >> >> > rtp payload-type nte 100<BR>>>>> >> >> > incoming called-number 6782282221<BR>>>>> >> >> > dtmf-relay rtp-nte<BR>>>>> >> >> > codec g711ulaw<BR>>>>> >> >> > ip qos dscp cs5 media<BR>>>>> >> >> > ip qos dscp cs5 signaling<BR>>>>> >> >> > no
vad<BR>>>>> >> >> > !<BR>>>>> >> >> > dial-peer voice 101 voip<BR>>>>> >> >> > description AA Subscriber<BR>>>>> >> >> > preference 2<BR>>>>> >> >> > destination-pattern 1..<BR>>>>> >> >> > voice-class h323 50<BR>>>>> >> >> > session target ipv4:10.1.80.11<BR>>>>> >> >> > dtmf-relay h245-alphanumeric<BR>>>>> >> >> > codec g711ulaw<BR>>>>> >> >> > no vad<BR>>>>> >> >> > !<BR>>>>> >> >> > dial-peer voice 2000 voip<BR>>>>> >> >> > description outbound<BR>>>>> >> >> > translation-profile outgoing addone<BR>>>>>
>> >> > preference 1<BR>>>>> >> >> > destination-pattern .T<BR>>>>> >> >> > rtp payload-type nse 101<BR>>>>> >> >> > rtp payload-type nte 100<BR>>>>> >> >> > voice-class sip asymmetric payload dtmf<BR>>>>> >> >> > session protocol sipv2<BR>>>>> >> >> > session target ipv4:64.154.41.200<BR>>>>> >> >> > dtmf-relay rtp-nte<BR>>>>> >> >> > codec g711ulaw<BR>>>>> >> >> > no vad<BR>>>>> >> >> > !<BR>>>>> >> >> > !<BR>>>>> >> >> > sip-ua<BR>>>>> >> >> > credentials username ***** password 7 ***** realm<BR>>>>>
sip.talkinip.net<BR>>>>> >> >> > authentication username ***** password 7 *****<BR>>>>> >> >> > authentication username ***** password 7 ***** realm<BR>>>>> >> >> > sip.talkinip.net<BR>>>>> >> >> > set pstn-cause 3 sip-status 486<BR>>>>> >> >> > set pstn-cause 34 sip-status 486<BR>>>>> >> >> > set pstn-cause 47 sip-status 486<BR>>>>> >> >> > registrar dns:sip.talkinip.net expires 60<BR>>>>> >> >> > sip-server dns:sip.talkinip.net:5060<BR>>>>> >> >> > _______________________________________________<BR>>>>> >> >> > cisco-voip mailing list<BR>>>>> >> >> > <A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>>> >> >> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>>>> >> >> ><BR>>>>> >> >> ><BR>>>>> >> ><BR>>>>> >> ><BR>>>>> ><BR>>>>> > _______________________________________________<BR>>>>> > cisco-voip mailing list<BR>>>>> > <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>>> > <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>>>> ><BR>>>>>
><BR>>>>><BR>>>><BR>>>><BR>>>> _______________________________________________<BR>>>> cisco-voip mailing list<BR>>>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>>>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>>>><BR>>>><BR>>><BR>>><BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/2b6ae4ba/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/2b6ae4ba/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 26<BR>Date: Tue, 27 Oct 2009 14:24:53 -0700<BR>From: Scott Voll <<A
href="mailto:svoll.voip@gmail.com" ymailto="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</A>><BR>To: "Joe Pollere (US)" <<A href="mailto:Joe.Pollere@us.didata.com" ymailto="mailto:Joe.Pollere@us.didata.com">Joe.Pollere@us.didata.com</A>><BR>Cc: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: [cisco-voip] answer: Re: What am I missing with Background<BR> images?<BR>Message-ID:<BR> <<A href="mailto:f84a38d30910271424k22e8c102ne7890347569c2951@mail.gmail.com" ymailto="mailto:f84a38d30910271424k22e8c102ne7890347569c2951@mail.gmail.com">f84a38d30910271424k22e8c102ne7890347569c2951@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>it's all depended on phone model.<BR><BR>7941 goes into the x4 directory and the 7965 goes into the x12 directory.<BR><BR>just my lack of understanding. Thanks
for the help.<BR><BR>Scott<BR><BR>On Tue, Oct 27, 2009 at 12:38 PM, Joe Pollere (US) <<BR><A href="mailto:Joe.Pollere@us.didata.com" ymailto="mailto:Joe.Pollere@us.didata.com">Joe.Pollere@us.didata.com</A>> wrote:<BR><BR>> It is case sensitive. list.xml should be List.xml<BR>><BR>><BR>><BR>> *From:* <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [mailto:<BR>> <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] *On Behalf Of *Scott Voll<BR>> *Sent:* Tuesday, October 27, 2009 3:35 PM<BR>> *To:* <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> *Subject:* [cisco-voip] What am I missing with Background images?<BR>><BR>><BR>><BR>> I have uploaded both
the thumb nail and full png file for the image I want<BR>> to use for a background. (both to the Desktops/320x196x4/ directory)<BR>><BR>><BR>><BR>> I have also added the list.xml file to both the root and the<BR>> Desktops/320x196x4/ and restarted both phone and TFTP server without being<BR>> able to get it to work. What am I missing?<BR>><BR>><BR>><BR>> Scott<BR>><BR>> ------------------------------<BR>><BR>> * Disclaimer: This e-mail communication and any attachments may contain<BR>> confidential and privileged information and is for use by the designated<BR>> addressee(s) named above only. If you are not the intended addressee, you<BR>> are hereby notified that you have received this communication in error and<BR>> that any use or reproduction of this email or its contents is strictly<BR>> prohibited and may be unlawful. If you have received this communication in<BR>> error, please
notify us immediately by replying to this message and deleting<BR>> it from your computer. Thank you. *<BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/fc94ba0f/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/fc94ba0f/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 27<BR>Date: Tue, 27 Oct 2009 17:46:45 -0500<BR>From: "Philip Walenta" <<A href="mailto:pwalenta@wi.rr.com" ymailto="mailto:pwalenta@wi.rr.com">pwalenta@wi.rr.com</A>><BR>To: <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] SIP phones and caller ID<BR>Message-ID: <01e001ca5757$5cf371f0$16da55d0$@rr.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Has
anyone who is using SIP phones ever seen it where instead of the caller<BR>id you get an IP address sent instead?<BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c8a94cd2/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c8a94cd2/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 28<BR>Date: Tue, 27 Oct 2009 19:23:06 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip]
dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271623m5dd6c4d8md557649bffb5dc@mail.gmail.com" ymailto="mailto:a54820e50910271623m5dd6c4d8md557649bffb5dc@mail.gmail.com">a54820e50910271623m5dd6c4d8md557649bffb5dc@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>Thanks for the reply Nick<BR><BR>I debugged voip rtp named-event and when I tried to hit 1 in the call for<BR>dtmf nothing came out of the debug. Could this possibly mean on my side Im<BR>not sending dtmf to the service provider?<BR><BR>Dane<BR><BR>On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR><BR>> That shows up in the debugs in working scenarios too. Not sure what<BR>> the importance of those statements are, but it's the type of thing you<BR>> see when you add 'all'
to a debug.<BR>><BR>> It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>> your INVITE. And you want a 200 OK. I've seen it where the debugs<BR>> will show that we're sending DTMF but the provider won't use it, which<BR>> is a conversation you would need to have with the provider.<BR>><BR>> -nick<BR>><BR>> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> wrote:<BR>> > Hmm that does not sound good<BR>> ><BR>> > This is with the default settings<BR>> ><BR>> > rtp payload-type nte 101<BR>> > rtp payload-type nse 100<BR>> ><BR>> > which don't show up in the config. Could there be any reason why the<BR>> router<BR>> > is not able to use 101 below are my dial peers<BR>> ><BR>> > dial-peer voice 100 voip<BR>>
> description AA Publisher<BR>> > preference 1<BR>> > destination-pattern 1..<BR>> > voice-class h323 50<BR>> > session target ipv4:10.1.80.10<BR>> > dtmf-relay h245-alphanumeric<BR>> > codec g711ulaw<BR>> > no vad<BR>> > !<BR>> > dial-peer voice 1000 voip<BR>> > description incoming Call<BR>> > translation-profile incoming aa<BR>> > preference 1<BR>> ><BR>> > incoming called-number 6784442454<BR>> ><BR>> > dtmf-relay rtp-nte<BR>> > codec g711ulaw<BR>> > ip qos dscp cs5 media<BR>> > ip qos dscp cs5 signaling<BR>> > no vad<BR>> > !<BR>> > dial-peer voice 101 voip<BR>> > description AA Subscriber<BR>> > preference 2<BR>> > destination-pattern 1..<BR>> > voice-class h323
50<BR>> > session target ipv4:10.1.80.11<BR>> > dtmf-relay h245-alphanumeric<BR>> > codec g711ulaw<BR>> > no vad<BR>> > !<BR>> > dial-peer voice 2000 voip<BR>> > description outbound<BR>> > translation-profile outgoing addone<BR>> > preference 1<BR>> > destination-pattern .T<BR>> ><BR>> > progress_ind setup enable 3<BR>> > progress_ind progress enable 8<BR>> > session protocol sipv2<BR>> > session target dns:did.voip.les.net<BR>> ><BR>> > dtmf-relay rtp-nte<BR>> > codec g711ulaw<BR>> ><BR>> > !<BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c1726f17/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c1726f17/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 29<BR>Date: Tue, 27 Oct 2009 20:14:58 -0400<BR>From: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:56c3b48b0910271714q68993636p4b157c41f3879d4b@mail.gmail.com"
ymailto="mailto:56c3b48b0910271714q68993636p4b157c41f3879d4b@mail.gmail.com">56c3b48b0910271714q68993636p4b157c41f3879d4b@mail.gmail.com</A>><BR>Content-Type: text/plain; charset=ISO-8859-1<BR><BR>Yes, as long as your debugs are setup correctly (they show output).<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>> wrote:<BR>> Thanks for the reply Nick<BR>><BR>> I debugged voip rtp named-event and when I tried to hit 1 in the call for<BR>> dtmf nothing came out of the debug.? Could this possibly mean on my side Im<BR>> not sending dtmf to the service provider?<BR>> Dane<BR>><BR>> On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> That shows up in the debugs in working
scenarios too. ?Not sure what<BR>>> the importance of those statements are, but it's the type of thing you<BR>>> see when you add 'all' to a debug.<BR>>><BR>>> It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>>> your INVITE. ?And you want a 200 OK. ?I've seen it where the debugs<BR>>> will show that we're sending DTMF but the provider won't use it, which<BR>>> is a conversation you would need to have with the provider.<BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Hmm that does not sound good<BR>>> ><BR>>> > This is with the default settings<BR>>> ><BR>>> > rtp payload-type nte 101<BR>>> > rtp payload-type nse 100<BR>>> ><BR>>> >
which don't show up in the config.? Could there be any reason why the<BR>>> > router<BR>>> > is not able to use 101 below are my dial peers<BR>>> ><BR>>> > dial-peer voice 100 voip<BR>>> > ?description AA Publisher<BR>>> > ?preference 1<BR>>> > ?destination-pattern 1..<BR>>> > ?voice-class h323 50<BR>>> > ?session target ipv4:10.1.80.10<BR>>> > ?dtmf-relay h245-alphanumeric<BR>>> > ?codec g711ulaw<BR>>> > ?no vad<BR>>> > !<BR>>> > dial-peer voice 1000 voip<BR>>> > ?description incoming Call<BR>>> > ?translation-profile incoming aa<BR>>> > ?preference 1<BR>>> ><BR>>> > ?incoming called-number 6784442454<BR>>> ><BR>>> > ?dtmf-relay rtp-nte<BR>>> > ?codec g711ulaw<BR>>> > ?ip qos dscp cs5 media<BR>>> > ?ip qos dscp cs5 signaling<BR>>>
> ?no vad<BR>>> > !<BR>>> > dial-peer voice 101 voip<BR>>> > ?description AA Subscriber<BR>>> > ?preference 2<BR>>> > ?destination-pattern 1..<BR>>> > ?voice-class h323 50<BR>>> > ?session target ipv4:10.1.80.11<BR>>> > ?dtmf-relay h245-alphanumeric<BR>>> > ?codec g711ulaw<BR>>> > ?no vad<BR>>> > !<BR>>> > dial-peer voice 2000 voip<BR>>> > ?description outbound<BR>>> > ?translation-profile outgoing addone<BR>>> > ?preference 1<BR>>> > ?destination-pattern .T<BR>>> ><BR>>> > ?progress_ind setup enable 3<BR>>> > ?progress_ind progress enable 8<BR>>> > ?session protocol sipv2<BR>>> > ?session target dns:did.voip.les.net<BR>>> ><BR>>> > ?dtmf-relay rtp-nte<BR>>> > ?codec g711ulaw<BR>>> ><BR>>> >
!<BR>><BR>><BR><BR><BR>------------------------------<BR><BR>Message: 30<BR>Date: Tue, 27 Oct 2009 20:17:41 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271717p382ed08bs2a7f1f72e5237173@mail.gmail.com" ymailto="mailto:a54820e50910271717p382ed08bs2a7f1f72e5237173@mail.gmail.com">a54820e50910271717p382ed08bs2a7f1f72e5237173@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>I have a cisco 7975 phone connected to a cucm 7.x
--> h323 gateway cisco<BR>2821 --> ITSP sip trunk<BR><BR>I am using the CUBE feature on the gateway...DTMF works calling internally<BR>to my cisco unity connection voice mail so it is able to be sent.<BR><BR>Does anyone have any ideas how I could go about troubleshooting this?<BR><BR>Dane<BR><BR>On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR><BR>> Yes, as long as your debugs are setup correctly (they show output).<BR>><BR>> -nick<BR>><BR>> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> wrote:<BR>> > Thanks for the reply Nick<BR>> ><BR>> > I debugged voip rtp named-event and when I tried to hit 1 in the call for<BR>> > dtmf nothing came out of the debug. Could this possibly
mean on my side<BR>> Im<BR>> > not sending dtmf to the service provider?<BR>> > Dane<BR>> ><BR>> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>> wrote:<BR>> >><BR>> >> That shows up in the debugs in working scenarios too. Not sure what<BR>> >> the importance of those statements are, but it's the type of thing you<BR>> >> see when you add 'all' to a debug.<BR>> >><BR>> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>> >> your INVITE. And you want a 200 OK. I've seen it where the debugs<BR>> >> will show that we're sending DTMF but the provider won't use it, which<BR>> >> is a conversation you would need to have with the provider.<BR>> >><BR>> >> -nick<BR>>
>><BR>> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> >> wrote:<BR>> >> > Hmm that does not sound good<BR>> >> ><BR>> >> > This is with the default settings<BR>> >> ><BR>> >> > rtp payload-type nte 101<BR>> >> > rtp payload-type nse 100<BR>> >> ><BR>> >> > which don't show up in the config. Could there be any reason why the<BR>> >> > router<BR>> >> > is not able to use 101 below are my dial peers<BR>> >> ><BR>> >> > dial-peer voice 100 voip<BR>> >> > description AA Publisher<BR>> >> > preference 1<BR>> >> > destination-pattern 1..<BR>> >> > voice-class h323 50<BR>> >> > session
target ipv4:10.1.80.10<BR>> >> > dtmf-relay h245-alphanumeric<BR>> >> > codec g711ulaw<BR>> >> > no vad<BR>> >> > !<BR>> >> > dial-peer voice 1000 voip<BR>> >> > description incoming Call<BR>> >> > translation-profile incoming aa<BR>> >> > preference 1<BR>> >> ><BR>> >> > incoming called-number 6784442454<BR>> >> ><BR>> >> > dtmf-relay rtp-nte<BR>> >> > codec g711ulaw<BR>> >> > ip qos dscp cs5 media<BR>> >> > ip qos dscp cs5 signaling<BR>> >> > no vad<BR>> >> > !<BR>> >> > dial-peer voice 101 voip<BR>> >> > description AA Subscriber<BR>> >> > preference 2<BR>> >> > destination-pattern 1..<BR>> >> >
voice-class h323 50<BR>> >> > session target ipv4:10.1.80.11<BR>> >> > dtmf-relay h245-alphanumeric<BR>> >> > codec g711ulaw<BR>> >> > no vad<BR>> >> > !<BR>> >> > dial-peer voice 2000 voip<BR>> >> > description outbound<BR>> >> > translation-profile outgoing addone<BR>> >> > preference 1<BR>> >> > destination-pattern .T<BR>> >> ><BR>> >> > progress_ind setup enable 3<BR>> >> > progress_ind progress enable 8<BR>> >> > session protocol sipv2<BR>> >> > session target dns:did.voip.les.net<BR>> >> ><BR>> >> > dtmf-relay rtp-nte<BR>> >> > codec g711ulaw<BR>> >> ><BR>> >> > !<BR>> ><BR>> ><BR>><BR>-------------- next part
--------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/006c32d3/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/006c32d3/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 31<BR>Date: Tue, 27 Oct 2009 20:49:12 -0400<BR>From: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>To: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A
href="mailto:56c3b48b0910271749i1e8ea360gf7202f1f084ba785@mail.gmail.com" ymailto="mailto:56c3b48b0910271749i1e8ea360gf7202f1f084ba785@mail.gmail.com">56c3b48b0910271749i1e8ea360gf7202f1f084ba785@mail.gmail.com</A>><BR>Content-Type: text/plain; charset=ISO-8859-1<BR><BR>So you have a H323-SIP CUBE, and your DTMF isn't working. This is<BR>probably the most common problem with CUBE users.<BR><BR>For this #1 problem, the number one cause is 'incoming called-number .'<BR><BR>Most people don't really understand inbound dial peer matching, and<BR>have used this for ages on normal TDM gateways that were<BR>single-protocol. The best way to fix this is to read the 'Understand<BR>Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring<BR>out the best way to match dial peers for both your incoming/outgoing<BR>SIP/H323 legs. You can prefix digits and match on incoming called<BR>number, or ditch incoming called-numbers completely
and use<BR>answer-address.<BR><BR>I like using 'debug voip ccapi inout' to determine this. You can do a<BR>search for peer= after you've got the debug to find out which dial<BR>peers you're hitting for each case, plus what the numbers look like<BR>after translations, etc. 'debug voip dialpeer' is an alternative, but<BR>I personally find it more confusing.<BR><BR>For h323-SIP your dial peers should look something like this:<BR><BR>incoming h323 dial peer for outgoing call: dtmf-relay h245-alpha or h245-signal<BR>outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte<BR>digit-drop (plus any payload commands required)<BR>incoming sip dial peer for incoming call: same as sip option above<BR>outgoing h323 dial peer for incoming call: same as h323 option above<BR><BR>My best guess is that if you look at your incoming/outgoing dial peers<BR>something isn't matched correctly.<BR><BR>-nick<BR><BR>On Tue, Oct 27, 2009 at 8:17 PM, Dane
Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>> wrote:<BR>> I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco<BR>> 2821 --> ITSP sip trunk<BR>><BR>> I am using the CUBE feature on the gateway...DTMF works calling internally<BR>> to my cisco unity connection voice mail so it is able to be sent.<BR>><BR>> Does anyone have any ideas how I could go about troubleshooting this?<BR>><BR>> Dane<BR>><BR>> On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR>>><BR>>> Yes, as long as your debugs are setup correctly (they show output).<BR>>><BR>>> -nick<BR>>><BR>>> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com"
ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> wrote:<BR>>> > Thanks for the reply Nick<BR>>> ><BR>>> > I debugged voip rtp named-event and when I tried to hit 1 in the call<BR>>> > for<BR>>> > dtmf nothing came out of the debug.? Could this possibly mean on my side<BR>>> > Im<BR>>> > not sending dtmf to the service provider?<BR>>> > Dane<BR>>> ><BR>>> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>>> > wrote:<BR>>> >><BR>>> >> That shows up in the debugs in working scenarios too. ?Not sure what<BR>>> >> the importance of those statements are, but it's the type of thing you<BR>>> >> see when you add 'all' to a debug.<BR>>> >><BR>>> >> It's not
the 183 you want to look at, but the 200 OK with the CSeq of<BR>>> >> your INVITE. ?And you want a 200 OK. ?I've seen it where the debugs<BR>>> >> will show that we're sending DTMF but the provider won't use it, which<BR>>> >> is a conversation you would need to have with the provider.<BR>>> >><BR>>> >> -nick<BR>>> >><BR>>> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>>> >> wrote:<BR>>> >> > Hmm that does not sound good<BR>>> >> ><BR>>> >> > This is with the default settings<BR>>> >> ><BR>>> >> > rtp payload-type nte 101<BR>>> >> > rtp payload-type nse 100<BR>>> >> ><BR>>> >> > which don't show up in the config.? Could there
be any reason why the<BR>>> >> > router<BR>>> >> > is not able to use 101 below are my dial peers<BR>>> >> ><BR>>> >> > dial-peer voice 100 voip<BR>>> >> > ?description AA Publisher<BR>>> >> > ?preference 1<BR>>> >> > ?destination-pattern 1..<BR>>> >> > ?voice-class h323 50<BR>>> >> > ?session target ipv4:10.1.80.10<BR>>> >> > ?dtmf-relay h245-alphanumeric<BR>>> >> > ?codec g711ulaw<BR>>> >> > ?no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 1000 voip<BR>>> >> > ?description incoming Call<BR>>> >> > ?translation-profile incoming aa<BR>>> >> > ?preference 1<BR>>> >> ><BR>>> >> > ?incoming called-number 6784442454<BR>>> >> ><BR>>> >> > ?dtmf-relay
rtp-nte<BR>>> >> > ?codec g711ulaw<BR>>> >> > ?ip qos dscp cs5 media<BR>>> >> > ?ip qos dscp cs5 signaling<BR>>> >> > ?no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 101 voip<BR>>> >> > ?description AA Subscriber<BR>>> >> > ?preference 2<BR>>> >> > ?destination-pattern 1..<BR>>> >> > ?voice-class h323 50<BR>>> >> > ?session target ipv4:10.1.80.11<BR>>> >> > ?dtmf-relay h245-alphanumeric<BR>>> >> > ?codec g711ulaw<BR>>> >> > ?no vad<BR>>> >> > !<BR>>> >> > dial-peer voice 2000 voip<BR>>> >> > ?description outbound<BR>>> >> > ?translation-profile outgoing addone<BR>>> >> > ?preference 1<BR>>> >> > ?destination-pattern .T<BR>>> >> ><BR>>>
>> > ?progress_ind setup enable 3<BR>>> >> > ?progress_ind progress enable 8<BR>>> >> > ?session protocol sipv2<BR>>> >> > ?session target dns:did.voip.les.net<BR>>> >> ><BR>>> >> > ?dtmf-relay rtp-nte<BR>>> >> > ?codec g711ulaw<BR>>> >> ><BR>>> >> > !<BR>>> ><BR>>> ><BR>><BR>><BR><BR><BR>------------------------------<BR><BR>Message: 32<BR>Date: Tue, 27 Oct 2009 21:34:44 -0400<BR>From: Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>To: Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>Cc: cisco-voip <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip]
dtmf from cucm to 2821 cube to sip trunk<BR>Message-ID:<BR> <<A href="mailto:a54820e50910271834q5021c6a4raa7bd9eb003cf1b5@mail.gmail.com" ymailto="mailto:a54820e50910271834q5021c6a4raa7bd9eb003cf1b5@mail.gmail.com">a54820e50910271834q5021c6a4raa7bd9eb003cf1b5@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="iso-8859-1"<BR><BR>I feel embarasssed I been blaming a telco all day when it was my own<BR>ignorance that made it not work<BR><BR>I was not matching the inbound dialpeer for my outbound calling.<BR><BR>I added the following dial peer and the problem was solved<BR><BR>dial-peer voice 150 voip<BR>description incoming outbound<BR>preference 1<BR>voice-class h323 50<BR>incoming called-number .T<BR>dtmf-relay h245-alphanumeric<BR>codec g711ulaw<BR>no vad<BR>!<BR><BR><BR>Thanks alot Nick and Ryan for all your help on this!<BR><BR>Dane<BR><BR><BR><BR>On Tue, Oct 27, 2009 at 8:49 PM, Nick Matthews <<A
href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>> wrote:<BR><BR>> So you have a H323-SIP CUBE, and your DTMF isn't working. This is<BR>> probably the most common problem with CUBE users.<BR>><BR>> For this #1 problem, the number one cause is 'incoming called-number .'<BR>><BR>> Most people don't really understand inbound dial peer matching, and<BR>> have used this for ages on normal TDM gateways that were<BR>> single-protocol. The best way to fix this is to read the 'Understand<BR>> Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring<BR>> out the best way to match dial peers for both your incoming/outgoing<BR>> SIP/H323 legs. You can prefix digits and match on incoming called<BR>> number, or ditch incoming called-numbers completely and use<BR>> answer-address.<BR>><BR>> I like using 'debug voip ccapi inout' to determine
this. You can do a<BR>> search for peer= after you've got the debug to find out which dial<BR>> peers you're hitting for each case, plus what the numbers look like<BR>> after translations, etc. 'debug voip dialpeer' is an alternative, but<BR>> I personally find it more confusing.<BR>><BR>> For h323-SIP your dial peers should look something like this:<BR>><BR>> incoming h323 dial peer for outgoing call: dtmf-relay h245-alpha or<BR>> h245-signal<BR>> outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte<BR>> digit-drop (plus any payload commands required)<BR>> incoming sip dial peer for incoming call: same as sip option above<BR>> outgoing h323 dial peer for incoming call: same as h323 option above<BR>><BR>> My best guess is that if you look at your incoming/outgoing dial peers<BR>> something isn't matched correctly.<BR>><BR>> -nick<BR>><BR>> On Tue, Oct 27, 2009 at 8:17
PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> wrote:<BR>> > I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco<BR>> > 2821 --> ITSP sip trunk<BR>> ><BR>> > I am using the CUBE feature on the gateway...DTMF works calling<BR>> internally<BR>> > to my cisco unity connection voice mail so it is able to be sent.<BR>> ><BR>> > Does anyone have any ideas how I could go about troubleshooting this?<BR>> ><BR>> > Dane<BR>> ><BR>> > On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>> wrote:<BR>> >><BR>> >> Yes, as long as your debugs are setup correctly (they show output).<BR>> >><BR>> >> -nick<BR>> >><BR>> >> On Tue,
Oct 27, 2009 at 7:23 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> >> wrote:<BR>> >> > Thanks for the reply Nick<BR>> >> ><BR>> >> > I debugged voip rtp named-event and when I tried to hit 1 in the call<BR>> >> > for<BR>> >> > dtmf nothing came out of the debug. Could this possibly mean on my<BR>> side<BR>> >> > Im<BR>> >> > not sending dtmf to the service provider?<BR>> >> > Dane<BR>> >> ><BR>> >> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <<A href="mailto:matthnick@gmail.com" ymailto="mailto:matthnick@gmail.com">matthnick@gmail.com</A>><BR>> >> > wrote:<BR>> >> >><BR>> >> >> That shows up in the debugs in working scenarios too. Not sure what<BR>> >> >> the
importance of those statements are, but it's the type of thing<BR>> you<BR>> >> >> see when you add 'all' to a debug.<BR>> >> >><BR>> >> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of<BR>> >> >> your INVITE. And you want a 200 OK. I've seen it where the debugs<BR>> >> >> will show that we're sending DTMF but the provider won't use it,<BR>> which<BR>> >> >> is a conversation you would need to have with the provider.<BR>> >> >><BR>> >> >> -nick<BR>> >> >><BR>> >> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <<A href="mailto:dane.newman@gmail.com" ymailto="mailto:dane.newman@gmail.com">dane.newman@gmail.com</A>><BR>> >> >> wrote:<BR>> >> >> > Hmm that does not sound good<BR>> >> >> ><BR>> >>
>> > This is with the default settings<BR>> >> >> ><BR>> >> >> > rtp payload-type nte 101<BR>> >> >> > rtp payload-type nse 100<BR>> >> >> ><BR>> >> >> > which don't show up in the config. Could there be any reason why<BR>> the<BR>> >> >> > router<BR>> >> >> > is not able to use 101 below are my dial peers<BR>> >> >> ><BR>> >> >> > dial-peer voice 100 voip<BR>> >> >> > description AA Publisher<BR>> >> >> > preference 1<BR>> >> >> > destination-pattern 1..<BR>> >> >> > voice-class h323 50<BR>> >> >> > session target ipv4:10.1.80.10<BR>> >> >> > dtmf-relay h245-alphanumeric<BR>> >> >> > codec g711ulaw<BR>>
>> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer voice 1000 voip<BR>> >> >> > description incoming Call<BR>> >> >> > translation-profile incoming aa<BR>> >> >> > preference 1<BR>> >> >> ><BR>> >> >> > incoming called-number 6784442454<BR>> >> >> ><BR>> >> >> > dtmf-relay rtp-nte<BR>> >> >> > codec g711ulaw<BR>> >> >> > ip qos dscp cs5 media<BR>> >> >> > ip qos dscp cs5 signaling<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer voice 101 voip<BR>> >> >> > description AA Subscriber<BR>> >> >> > preference 2<BR>> >> >> >
destination-pattern 1..<BR>> >> >> > voice-class h323 50<BR>> >> >> > session target ipv4:10.1.80.11<BR>> >> >> > dtmf-relay h245-alphanumeric<BR>> >> >> > codec g711ulaw<BR>> >> >> > no vad<BR>> >> >> > !<BR>> >> >> > dial-peer voice 2000 voip<BR>> >> >> > description outbound<BR>> >> >> > translation-profile outgoing addone<BR>> >> >> > preference 1<BR>> >> >> > destination-pattern .T<BR>> >> >> ><BR>> >> >> > progress_ind setup enable 3<BR>> >> >> > progress_ind progress enable 8<BR>> >> >> > session protocol sipv2<BR>> >> >> > session target dns:did.voip.les.net<BR>> >> >>
><BR>> >> >> > dtmf-relay rtp-nte<BR>> >> >> > codec g711ulaw<BR>> >> >> ><BR>> >> >> > !<BR>> >> ><BR>> >> ><BR>> ><BR>> ><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/aee9cc8d/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/aee9cc8d/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 33<BR>Date: Wed, 28 Oct 2009 21:04:24 +1100<BR>From: "Dana Tong (AU)" <<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><BR>To: "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>" <<A
href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR>Message-ID:<BR> <<A href="mailto:B9B345954EE2444284E3DC802DF6333A5D24E9537C@AUNDDEXMBS01.au.didata.local" ymailto="mailto:B9B345954EE2444284E3DC802DF6333A5D24E9537C@AUNDDEXMBS01.au.didata.local">B9B345954EE2444284E3DC802DF6333A5D24E9537C@AUNDDEXMBS01.au.didata.local</A>><BR> <BR>Content-Type: text/plain; charset="windows-1252"<BR><BR>Hey guys,<BR><BR>I've upgraded CUCM to 7.1(3) and CUPS to 7.0(5) but the customer still cannot get deskphone control.<BR>I think it might be something to do with his PC and the software he's running or has run in the past. (I found once that if you were running a CTI application [ie Cisco Attendant Console] that deskphone control would stop. I think the customer has an install of Zeacomm Qmaster installed
so that might be stopping it.<BR><BR>He is able to login and become "available" but no deskphone control.<BR><BR>My PC is not part of the domain and I can get deskphone control but no presence.<BR><BR>Any thoughts guys?<BR><BR>Cheers<BR>Dana<BR><BR><BR>________________________________<BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Dana Tong (AU) [<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>]<BR>Sent: Tuesday, 27 October 2009 8:05 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR><BR>Sorry, that
was a screenshot from my PC. The customer can log in and go ?Available? on his PC but still not send messages to other users.<BR><BR>From: Adam Frankel [mailto:<A href="mailto:afrankel@cisco.com" ymailto="mailto:afrankel@cisco.com">afrankel@cisco.com</A>]<BR>Sent: Monday, 26 October 2009 7:35 PM<BR>To: Dana Tong (AU)<BR>Cc: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR><BR>It appears as if the user is showing him/herself as offline. Do you have any ASA in between? Often we see ASA (pre-8.04) with SIP Inspect will drop the SIP NOTIFY message from the server to the client. If the ASA is not doing NAT you can remove SIP Inspect. If you are doing LDAP authentication on the CUCM and pointing to a GC, change the port to 3268 and restart CTIManager.<BR><BR>Adam<BR><BR><BR>-----Original Message-----<BR>From:
Dana Tong (AU) <<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><mailto:<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><BR>Sent: Sun, Oct 25, 2009 10:48:16 Pm<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>CC:<BR>Subject: Re: [cisco-voip] CUPC troubleshooting
tips?<BR>[cid:image001.png@01CA56DC.4577E680]<BR>[cid:image002.jpg@01CA56DC.4577E680]<BR><BR><BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>> [mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Dana Tong (AU)<BR>Sent: Monday, 26 October 2009 11:10 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] CUPC troubleshooting tips?<BR><BR>Hi everyone,<BR><BR>I am
having an issue with a CUPS / CUPC installation. This is still in the deployment phase.<BR><BR>CUCM = 7.0.2.20000-5<BR>CUPS = 7.0.4<BR>CUPC = 7.0.2.13496<BR><BR>CUCM is being upgraded to 7.1(3) on Wednesday night.<BR><BR><BR>My issues are:<BR>Deskphone control is random. I can login via VPN and control the users deskphone. When the user logs in, he cannot control the phone. The problem appears to be related to the user?s PC. He has VT Advantage also installed. I asked him to shut all application and to try again with no luck. Once he has attempted to login, deskphone control goes to ?stopped? and CTI won?t attempt to connect anymore. I can no longer login and get deskphone control up either. The fix is to restart the CUP server.<BR><BR>Instant Messaging:<BR>My client cannot instant message another user. The CUPC client reports ?Contact cannot receive Instant Messages?.<BR><BR>Any thoughts on these
problems?<BR><BR>Thanks<BR>Dana<BR><BR><BR><BR>******************************************************************************<BR><BR>- NOTICE FROM DIMENSION DATA AUSTRALIA<BR><BR>This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in error, please notify the sender and delete it immediately.<BR><BR><BR><BR>Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.<BR><BR>******************************************************************************<BR><BR><BR><BR><BR><BR><BR><BR>________________________________<BR><BR><BR><BR><BR><BR><BR>_______________________________________________<BR><BR>cisco-voip mailing list<BR><BR><A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.html</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: image001.png<BR>Type: image/png<BR>Size: 16877 bytes<BR>Desc: image001.png<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.png"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.png</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: image002.jpg<BR>Type: image/jpeg<BR>Size: 26208 bytes<BR>Desc: image002.jpg<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.jpg" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.jpg</A>><BR><BR>------------------------------<BR><BR>Message: 34<BR>Date: Wed, 28 Oct 2009 21:59:51 +1100<BR>From: "Dana Tong (AU)" <<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><BR>To: "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>" <<A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR>Message-ID:<BR> <<A href="mailto:B9B345954EE2444284E3DC802DF6333A5D24E9537E@AUNDDEXMBS01.au.didata.local" ymailto="mailto:B9B345954EE2444284E3DC802DF6333A5D24E9537E@AUNDDEXMBS01.au.didata.local">B9B345954EE2444284E3DC802DF6333A5D24E9537E@AUNDDEXMBS01.au.didata.local</A>><BR> <BR>Content-Type: text/plain; charset="windows-1252"<BR><BR>My bad. It's all good.<BR><BR>VT advantage was screwing up deskphone control!<BR><BR>Cheers<BR><BR>________________________________<BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Dana Tong
(AU) [<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>]<BR>Sent: Wednesday, 28 October 2009 8:04 PM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR><BR>Hey guys,<BR><BR>I've upgraded CUCM to 7.1(3) and CUPS to 7.0(5) but the customer still cannot get deskphone control.<BR>I think it might be something to do with his PC and the software he's running or has run in the past. (I found once that if you were running a CTI application [ie Cisco Attendant Console] that deskphone control would stop. I think the customer has an install of Zeacomm Qmaster installed so that might be stopping it.<BR><BR>He is able to login and become "available" but no deskphone control.<BR><BR>My PC is not part of the domain and I can get deskphone control but no presence.<BR><BR>Any
thoughts guys?<BR><BR>Cheers<BR>Dana<BR><BR><BR>________________________________<BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A> [<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Dana Tong (AU) [<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>]<BR>Sent: Tuesday, 27 October 2009 8:05 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR><BR>Sorry, that was a screenshot from my PC. The customer can log in and go ?Available? on his PC but still not send messages to other users.<BR><BR>From: Adam Frankel [mailto:<A href="mailto:afrankel@cisco.com"
ymailto="mailto:afrankel@cisco.com">afrankel@cisco.com</A>]<BR>Sent: Monday, 26 October 2009 7:35 PM<BR>To: Dana Tong (AU)<BR>Cc: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR><BR>It appears as if the user is showing him/herself as offline. Do you have any ASA in between? Often we see ASA (pre-8.04) with SIP Inspect will drop the SIP NOTIFY message from the server to the client. If the ASA is not doing NAT you can remove SIP Inspect. If you are doing LDAP authentication on the CUCM and pointing to a GC, change the port to 3268 and restart CTIManager.<BR><BR>Adam<BR><BR><BR>-----Original Message-----<BR>From: Dana Tong (AU) <<A href="mailto:Dana.Tong@didata.com.au" ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><mailto:<A href="mailto:Dana.Tong@didata.com.au"
ymailto="mailto:Dana.Tong@didata.com.au">Dana.Tong@didata.com.au</A>><BR>Sent: Sun, Oct 25, 2009 10:48:16 Pm<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>> <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>CC:<BR>Subject: Re: [cisco-voip] CUPC troubleshooting tips?<BR>[cid:image001.png@01CA56DC.4577E680]<BR>[cid:image002.jpg@01CA56DC.4577E680]<BR><BR><BR>From: <A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A><mailto:<A
href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>> [mailto:<A href="mailto:cisco-voip-bounces@puck.nether.net" ymailto="mailto:cisco-voip-bounces@puck.nether.net">cisco-voip-bounces@puck.nether.net</A>] On Behalf Of Dana Tong (AU)<BR>Sent: Monday, 26 October 2009 11:10 AM<BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] CUPC troubleshooting tips?<BR><BR>Hi everyone,<BR><BR>I am having an issue with a CUPS / CUPC installation. This is still in the deployment phase.<BR><BR>CUCM = 7.0.2.20000-5<BR>CUPS = 7.0.4<BR>CUPC = 7.0.2.13496<BR><BR>CUCM is being upgraded to 7.1(3) on Wednesday night.<BR><BR><BR>My issues are:<BR>Deskphone
control is random. I can login via VPN and control the users deskphone. When the user logs in, he cannot control the phone. The problem appears to be related to the user?s PC. He has VT Advantage also installed. I asked him to shut all application and to try again with no luck. Once he has attempted to login, deskphone control goes to ?stopped? and CTI won?t attempt to connect anymore. I can no longer login and get deskphone control up either. The fix is to restart the CUP server.<BR><BR>Instant Messaging:<BR>My client cannot instant message another user. The CUPC client reports ?Contact cannot receive Instant Messages?.<BR><BR>Any thoughts on these problems?<BR><BR>Thanks<BR>Dana<BR><BR><BR><BR>******************************************************************************<BR><BR>- NOTICE FROM DIMENSION DATA AUSTRALIA<BR><BR>This message is confidential, and may contain proprietary or legally privileged information. If you have received this email in
error, please notify the sender and delete it immediately.<BR><BR><BR><BR>Internet communications are not secure. You should scan this message and any attachments for viruses. Under no circumstances do we accept liability for any loss or damage which may result from your receipt of this message or any attachments.<BR><BR>******************************************************************************<BR><BR><BR><BR><BR><BR>________________________________<BR><BR><BR><BR><BR><BR><BR>_______________________________________________<BR><BR>cisco-voip mailing list<BR><BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><mailto:<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip"
target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.html</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: image001.png<BR>Type: image/png<BR>Size: 16877 bytes<BR>Desc: image001.png<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.png" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.png</A>><BR>-------------- next part --------------<BR>A non-text attachment was scrubbed...<BR>Name: image002.jpg<BR>Type: image/jpeg<BR>Size: 26208 bytes<BR>Desc:
image002.jpg<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.jpg" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.jpg</A>><BR><BR>------------------------------<BR><BR>Message: 35<BR>Date: Wed, 28 Oct 2009 13:44:33 +0200<BR>From: Kelemen Zolt?n <<A href="mailto:keli@carocomp.ro" ymailto="mailto:keli@carocomp.ro">keli@carocomp.ro</A>><BR>To: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] 7960 to SIP server<BR>Message-ID: <<A href="mailto:4AE82EA1.90602@carocomp.ro" ymailto="mailto:4AE82EA1.90602@carocomp.ro">4AE82EA1.90602@carocomp.ro</A>><BR>Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"<BR><BR>Generally speaking, it should be, though as they are not a "supported <BR>type", it probably won't be
straight-forward and the phones might need <BR>some external provisioning server (ie tftp)<BR><BR>I don't have any experience with talkswitch itself, but a SIP server <BR>should be a registrar server if you need to add phones to it.<BR><BR>The talkswitch site has a pdf guide for installing phones here: <BR><A href="http://www.talkswitch.com/us/en/support/documentation/phones/#ipphones" target=_blank>http://www.talkswitch.com/us/en/support/documentation/phones/#ipphones</A> <BR>(Adding IP Phones to TalkSwitch <BR><<A href="http://www.talkswitch.com/dms/?domain=www.talkswitch.com&get=845CBD73CDC4929EE877848D96FBEB2D" target=_blank>http://www.talkswitch.com/dms/?domain=www.talkswitch.com&get=845CBD73CDC4929EE877848D96FBEB2D</A>> <BR>) and you might find this one helpful as well (except of course the bits <BR>related to configuring the Asterisk server): <BR><A href="http://wiki.siftah.com/Cisco_7960G_IP_Phone_on_Asterisk"
target=_blank>http://wiki.siftah.com/Cisco_7960G_IP_Phone_on_Asterisk</A><BR><BR>According to the talkswitch guide, you might try "other IP phone" as <BR>"phone type" on the talkswitch.<BR><BR>regards,<BR> Zoltan<BR><BR>On 10/26/2009 8:36 PM, VoiceNoob wrote:<BR>><BR>> So I am trying to see if something a customer is doing is even <BR>> possible. They have several 7960 IP phones they want to load the SIP <BR>> image on and deploy. They want to register to a Talkswitch 484 VS. I <BR>> need to know where I should start in this process. I have some packet <BR>> captures of the phone trying to register but I don't even know if this <BR>> is possible or not. Should the Talkswitch device be a SIP registrar <BR>> server?<BR>><BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net"
ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>> <BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/2f66e1d5/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/2f66e1d5/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 36<BR>Date: Wed, 28 Oct 2009 09:28:43 -0400<BR>From: "c3voip" <<A href="mailto:c3voip@nc.rr.com" ymailto="mailto:c3voip@nc.rr.com">c3voip@nc.rr.com</A>><BR>To: <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] LDAP Sync vs AD
Integration<BR>Message-ID: <003001ca57d2$91bcf930$b536eb90$@rr.com><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>Now that I have upgraded to CUCM 7.1.2, I am having to find new ways to do<BR>old tasks.<BR><BR><BR><BR>The first of which is user management.<BR><BR><BR><BR>Adding a user with CCM 4.1.3 with AD Integration: <BR><BR>We used to be able to create a Subscriber using Unity, which would create<BR>the AD user. We could find the user in Global Directory and edit their<BR>telephone number for the Corporate Directory. <BR><BR><BR><BR>Deleting a user with CCM 4.1.3 with AD Integration:<BR><BR>We used to be able to delete a Subscriber using Unity, then go into Global<BR>Directory and delete the user which would delete the user in AD.<BR><BR><BR><BR>Now with CUCM 7.1.2 with LDAP Sync:<BR><BR>It looks like we need to grant some type of AD domain admin rights to people<BR>that didn't have them before in order to give them access
to the AD Users<BR>and Computers plugin to perform these same tasks. <BR><BR><BR><BR>Am I missing something? <BR><BR><BR><BR>Thanks,<BR><BR>-C<BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/4ecd79d1/attachment-0001.html" target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/4ecd79d1/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 37<BR>Date: Wed, 28 Oct 2009 07:40:10 -0700<BR>From: Scott Voll <<A href="mailto:svoll.voip@gmail.com" ymailto="mailto:svoll.voip@gmail.com">svoll.voip@gmail.com</A>><BR>To: c3voip <<A href="mailto:c3voip@nc.rr.com" ymailto="mailto:c3voip@nc.rr.com">c3voip@nc.rr.com</A>><BR>Cc: <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>Subject: Re: [cisco-voip] LDAP Sync
vs AD Integration<BR>Message-ID:<BR> <<A href="mailto:f84a38d30910280740t3dfd6cfp56f51a9bc1ae9229@mail.gmail.com" ymailto="mailto:f84a38d30910280740t3dfd6cfp56f51a9bc1ae9229@mail.gmail.com">f84a38d30910280740t3dfd6cfp56f51a9bc1ae9229@mail.gmail.com</A>><BR>Content-Type: text/plain; charset="windows-1252"<BR><BR>your not missing anything.<BR><BR>The AD sync is only that. it only looks to your LDAP for authentication.<BR>it will not add / delete users.<BR><BR>Couple questions:<BR><BR>is your Unity VM only and is that the LDAP your looking at?<BR>Are you doing your add / delete stuff from CM or Unity.<BR> if unity, I would not think anything would change.<BR> if CM you are correct and they would need to have access via the LDAP.<BR><BR>hope that helps.<BR><BR>Scott<BR><BR><BR><BR>On Wed, Oct 28, 2009 at 6:28 AM, c3voip <<A href="mailto:c3voip@nc.rr.com"
ymailto="mailto:c3voip@nc.rr.com">c3voip@nc.rr.com</A>> wrote:<BR><BR>> Now that I have upgraded to CUCM 7.1.2, I am having to find new ways to<BR>> do old tasks.<BR>><BR>><BR>><BR>> The first of which is user management.<BR>><BR>><BR>><BR>> Adding a user with CCM 4.1.3 with AD Integration:<BR>><BR>> We used to be able to create a Subscriber using Unity, which would create<BR>> the AD user. We could find the user in Global Directory and edit their<BR>> telephone number for the Corporate Directory.<BR>><BR>><BR>><BR>> Deleting a user with CCM 4.1.3 with AD Integration:<BR>><BR>> We used to be able to delete a Subscriber using Unity, then go into Global<BR>> Directory and delete the user which would delete the user in AD.<BR>><BR>><BR>><BR>> Now with CUCM 7.1.2 with LDAP Sync:<BR>><BR>> It looks like we need to grant some type of AD domain admin rights
to<BR>> people that didn?t have them before in order to give them access to the AD<BR>> Users and Computers plugin to perform these same tasks.<BR>><BR>><BR>><BR>> Am I missing something?<BR>><BR>><BR>><BR>> Thanks,<BR>><BR>> -C<BR>><BR>> _______________________________________________<BR>> cisco-voip mailing list<BR>> <A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR>> <A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR>><BR>><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/55b5b6d9/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/55b5b6d9/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>Message: 38<BR>Date: Wed, 28 Oct 2009 11:55:40 -0400<BR>From: Matthew Loraditch <<A href="mailto:MLoraditch@heliontechnologies.com" ymailto="mailto:MLoraditch@heliontechnologies.com">MLoraditch@heliontechnologies.com</A>><BR>To: "<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>" <<A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A>><BR>Subject: [cisco-voip] Mobility Calls: Transform Internal Extensions to<BR> DIDs<BR>Message-ID:<BR> <<A href="mailto:530C67FE62559C42857C78B962454E6203B8B57A78@hermes.helion.local"
ymailto="mailto:530C67FE62559C42857C78B962454E6203B8B57A78@hermes.helion.local">530C67FE62559C42857C78B962454E6203B8B57A78@hermes.helion.local</A>><BR>Content-Type: text/plain; charset="us-ascii"<BR><BR>All,<BR>We want to have our internal extensions show up as their external DIDs when a mobility call is initiated. For examples, when Extension 1111 calls 1112, when the call is extended to 1112s Cell it should show up as 4105551111 not just 1111. It appears external masks are not taken into consideration for these calls, and prefix digits on my RG wouldn't work as that would affect all callers. I would think I can do this with transformation patterns but have never used them.<BR>Any suggestions?<BR>Thanks!!<BR><BR><BR>Matthew Loraditch<BR>1965 Greenspring Drive<BR>Timonium, MD 21093<BR><A href="mailto:support@heliontechnologies.com" ymailto="mailto:support@heliontechnologies.com">support@heliontechnologies.com</A><mailto:<A
href="mailto:support@heliontechnologies.com" ymailto="mailto:support@heliontechnologies.com">support@heliontechnologies.com</A>><BR>(p) (410) 252-8830<BR>(F) (443) 541-1593<BR><BR>Visit us at www.heliontechnologies.com<<A href="http://www.heliontechnologies.com/" target=_blank>http://www.heliontechnologies.com</A>><BR>Support Issue? Email <A href="mailto:support@heliontechnologies.com" ymailto="mailto:support@heliontechnologies.com">support@heliontechnologies.com</A><mailto:<A href="mailto:support@heliontechnologies.com" ymailto="mailto:support@heliontechnologies.com">support@heliontechnologies.com</A>> for fast assistance!<BR><BR>-------------- next part --------------<BR>An HTML attachment was scrubbed...<BR>URL: <<A href="https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/0a6453fa/attachment-0001.html"
target=_blank>https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/0a6453fa/attachment-0001.html</A>><BR><BR>------------------------------<BR><BR>_______________________________________________<BR>cisco-voip mailing list<BR><A href="mailto:cisco-voip@puck.nether.net" ymailto="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</A><BR><A href="https://puck.nether.net/mailman/listinfo/cisco-voip" target=_blank>https://puck.nether.net/mailman/listinfo/cisco-voip</A><BR><BR><BR>End of cisco-voip Digest, Vol 72, Issue 28<BR>******************************************<BR></DIV></DIV></DIV></div><br>
</body></html>