[cisco-voip] misscalled recording
Arnold Lesar
arnoldlesar at yahoo.co.uk
Wed Oct 28 21:33:31 EDT 2009
dear all,
does cisco IPCC 4.0(5)Express Standard can record misscalled from PSTN line?
if this things could, how do they do it?
GBU
Regards,
Arnold Samuel Lesar
------------------------------------------------------
Note: This message was created by ARNOLD SAMUEL LESAR.
------------------------------------------------------
--------------------------------------------------------------------------
--------------------------------------------------------------------------
PT. PELITA RELIANCE INTERNATIONAL
Eka Hospital BSD City, Tangerang
Address : CBD Lot IX, BSD City, Tangerang
Phone : (+62-21) 256 555 55
Fax : (+62-21) 256 555 44
--------------------------------------------------------------------------
--------------------------------------------------------------------------
________________________________
From: "cisco-voip-request at puck.nether.net" <cisco-voip-request at puck.nether.net>
To: cisco-voip at puck.nether.net
Sent: Wednesday, 28 October, 2009 23:00:02
Subject: cisco-voip Digest, Vol 72, Issue 28
Send cisco-voip mailing list submissions to
cisco-voip at puck.nether.net
To subscribe or unsubscribe via the World Wide Web, visit
https://puck.nether.net/mailman/listinfo/cisco-voip
or, via email, send a message with subject or body 'help' to
cisco-voip-request at puck.nether.net
You can reach the person managing the list at
cisco-voip-owner at puck.nether.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cisco-voip digest..."
Today's Topics:
1. Re: FXO hookflash / conferencing - CM 7.1 (Jack Martin)
2. Re: FXO hookflash / conferencing - CM 7.1 (Ryan West)
3. ATA firmware update (Robert Singleton)
4. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
5. Re: UCCX Script (Jim Reed)
6. Re: Problem using pitney bowes postage machine (Norton, Mike)
7. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)
8. Re: FXO port Attendant DN won't ring Hunt Pilot (Norton, Mike)
9. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)
10. Interpret CDR Search Results (Jeff Ruttman)
11. Re: Interpret CDR Search Results (Ryan Ratliff)
12. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
13. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)
14. Re: Interpret CDR Search Results (Jeff Ruttman)
15. Re: Interpret CDR Search Results (Ryan Ratliff)
16. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
17. Cisco 7961 - Wrong Time, No Local Directory, No Services
(Jeff Cartier)
18. What am I missing with Background images? (Scott Voll)
19. Re: dtmf from cucm to 2821 cube to sip trunk (Ryan Ratliff)
20. Re: Cisco 7961 - Wrong Time, No Local Directory, No Services
(Ryan Ratliff)
21. Re: What am I missing with Background images? (Ryan Ratliff)
22. Re: What am I missing with Background images? (Joe Pollere (US))
23. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
24. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)
25. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
26. answer: Re: What am I missing with Background images? (Scott Voll)
27. SIP phones and caller ID (Philip Walenta)
28. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
29. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)
30. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
31. Re: dtmf from cucm to 2821 cube to sip trunk (Nick Matthews)
32. Re: dtmf from cucm to 2821 cube to sip trunk (Dane Newman)
33. Re: CUPC troubleshooting tips? (Dana Tong (AU))
34. Re: CUPC troubleshooting tips? (Dana Tong (AU))
35. Re: 7960 to SIP server (Kelemen Zolt?n)
36. LDAP Sync vs AD Integration (c3voip)
37. Re: LDAP Sync vs AD Integration (Scott Voll)
38. Mobility Calls: Transform Internal Extensions to DIDs
(Matthew Loraditch)
----------------------------------------------------------------------
Message: 1
Date: Tue, 27 Oct 2009 11:24:19 -0500
From: Jack Martin <jackm at tushaus.com>
To: Ryan West <rwest at zyedge.com>, "cisco-voip at puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] FXO hookflash / conferencing - CM 7.1
Message-ID: <102128A0-EF02-4820-8E10-DB4609F2DA82 at mimectl>
Content-Type: text/plain; charset="Windows-1252"
I believe what you are describing is expected behavior of a line appearancve configured with hookflash.
Are you trying the ad-hoc conference from the same line appearence? Is the CME configured as a key-system?
If you park the first outbound call then place a second outbound call, are you able to conference in the parked call?
Jack Martin, CCVP
Network Engineer
Tushaus Computer Services
10400 Innovation Drive, Ste 100
Milwaukee, WI 53226
414.908.2222 Helpdesk
414.908.2267 Work
414.908.4467 Fax
________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan West [rwest at zyedge.com]
Sent: Tuesday, October 27, 2009 1:17 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] FXO hookflash / conferencing - CM 7.1
Hello,
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) http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088 . 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.
Thanks,
-ryan
------------------------------
Message: 2
Date: Tue, 27 Oct 2009 12:26:31 -0400
From: Ryan West <rwest at zyedge.com>
To: Jack Martin <jackm at tushaus.com>, "cisco-voip at puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] FXO hookflash / conferencing - CM 7.1
Message-ID:
<6E21B2BDEF6E714EA0B5BA8D5D0E140124DFAF437A at zy-ex1.zyedge.local>
Content-Type: text/plain; charset="us-ascii"
Jack,
>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.
Thanks!
-ryan
-----Original Message-----
From: Jack Martin [mailto:jackm at tushaus.com]
Sent: Tuesday, October 27, 2009 12:24 PM
To: Ryan West; cisco-voip at puck.nether.net
Subject: RE: FXO hookflash / conferencing - CM 7.1
I believe what you are describing is expected behavior of a line appearancve configured with hookflash.
Are you trying the ad-hoc conference from the same line appearence? Is the CME configured as a key-system?
If you park the first outbound call then place a second outbound call, are you able to conference in the parked call?
Jack Martin, CCVP
Network Engineer
Tushaus Computer Services
10400 Innovation Drive, Ste 100
Milwaukee, WI 53226
414.908.2222 Helpdesk
414.908.2267 Work
414.908.4467 Fax
________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan West [rwest at zyedge.com]
Sent: Tuesday, October 27, 2009 1:17 AM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] FXO hookflash / conferencing - CM 7.1
Hello,
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) http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdv71088 . 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.
Thanks,
-ryan
------------------------------
Message: 3
Date: Tue, 27 Oct 2009 11:48:31 -0500
From: Robert Singleton <rsingleton at morsco.com>
To: voip puck <cisco-voip at puck.nether.net>
Subject: [cisco-voip] ATA firmware update
Message-ID: <4AE7245F.40808 at morsco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Greetings, All!
I have several ATA188s in the field that have never updated firmware,
although most have. I have never been able to figure out why some
updated and others did not and more importantly, why some will decide to
update suddenly months later.
The older ones are running v3.1.0, which has ethernet ports fixed at
100Mb. The updated ones are running v3.02.03, which has ethernet ports
fixed at 10Mb. Normally, the port speed doesn't matter because they are
generally connected to switches that auto detect speed. In one
particular case today, however, I have four ATAs that are daisy chained
together and it appears that the 2nd in the string has updated, so it
and the 2 behind it cannot register. The first in the chain is still
running the older firmware.
The question is, how can I force an ATA to update, preferably *without*
having to have someone at the branch find a telephone to plug in and use
the voice menus? I will be able to have someone move ethernet cabling
around, so I can have them connect each ATA to the switch port
individually, but how can I make it update on demand?
Thanks!
Robert
--
Robert Singleton
817-259-0955 desk
817-538-2286 mobile
------------------------------
Message: 4
Date: Tue, 27 Oct 2009 12:56:40 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Nick Matthews <matthnick at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910270956m1c0f2044kbb5f291d119f31d8 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Well I tried to switch providers just to test it out and now I am getting
something back in the 183 but still no dtmf hmm
I see they are sending me
m=audio 11680 RTP/AVP 0 101
How do I interperate that line?
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP 173.14.220.57:5060
;branch=z9hG4bK749136B;received=173.14.220.57
From: <sip:6782282221 at did.voip.les.net <sip%3A6782282221 at did.voip.les.net>
>;tag=419FE94-8A1
To: <sip:18774675464 at did.voip.les.net <sip%3A18774675464 at did.voip.les.net>
>;tag=as5677a12c
Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
CSeq: 101 INVITE
User-Agent: LES.NET.VoIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:18774675464 at 64.34.181.47 <sip%3A18774675464 at 64.34.181.47>>
Content-Type: application/sdp
Content-Length: 214
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:
INVITE response with no RSEQ - disable IS_REL1XX
*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No GTD
found in inbound container
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation:
Number of m-lines = 1
SIP: Attribute mid, level 1 instance 1 not found.
*Oct 27 18:02:12.551:
//1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already
bound, use existing source_media_ip_addr
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:
Media src addr for stream 1 = 173.14.220.57
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation:
Codec (g711ulaw) Negotiation Successful on Static Payload for m-line 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation:
No ptime present or multiple ptime attributes that can't be handled
*Oct 27 18:02:12.551:
//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse:
Dynamic payload(101) could not be reserved.
*Oct 27 18:02:12.551:
//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
relay option
*Oct 27 18:02:12.555:
//1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
named event(NE) match in fmtp list of events.
*Oct 27 18:02:12.555:
//-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
from X-cap = 0
*Oct 27 18:02:12.555:
//1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not
present in SDP. Disable modem relay
*Oct 27 18:02:12.555:
//1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction
attribute present or multiple direction attributes that can't be handled for
m-line:1 and num-a-lines:0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation:
Codec negotiation successful for media line 1
payload_type=0, codec_bytes=160, codec=g711ulaw, dtmf_relay=rtp-nte
stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
dest_port=11680
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/sipSPIChangeStreamState:
Stream (callid = -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)
*Oct 27 18:02:12.555:
//1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:
Preferred Codec : g711ulaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com> wrote:
> The 200 OK that you've pasted is confirming the CANCEL that we sent.
> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
> a 200 OK with the CSeq for 101 INVITE.
>
> I've seen this for certain IVRs/providers - sometimes they don't
> properly terminate a call with a 200 OK. If you were not sending an
> SDP in your original INVITE, then you would need the PRACK setting
> mentioned. You have two problems, either could fix the problem: They
> could advertise DTMF in their 183, or they could send you a 200 OK for
> the call. It is assumed you would get DTMF in the 200 OK. It's
> common for endpoints that support DTMF to not advertise it in the 183
> because you technically shouldn't need DTMF to hear ringback.
>
> -nick
>
> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
> > There is no SDP in that 200 OK so I would assume the media info is the
> same
> > as in the 183 Ringing message. You really need your ITSP to tell you
> what
> > dtmf method they want you to use on your outbound calls. As Nick said
> they
> > don't appear to be advertising any dtmf method at all.
> > -Ryan
> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
> > Is the below the ok I should be getting?
> >
> >
> > They did send this with the first debug
> >
> > Received:
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=32DA608-109A
> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
> > CSeq: 102 CANCEL
> > Content-Length: 0
> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:
> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
> > *Oct 27 13:44:12.836:
> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> > *Oct 27 13:44:12.840:
> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> > ccsip_spi_get_msg_type returned: 2 for event 1
> > *Oct 27 13:44:12.840:
> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> > context=0x00000000
> > *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> > Checking Invite Dialog
> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >
> > This with the 2nd debug
> >
> > Received:
> > SIP/2.0 200 OK
> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> > CSeq: 102 CANCEL
> > Content-Length: 0
> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> > *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> > *Oct 27 12:34:15.912:
> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> > ccsip_spi_get_msg_type returned: 2 for event 1
> > *Oct 27 12:34:15.912:
> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> > context=0x00000000
> > *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> > Checking Invite Dialog
> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> > Received:
> > SIP/2.0 487 Request Terminated
> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
> >;tag=3465630735-938664
> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> > Contact: <sip:18774675464 at 64.154.41.200:5060>
> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> > CSeq: 102 INVITE
> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> > Content-Length: 0
> >
> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <matthnick at gmail.com>
> wrote:
> >>
> >> In the 183 Session Progress they're not advertising DTMF:
> >>
> >> m=audio 45846 RTP/AVP 0
> >>
> >> There should be a 100 or 101 there. Although, 183 is just ringback.
> >> You would want to pick up on the other side and they should send a 200
> >> OK with a new SDP. If the other side did pick up, you need to tell
> >> the provider that they need to send a 200 OK, because they're not.
> >>
> >>
> >> -nick
> >>
> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
> >> wrote:
> >> > Nick
> >> >
> >> > I removed voice-class sip asymmetric payload dtmf and added in the
> >> > other
> >> > line
> >> >
> >> > Just to state incoming dtmf works but not outbound the ITSP has told
> me
> >> > they
> >> > are using two different sip servers/vendors for processing inbound and
> >> > outbound
> >> > How does this translate into what I should sent the following too?
> >> >
> >> > rtp payload-type nse
> >> > rtp payload-type nte
> >> >
> >> > In the debug trhe following where set
> >> >
> >> > rtp payload-type nse 101
> >> > rtp payload-type nte 100
> >> >
> >> > In the debug of ccsip If I am looking at it correctly I see me sending
> >> > this
> >> >
> >> > *Oct 27 12:34:09.128:
> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
> >> > Preferred method of dtmf relay is: 6, with payload: 100
> >> > *Oct 27 12:34:09.128:
> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
> >> > max_event 15
> >> >
> >> > and
> >> >
> >> >
> >> > *Oct 27 12:34:10.836:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
> >> > payload
> >> > from X-cap = 0
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
> >> > present
> >> > in SDP. Disable modem relay
> >> >
> >> >
> >> > Sent:
> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
> >> > Remote-Party-ID:
> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
> >;party=calling;screen=yes;privacy=off
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
> >> > Min-SE: 1800
> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> >> > SUBSCRIBE,
> >> > NOTIFY, INFO, REGISTER
> >> > CSeq: 101 INVITE
> >> > Max-Forwards: 70
> >> > Timestamp: 1256646849
> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
> >> > Expires: 180
> >> > Allow-Events: telephone-event
> >> > Content-Type: application/sdp
> >> > Content-Disposition: session;handling=required
> >> > Content-Length: 250
> >> > v=0
> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
> >> > s=SIP Call
> >> > c=IN IP4 173.14.220.57
> >> > t=0 0
> >> > m=audio 16462 RTP/AVP 0 100
> >> > c=IN IP4 173.14.220.57
> >> > a=rtpmap:0 PCMU/8000
> >> > a=rtpmap:100 telephone-event/8000
> >> > a=fmtp:100 0-15
> >> > a=ptime:20
> >> >
> >> >
> >> > Then when I do a search for fmtp again further down I see
> >> >
> >> > Sent:
> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> >> > Remote-Party-ID:
> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
> >;party=calling;screen=yes;privacy=off
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
> >> > Min-SE: 1800
> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
> >> > SUBSCRIBE,
> >> > NOTIFY, INFO, REGISTER
> >> > CSeq: 102 INVITE
> >> > Max-Forwards: 70
> >> > Timestamp: 1256646849
> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
> >> > Expires: 180
> >> > Allow-Events: telephone-event
> >> > Proxy-Authorization: Digest
> >> >
> >> > username="1648245954",realm="64.154.41.110",uri="
> sip:18774675464 at 64.154.41.200:5060
> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
> >> > Content-Type: application/sdp
> >> > Content-Disposition: session;handling=required
> >> > Content-Length: 250
> >> > v=0
> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
> >> > s=SIP Call
> >> > c=IN IP4 173.14.220.57
> >> > t=0 0
> >> > m=audio 16462 RTP/AVP 0 100
> >> > c=IN IP4 173.14.220.57
> >> > a=rtpmap:0 PCMU/8000
> >> > a=rtpmap:100 telephone-event/8000
> >> > a=fmtp:100 0-15
> >> > a=ptime:20
> >> > *Oct 27 12:34:09.332:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> >> > *Oct 27 12:34:09.332:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> >> > ccsip_spi_get_msg_type returned: 2 for event 1
> >> > *Oct 27 12:34:09.332:
> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> >> > context=0x00000000
> >> > *Oct 27 12:34:09.332:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> >> > Checking Invite Dialog
> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >> > Received:
> >> > SIP/2.0 100 Trying
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > CSeq: 102 INVITE
> >> > Content-Length: 0
> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
> >> > INVITE response with no RSEQ - disable IS_REL1XX
> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/sipSPIChangeState:
> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to
> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
> >> > *Oct 27 12:34:10.832:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> >> > *Oct 27 12:34:10.832:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> >> > ccsip_spi_get_msg_type returned: 2 for event 1
> >> > *Oct 27 12:34:10.832:
> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> >> > context=0x00000000
> >> > *Oct 27 12:34:10.836:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> >> > Checking Invite Dialog
> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >> > Received:
> >> > SIP/2.0 183 Session Progress
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
> >;tag=3465630735-938664
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > Contact: <sip:18774675464 at 64.154.41.200:5060>
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > CSeq: 102 INVITE
> >> > Content-Type: application/sdp
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> >> > Content-Length: 146
> >> > v=0
> >> > o=msx71 490 6110 IN IP4 64.154.41.200
> >> > s=sip call
> >> > c=IN IP4 64.154.41.101
> >> > t=0 0
> >> > m=audio 45846 RTP/AVP 0
> >> > a=ptime:20
> >> > a=rtpmap:0 PCMU/8000
> >> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
> >> > INVITE response with no RSEQ - disable IS_REL1XX
> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
> No
> >> > GTD
> >> > found in inbound container
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
> >> > Number of m-lines = 1
> >> > SIP: Attribute mid, level 1 instance 1 not found.
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
> >> > already
> >> > bound, use existing source_media_ip_addr
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
> >> > Media src addr for stream 1 = 173.14.220.57
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line 1
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
> >> > One ptime attribute found - value:20
> >> > *Oct 27 12:34:10.836:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values
> :Codec:
> >> > g711ulaw ptime :20, codecbytes: 160
> >> > *Oct 27 12:34:10.836:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
> :Codec:
> >> > g711ulaw codecbytes :160, ptime: 20
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160 for
> >> > codec
> >> > g711ulaw
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index
> 1
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
> >> > Dynamic payload(100) could not be reserved.
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
> >> > named
> >> > event(NE) match in fmtp list of events.
> >> > *Oct 27 12:34:10.836:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
> >> > payload
> >> > from X-cap = 0
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
> >> > present
> >> > in SDP. Disable modem relay
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
> direction
> >> > attribute present or multiple direction attributes that can't be
> handled
> >> > for
> >> > m-line:1 and num-a-lines:0
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
> >> > Codec negotiation successful for media line 1
> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,
> >> > dtmf_relay=rtp-nte
> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
> >> > dest_port=45846
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to
> >> > (STREAM_ADDING)
> >> > *Oct 27 12:34:10.836:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
> >> > Preferred Codec : g711ulaw, bytes :160
> >> > Preferred DTMF relay : rtp-nte
> >> > Preferred NTE payload : 100
> >> > Early Media : No
> >> > Delayed Media : No
> >> > Bridge Done : No
> >> > New Media : No
> >> > DSP DNLD Reqd : No
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
> >> > already
> >> > bound, use existing source_media_ip_addr
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
> >> > Media src addr for stream 1 = 173.14.220.57
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
> >> > callId 846 size 240 ptr 0x4A170B28)
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
> >> > Hndl ptype 0 mline 1
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
> >> > Selecting
> >> > codec g711ulaw
> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
> >> > Codec to be matched: 5
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD
> >> > AUDIO
> >> > CODEC 5
> >> > *Oct 27 12:34:10.840:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
> :Codec:
> >> > g711ulaw codecbytes :160, ptime: 20
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Media
> >> > negotiation done:
> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
> coverted
> >> > ptime=20 stream->mline_index=1, media_ndx=1
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1
> >> > 64.154.41.101:45846
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy
> >> > sdp to
> >> > channel- AFTER CODEC FILTERING:
> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy
> >> > sdp to
> >> > channel- AFTER CODEC FILTERING:
> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
> >> > Report initial call media
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
> ccb->flags
> >> > 0x400018, ccb->pld.flags_ipip 0x200005
> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
> >> > callId 846 size 240 ptr 0x4DEC000C)
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
> >> > 5030: Posting Remote SRTP caps to other callleg.
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
> >> > cc_api_caps_ind()
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
> >> > Stream type : voice+dtmf
> >> > Media line : 1
> >> > State : STREAM_ADDING (2)
> >> > Stream address type : 1
> >> > Callid : 846
> >> > Negotiated Codec : g711ulaw, bytes :160
> >> > Nego. Codec payload : 0 (tx), 0 (rx)
> >> > Negotiated DTMF relay : rtp-nte
> >> > Negotiated NTE payload : 100 (tx), 100 (rx)
> >> > Negotiated CN payload : 0
> >> > Media Srce Addr/Port : [173.14.220.57]:16462
> >> > Media Dest Addr/Port : [64.154.41.101]:45846
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
> >> > headers
> >> > recvd from app container
> >> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:
> >> > No
> >> > QSIG Body found in inbound container
> >> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:
> >> > No
> >> > RawMsg Body found in inbound container
> >> > *Oct 27 12:34:10.840:
> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:
> >> > No
> >> > Data to form The Raw Message
> >> > *Oct 27 12:34:10.840:
> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/sipSPIChangeState:
> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
> >> > SUBSTATE_NONE)
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction
> >> > Complete. Lock on Facilities released.
> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge: confID
> =
> >> > 6,
> >> > srcCallID = 846, dstCallID = 845
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
> >> > Old streamcallid=846, new streamcallid=846
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
> >> > Setting SPI mode to SIP-H323
> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = 1131891908
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
> >> > sipSPIProcessRtpSessions
> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:
> >> > Adding
> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
> >> > already
> >> > bound, use existing source_media_ip_addr
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
> >> > Media src addr for stream 1 = 173.14.220.57
> >> > *Oct 27 12:34:10.844:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
> >> > sipSPIUpdateRtcpSession for m-line 1
> >> > *Oct 27 12:34:10.848:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
> >> > rtcp_session info
> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,
> >> > rport=45846, do_rtcp=TRUE
> >> > src_callid = 846, dest_callid = 845, stream type = voice+dtmf,
> >> > stream direction = SENDRECV
> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0 media_addr_type
> =
> >> > 1
> >> > *Oct 27 12:34:10.848:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
> >> > RTP session already created - update
> >> > *Oct 27 12:34:10.848:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
> >> > stun is disabled for stream:4A1709F8
> >> > *Oct 27 12:34:10.848:
> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
> >> > New Remote Media Direction = SENDRECV
> >> > Present Local Media Direction = SENDRECV
> >> > New Local Media Direction = SENDRECV
> >> > retVal = 0
> >> > *Oct 27 12:34:10.848:
> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to
> >> > (STREAM_ACTIVE)
> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge: really
> >> > can't
> >> > find peer_stream for
> >> > dtmf-relay
> interworking
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> Entry
> >> > *Oct 27 12:34:11.140:
> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: CURRENT
> >> > VALUES: stream_callid=846, current_seq_num=0x23ED
> >> > *Oct 27 12:34:11.140:
> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
> >> > VALUES:
> >> > stream_callid=846, current_seq_num=0x11D9
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load
> >> > DSP
> >> > with negotiated codec: g711ulaw, Bytes=160
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set
> >> > forking flag to 0x0
> >> > *Oct 27 12:34:11.140:
> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx payload
> =
> >> > 100, tx payload = 100
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
> >> > config=0
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Disabling Modem Relay...
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
> >> > Xcap
> >> > list
> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Modem
> >> > Relay & Passthru both disabled
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > nse
> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
> relay=0,
> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
> >> > *Oct 27 12:34:11.144:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > 1
> >> > Active Streams
> >> > *Oct 27 12:34:11.144:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > Adding stream type (voice+dtmf) from media
> >> > line 1 codec g711ulaw
> >> > *Oct 27 12:34:11.144:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
> >> > caps.stream_list.xmitFunc=
> >> > *Oct 27 12:34:11.144:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > voip_rtp_xmit, caps.stream_list.context=
> >> > *Oct 27 12:34:11.144:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > 0x497E0B60 (gccb)
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load
> >> > DSP
> >> > with codec : g711ulaw, Bytes=160, payload = 0
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
> >> > video
> >> > caps detected in the caps posted by peer leg
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> >> > Setting
> >> > CAPS_RECEIVED flag
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> >> > Calling
> >> > cc_api_caps_ack()
> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack: Set
> >> > forking flag to 0x0
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> Entry
> >> > *Oct 27 12:34:11.168:
> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: CURRENT
> >> > VALUES: stream_callid=846, current_seq_num=0x11D9
> >> > *Oct 27 12:34:11.168:
> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
> >> > VALUES:
> >> > stream_callid=846, current_seq_num=0x11D9
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load
> >> > DSP
> >> > with negotiated codec: g711ulaw, Bytes=160
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set
> >> > forking flag to 0x0
> >> > *Oct 27 12:34:11.168:
> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx payload
> =
> >> > 100, tx payload = 100
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
> >> > config=0
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Disabling Modem Relay...
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
> >> > Xcap
> >> > list
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > Modem
> >> > Relay & Passthru both disabled
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
> >> > nse
> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
> relay=0,
> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
> >> > *Oct 27 12:34:11.168:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > 1
> >> > Active Streams
> >> > *Oct 27 12:34:11.168:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > Adding stream type (voice+dtmf) from media
> >> > line 1 codec g711ulaw
> >> > *Oct 27 12:34:11.168:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
> >> > caps.stream_list.xmitFunc=
> >> > *Oct 27 12:34:11.168:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > voip_rtp_xmit, caps.stream_list.context=
> >> > *Oct 27 12:34:11.168:
> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
> >> > 0x497E0B60 (gccb)
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Load
> >> > DSP
> >> > with codec : g711ulaw, Bytes=160, payload = 0
> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
> >> > video
> >> > caps detected in the caps posted by peer leg
> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
> Second
> >> > TCS
> >> > received for transfers across trunk - set CAPS2_RECEIVED
> >> > *Oct 27 12:34:15.876:
> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
> >> > stun is disabled for stream:4A1709F8
> >> > *Oct 27 12:34:15.876:
> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:
> >> > Stats are not supported for IPIP call.
> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
> >> > Queued
> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
> >> > *Oct 27 12:34:15.880:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> >> > ccsip_spi_get_msg_type returned: 3 for event 7
> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:
> >> > Associated container=0x4E310C1C to Cancel
> >> > *Oct 27 12:34:15.880:
> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:
> >> > Sending CANCEL to the transport layer
> >> > *Oct 27 12:34:15.880:
> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
> >> > msg=0x4DF0D994,
> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,
> >> > switch=0, callBack=0x419703BC
> >> > *Oct 27 12:34:15.880:
> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
> Proceedable
> >> > for
> >> > sending msg immediately
> >> > *Oct 27 12:34:15.880:
> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
> >> > transport
> >> > is 0
> >> > *Oct 27 12:34:15.880:
> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to send
> >> > the
> >> > msg=0x4DF0D994
> >> > *Oct 27 12:34:15.880:
> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting
> >> > send
> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP
> >> > *Oct 27 12:34:15.880:
> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
> >> > Sent Cancel Request, starting CancelWaitResponseTimer
> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/sipSPIChangeState:
> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, SUBSTATE_NONE)
> >> > to
> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)
> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >> > Sent:
> >> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > CSeq: 102 CANCEL
> >> > Max-Forwards: 70
> >> > Timestamp: 1256646855
> >> > Reason: Q.850;cause=16
> >> > Content-Length: 0
> >> > *Oct 27 12:34:15.900:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> >> > *Oct 27 12:34:15.900:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> >> > ccsip_spi_get_msg_type returned: 2 for event 1
> >> > *Oct 27 12:34:15.900:
> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> >> > context=0x00000000
> >> > *Oct 27 12:34:15.900:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> >> > Checking Invite Dialog
> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >> > Received:
> >> > SIP/2.0 200 OK
> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
> >;tag=2EDA9C8-25D6
> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> >> > CSeq: 102 CANCEL
> >> > Content-Length: 0
> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> >> > *Oct 27 12:34:15.912:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> >> > *Oct 27 12:34:15.912:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> >> > ccsip_spi_get_msg_type returned: 2 for event 1
> >> > *Oct 27 12:34:15.912:
> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> >> > context=0x00000000
> >> > *Oct 27 12:34:15.912:
> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
> >> > Checking Invite Dialog
> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> >> >
> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com>
> >> > wrote:
> >> >>
> >> >> You would want to check the SDP of 200 OK the provider sends for your
> >> >> outgoing call. It will list the payload type for the dtmf in the
> >> >> format a=fmtp 101 1-16, or something similar. You want to find out
> >> >> what payload type they are advertising (or if they are at all). It
> >> >> would be worth checking the incoming INVITE from them to see what
> >> >> they're using when they send the first SDP.
> >> >>
> >> >> On that note, I would also remove the asymmetric payload command - to
> >> >> my knowledge it doesn't do what you're expecting it to. You may want
> >> >> to try this command:
> >> >> voice-class sip dtmf-relay force rtp-nte
> >> >>
> >> >>
> >> >> -nick
> >> >>
> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com>
> >> >> wrote:
> >> >> > Hello,
> >> >> >
> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf
> works
> >> >> > fine.
> >> >> > It took some playing around with it. At first it didnt work till
> the
> >> >> > payload was ajusted. I am now trying to get outbound dtmf
> working
> >> >> > properly.
> >> >> >
> >> >> > On my 2821 I debugged voip rtp session named-events and then made a
> >> >> > call
> >> >> > to
> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on the
> >> >> > router
> >> >> > nothing showed up in the debug. Does this mean I can safely asume
> >> >> > that
> >> >> > the
> >> >> > problem for right now is not on the ITSP side but on my side since
> >> >> > dtmf
> >> >> > is
> >> >> > not being sent down the sip trunk?
> >> >> >
> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
> >> >> > configuration
> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas what
> I
> >> >> > can
> >> >> > do
> >> >> > so dtmf digits process properly outbound?
> >> >> >
> >> >> > The settings in my cuc 7.x to add the gateway h323 are
> >> >> >
> >> >> > h323 cucm gateway configuratration
> >> >> > Signaling Port 1720
> >> >> > media termination point required yes
> >> >> > retry video call as auto yes
> >> >> > wait for far end h.245 terminal capability set yes
> >> >> > transmit utf-8 calling party name no
> >> >> > h.235 pass through allowed no
> >> >> > significant digits all
> >> >> > redirect number IT deliver - inbound no
> >> >> > enable inbound faststart yes
> >> >> > display IE deliver no
> >> >> > redirect nunmber IT deliver - outbound no
> >> >> > enable outbound faststart yes
> >> >> >
> >> >> >
> >> >> > voice service voip
> >> >> > allow-connections h323 to h323
> >> >> > allow-connections h323 to sip
> >> >> > allow-connections sip to h323
> >> >> > allow-connections sip to sip
> >> >> > fax protocol pass-through g711ulaw
> >> >> > h323
> >> >> > emptycapability
> >> >> > h225 id-passthru
> >> >> > h245 passthru tcsnonstd-passthru
> >> >> > sip
> >> >> >
> >> >> >
> >> >> > voice class h323 50
> >> >> > h225 timeout tcp establish 3
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > !
> >> >> > voice translation-rule 1
> >> >> > rule 1 /.*/ /190/
> >> >> > !
> >> >> > voice translation-rule 2
> >> >> > rule 1 /.*/ /1&/
> >> >> > !
> >> >> > !
> >> >> > voice translation-profile aa
> >> >> > translate called 1
> >> >> > !
> >> >> > voice translation-profile addone
> >> >> > translate called 2
> >> >> > !
> >> >> > !
> >> >> > voice-card 0
> >> >> > dspfarm
> >> >> > dsp services dspfarm
> >> >> > !
> >> >> > !
> >> >> > sccp local GigabitEthernet0/1
> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
> >> >> > sccp
> >> >> > !
> >> >> > sccp ccm group 1
> >> >> > associate ccm 1 priority 1
> >> >> > associate ccm 2 priority 2
> >> >> > associate profile 1 register 2821transcode
> >> >> > !
> >> >> > dspfarm profile 1 transcode
> >> >> > codec g711ulaw
> >> >> > codec g711alaw
> >> >> > codec g729ar8
> >> >> > codec g729abr8
> >> >> > codec g729r8
> >> >> > maximum sessions 4
> >> >> > associate application SCCP
> >> >> > !
> >> >> > !
> >> >> > dial-peer voice 100 voip
> >> >> > description AA Publisher
> >> >> > preference 1
> >> >> > destination-pattern 1..
> >> >> > voice-class h323 50
> >> >> > session target ipv4:10.1.80.10
> >> >> > dtmf-relay h245-alphanumeric
> >> >> > codec g711ulaw
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 1000 voip
> >> >> > description incoming Call
> >> >> > translation-profile incoming aa
> >> >> > preference 1
> >> >> > rtp payload-type nse 101
> >> >> > rtp payload-type nte 100
> >> >> > incoming called-number 6782282221
> >> >> > dtmf-relay rtp-nte
> >> >> > codec g711ulaw
> >> >> > ip qos dscp cs5 media
> >> >> > ip qos dscp cs5 signaling
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 101 voip
> >> >> > description AA Subscriber
> >> >> > preference 2
> >> >> > destination-pattern 1..
> >> >> > voice-class h323 50
> >> >> > session target ipv4:10.1.80.11
> >> >> > dtmf-relay h245-alphanumeric
> >> >> > codec g711ulaw
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 2000 voip
> >> >> > description outbound
> >> >> > translation-profile outgoing addone
> >> >> > preference 1
> >> >> > destination-pattern .T
> >> >> > rtp payload-type nse 101
> >> >> > rtp payload-type nte 100
> >> >> > voice-class sip asymmetric payload dtmf
> >> >> > session protocol sipv2
> >> >> > session target ipv4:64.154.41.200
> >> >> > dtmf-relay rtp-nte
> >> >> > codec g711ulaw
> >> >> > no vad
> >> >> > !
> >> >> > !
> >> >> > sip-ua
> >> >> > credentials username ***** password 7 ***** realm
> sip.talkinip.net
> >> >> > authentication username ***** password 7 *****
> >> >> > authentication username ***** password 7 ***** realm
> >> >> > sip.talkinip.net
> >> >> > set pstn-cause 3 sip-status 486
> >> >> > set pstn-cause 34 sip-status 486
> >> >> > set pstn-cause 47 sip-status 486
> >> >> > registrar dns:sip.talkinip.net expires 60
> >> >> > sip-server dns:sip.talkinip.net:5060
> >> >> > _______________________________________________
> >> >> > cisco-voip mailing list
> >> >> > cisco-voip at puck.nether.net
> >> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >> >> >
> >> >> >
> >> >
> >> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f0979ab6/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 27 Oct 2009 11:14:45 -0600
From: Jim Reed <jreed at swiftnews.com>
To: Ratko Dodevski <rade239 at gmail.com>, "cisco-voip at puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] UCCX Script
Message-ID: <C70C86A8.2B732%jreed at swiftnews.com>
Content-Type: text/plain; charset="iso-8859-1"
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.
For what it's worth...
--
Jim Reed
Swift Communications, Inc.
970-683-5646 (Direct)
775-772-7666 (Cell)
Quando omni flunkus moritati
"When all else fails, play dead"
Red Green - President: Possum Lodge
On 10/26/09 3:41 AM, "Ratko Dodevski" <rade239 at gmail.com> wrote:
Hi,
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.
thanks in advanced
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PhoneNumberMatching.aef
Type: application/octet-stream
Size: 14804 bytes
Desc: PhoneNumberMatching.aef
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PhoneNumbers.xml
Type: application/octet-stream
Size: 7894 bytes
Desc: PhoneNumbers.xml
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/df3e02aa/attachment-0003.obj>
------------------------------
Message: 6
Date: Tue, 27 Oct 2009 11:21:24 -0600
From: "Norton, Mike" <mikenorton at pwsd76.ab.ca>
To: Robert Shearrill <rshearri at uchicago.edu>,
"cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Problem using pitney bowes postage machine
Message-ID:
<096D50507635B645A061351B1308C90B01EFB32443 at pwsdexchange03.pwsb33.ab.ca>
Content-Type: text/plain; charset="us-ascii"
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.
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.
--
Mike Norton
I.T. Support
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Robert Shearrill
Sent: October-26-09 12:37 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] Problem using pitney bowes postage machine
I having trouble using pitney bowes postage machine on the vg224 analog gateway. Have anyone come across this problem or have a solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/23c58ae2/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 27 Oct 2009 14:00:01 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID: <AAFA07F1-1E5C-4C2B-90F8-8DFE0601A50A at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
That is RFC2833 DTMF with a payload type of 101.
I do know that CUBE cannot do dynamic RFC2833 payload types. It can
only send the payloadType defined in the voip dial-peer. So if
inbound calls use a different payloadType than outbound calls you will
want to update the dial-peers accordingly.
-Ryan
On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
Well I tried to switch providers just to test it out and now I am
getting something back in the 183 but still no dtmf hmm
I see they are sending me
m=audio 11680 RTP/AVP 0 101
How do I interperate that line?
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57
From: <sip:6782282221 at did.voip.les.net>;tag=419FE94-8A1
To: <sip:18774675464 at did.voip.les.net>;tag=as5677a12c
Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
CSeq: 101 INVITE
User-Agent: LES.NET.VoIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:18774675464 at 64.34.181.47>
Content-Type: application/sdp
Content-Length: 214
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX
*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
No GTD found in inbound container
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoMediaNegotiation: Number of m-lines = 1
SIP: Attribute mid, level 1 instance 1 not found.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
resolve_media_ip_address_to_bind: Media already bound, use existing
source_media_ip_addr
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/
sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on
Static Payload for m-line 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoPtimeNegotiation: No ptime present or multiple ptime
attributes that can't be handled
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: m-line index 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
fmtp list of events.
*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/
sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem
relay
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIGetSDPDirectionAttribute: No direction attribute present or
multiple direction attributes that can't be handled for m-line:1 and
num-a-lines:0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
payload_type=0, codec_bytes=160, codec=g711ulaw,
dtmf_relay=rtp-nte
stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
dest_port=11680
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/
sipSPIChangeStreamState: Stream (callid = -1) State changed from
(STREAM_DEAD) to (STREAM_ADDING)
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/
sipSPIUpdCallWithSdpInfo:
Preferred Codec : g711ulaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>
wrote:
The 200 OK that you've pasted is confirming the CANCEL that we sent.
You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
a 200 OK with the CSeq for 101 INVITE.
I've seen this for certain IVRs/providers - sometimes they don't
properly terminate a call with a 200 OK. If you were not sending an
SDP in your original INVITE, then you would need the PRACK setting
mentioned. You have two problems, either could fix the problem: They
could advertise DTMF in their 183, or they could send you a 200 OK for
the call. It is assumed you would get DTMF in the 200 OK. It's
common for endpoints that support DTMF to not advertise it in the 183
because you technically shouldn't need DTMF to hear ringback.
-nick
On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
wrote:
> There is no SDP in that 200 OK so I would assume the media info is
the same
> as in the 183 Ringing message. You really need your ITSP to tell
you what
> dtmf method they want you to use on your outbound calls. As Nick
said they
> don't appear to be advertising any dtmf method at all.
> -Ryan
> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
> Is the below the ok I should be getting?
>
>
> They did send this with the first debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
> From: <sip:6782282221 at sip.talkinip.net>;tag=32DA608-109A
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> This with the 2nd debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 487 Request Terminated
> To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> Contact: <sip:18774675464 at 64.154.41.200:5060>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 INVITE
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> Content-Length: 0
>
> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews
<matthnick at gmail.com> wrote:
>>
>> In the 183 Session Progress they're not advertising DTMF:
>>
>> m=audio 45846 RTP/AVP 0
>>
>> There should be a 100 or 101 there. Although, 183 is just ringback.
>> You would want to pick up on the other side and they should send a
200
>> OK with a new SDP. If the other side did pick up, you need to tell
>> the provider that they need to send a 200 OK, because they're not.
>>
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Nick
>> >
>> > I removed voice-class sip asymmetric payload dtmf and added in
the
>> > other
>> > line
>> >
>> > Just to state incoming dtmf works but not outbound the ITSP has
told me
>> > they
>> > are using two different sip servers/vendors for processing
inbound and
>> > outbound
>> > How does this translate into what I should sent the following too?
>> >
>> > rtp payload-type nse
>> > rtp payload-type nte
>> >
>> > In the debug trhe following where set
>> >
>> > rtp payload-type nse 101
>> > rtp payload-type nte 100
>> >
>> > In the debug of ccsip If I am looking at it correctly I see me
sending
>> > this
>> >
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>> > Preferred method of dtmf relay is: 6, with payload: 100
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>> > max_event 15
>> >
>> > and
>> >
>> >
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> >
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 101 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> >
>> >
>> > Then when I do a search for fmtp again further down I see
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 102 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Proxy-Authorization: Digest
>> >
>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464 at 64.154.41.200:5060
",response
=
"ab63d4755ff4182631ad2db0f9ed0e44
",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 100 Trying
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Length: 0
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE) to
>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 183 Session Progress
>> > To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Type: application/sdp
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Content-Length: 146
>> > v=0
>> > o=msx71 490 6110 IN IP4 64.154.41.200
>> > s=sip call
>> > c=IN IP4 64.154.41.101
>> > t=0 0
>> > m=audio 45846 RTP/AVP 0
>> > a=ptime:20
>> > a=rtpmap:0 PCMU/8000
>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentGTD: No
>> > GTD
>> > found in inbound container
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>> > Number of m-lines = 1
>> > SIP: Attribute mid, level 1 instance 1 not found.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-
line 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>> > One ptime attribute found - value:20
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes:
Values :Codec:
>> > g711ulaw ptime :20, codecbytes: 160
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes:
160 for
>> > codec
>> > g711ulaw
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
index 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>> > Dynamic payload(100) could not be reserved.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case
of full
>> > named
>> > event(NE) match in fmtp list of events.
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
direction
>> > attribute present or multiple direction attributes that can't be
handled
>> > for
>> > m-line:1 and num-a-lines:0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec negotiation successful for media line 1
>> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>> > dtmf_relay=rtp-nte
>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>> > dest_port=45846
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>> > (STREAM_ADDING)
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Preferred Codec : g711ulaw, bytes :160
>> > Preferred DTMF relay : rtp-nte
>> > Preferred NTE payload : 100
>> > Early Media : No
>> > Delayed Media : No
>> > Bridge Done : No
>> > New Media : No
>> > DSP DNLD Reqd : No
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4A170B28)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Hndl ptype 0 mline 1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Selecting
>> > codec g711ulaw
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>> > Codec to be matched: 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
ADD
>> > AUDIO
>> > CODEC 5
>> > *Oct 27 12:34:10.840:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Media
>> > negotiation done:
>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
coverted
>> > ptime=20 stream->mline_index=1, media_ndx=1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1
ss 1
>> > 64.154.41.101:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > Report initial call media
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
ccb->flags
>> > 0x400018, ccb->pld.flags_ipip 0x200005
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4DEC000C)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>> > 5030: Posting Remote SRTP caps to other callleg.
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>> > cc_api_caps_ind()
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Stream type : voice+dtmf
>> > Media line : 1
>> > State : STREAM_ADDING (2)
>> > Stream address type : 1
>> > Callid : 846
>> > Negotiated Codec : g711ulaw, bytes :160
>> > Nego. Codec payload : 0 (tx), 0 (rx)
>> > Negotiated DTMF relay : rtp-nte
>> > Negotiated NTE payload : 100 (tx), 100 (rx)
>> > Negotiated CN payload : 0
>> > Media Srce Addr/Port : [173.14.220.57]:16462
>> > Media Dest Addr/Port : [64.154.41.101]:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>> > headers
>> > recvd from app container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQSIG:
>> > No
>> > QSIG Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQ931:
>> > No
>> > RawMsg Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPICreateNewRawMsg:
>> > No
>> > Data to form The Raw Message
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>> > SUBSTATE_NONE)
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
Transaction
>> > Complete. Lock on Facilities released.
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
confID =
>> > 6,
>> > srcCallID = 846, dstCallID = 845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old streamcallid=846, new streamcallid=846
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>> > Setting SPI mode to SIP-H323
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
1131891908
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>> > sipSPIProcessRtpSessions
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/
sipSPIAddStream:
>> > Adding
>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > sipSPIUpdateRtcpSession for m-line 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > rtcp_session info
>> > laddr = 173.14.220.57, lport = 16462, raddr =
64.154.41.101,
>> > rport=45846, do_rtcp=TRUE
>> > src_callid = 846, dest_callid = 845, stream type = voice
+dtmf,
>> > stream direction = SENDRECV
>> > media_ip_addr = 64.154.41.101, vrf tableid = 0
media_addr_type =
>> > 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > RTP session already created - update
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>> > New Remote Media Direction = SENDRECV
>> > Present Local Media Direction = SENDRECV
>> > New Local Media Direction = SENDRECV
>> > retVal = 0
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>> > (STREAM_ACTIVE)
>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
really
>> > can't
>> > find peer_stream for
>> > dtmf-relay
interworking
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x23ED
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Setting
>> > CAPS_RECEIVED flag
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Calling
>> > cc_api_caps_ack()
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ack: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Second
>> > TCS
>> > received for transfers across trunk - set CAPS2_RECEIVED
>> > *Oct 27 12:34:15.876:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/
ccsip_call_statistics:
>> > Stats are not supported for IPIP call.
>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>> > Queued
>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 3 for event 7
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/
sipSPISendCancel:
>> > Associated container=0x4E310C1C to Cancel
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/
sipSPISendCancel:
>> > Sending CANCEL to the transport layer
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> > msg=0x4DF0D994,
>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,
transport=1,
>> > switch=0, callBack=0x419703BC
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
Proceedable
>> > for
>> > sending msg immediately
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>> > transport
>> > is 0
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set
to send
>> > the
>> > msg=0x4DF0D994
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:
Posting
>> > send
>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for
UDP
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>> > Sent Cancel Request, starting CancelWaitResponseTimer
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_NONE)
>> > to
>> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Sent:
>> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Max-Forwards: 70
>> > Timestamp: 1256646855
>> > Reason: Q.850;cause=16
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >
>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com
>
>> > wrote:
>> >>
>> >> You would want to check the SDP of 200 OK the provider sends
for your
>> >> outgoing call. It will list the payload type for the dtmf in the
>> >> format a=fmtp 101 1-16, or something similar. You want to find
out
>> >> what payload type they are advertising (or if they are at
all). It
>> >> would be worth checking the incoming INVITE from them to see what
>> >> they're using when they send the first SDP.
>> >>
>> >> On that note, I would also remove the asymmetric payload
command - to
>> >> my knowledge it doesn't do what you're expecting it to. You
may want
>> >> to try this command:
>> >> voice-class sip dtmf-relay force rtp-nte
>> >>
>> >>
>> >> -nick
>> >>
>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com
>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I am having an issue with dtmf working outbound. Inbound
dtmf works
>> >> > fine.
>> >> > It took some playing around with it. At first it didnt work
till the
>> >> > payload was ajusted. I am now trying to get outbound dtmf
working
>> >> > properly.
>> >> >
>> >> > On my 2821 I debugged voip rtp session named-events and then
made a
>> >> > call
>> >> > to
>> >> > a 1800 number and hit digits. I didn't see any dtmf output
on the
>> >> > router
>> >> > nothing showed up in the debug. Does this mean I can safely
asume
>> >> > that
>> >> > the
>> >> > problem for right now is not on the ITSP side but on my side
since
>> >> > dtmf
>> >> > is
>> >> > not being sent down the sip trunk?
>> >> >
>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>> >> > configuration
>> >> > of the cisco 2821 is shown below. Does anyone have any ideas
what I
>> >> > can
>> >> > do
>> >> > so dtmf digits process properly outbound?
>> >> >
>> >> > The settings in my cuc 7.x to add the gateway h323 are
>> >> >
>> >> > h323 cucm gateway configuratration
>> >> > Signaling Port 1720
>> >> > media termination point required yes
>> >> > retry video call as auto yes
>> >> > wait for far end h.245 terminal capability set yes
>> >> > transmit utf-8 calling party name no
>> >> > h.235 pass through allowed no
>> >> > significant digits all
>> >> > redirect number IT deliver - inbound no
>> >> > enable inbound faststart yes
>> >> > display IE deliver no
>> >> > redirect nunmber IT deliver - outbound no
>> >> > enable outbound faststart yes
>> >> >
>> >> >
>> >> > voice service voip
>> >> > allow-connections h323 to h323
>> >> > allow-connections h323 to sip
>> >> > allow-connections sip to h323
>> >> > allow-connections sip to sip
>> >> > fax protocol pass-through g711ulaw
>> >> > h323
>> >> > emptycapability
>> >> > h225 id-passthru
>> >> > h245 passthru tcsnonstd-passthru
>> >> > sip
>> >> >
>> >> >
>> >> > voice class h323 50
>> >> > h225 timeout tcp establish 3
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > voice translation-rule 1
>> >> > rule 1 /.*/ /190/
>> >> > !
>> >> > voice translation-rule 2
>> >> > rule 1 /.*/ /1&/
>> >> > !
>> >> > !
>> >> > voice translation-profile aa
>> >> > translate called 1
>> >> > !
>> >> > voice translation-profile addone
>> >> > translate called 2
>> >> > !
>> >> > !
>> >> > voice-card 0
>> >> > dspfarm
>> >> > dsp services dspfarm
>> >> > !
>> >> > !
>> >> > sccp local GigabitEthernet0/1
>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>> >> > sccp
>> >> > !
>> >> > sccp ccm group 1
>> >> > associate ccm 1 priority 1
>> >> > associate ccm 2 priority 2
>> >> > associate profile 1 register 2821transcode
>> >> > !
>> >> > dspfarm profile 1 transcode
>> >> > codec g711ulaw
>> >> > codec g711alaw
>> >> > codec g729ar8
>> >> > codec g729abr8
>> >> > codec g729r8
>> >> > maximum sessions 4
>> >> > associate application SCCP
>> >> > !
>> >> > !
>> >> > dial-peer voice 100 voip
>> >> > description AA Publisher
>> >> > preference 1
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.10
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 1000 voip
>> >> > description incoming Call
>> >> > translation-profile incoming aa
>> >> > preference 1
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > incoming called-number 6782282221
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > ip qos dscp cs5 media
>> >> > ip qos dscp cs5 signaling
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 101 voip
>> >> > description AA Subscriber
>> >> > preference 2
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.11
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 2000 voip
>> >> > description outbound
>> >> > translation-profile outgoing addone
>> >> > preference 1
>> >> > destination-pattern .T
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > voice-class sip asymmetric payload dtmf
>> >> > session protocol sipv2
>> >> > session target ipv4:64.154.41.200
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > !
>> >> > sip-ua
>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net
>> >> > authentication username ***** password 7 *****
>> >> > authentication username ***** password 7 ***** realm
>> >> > sip.talkinip.net
>> >> > set pstn-cause 3 sip-status 486
>> >> > set pstn-cause 34 sip-status 486
>> >> > set pstn-cause 47 sip-status 486
>> >> > registrar dns:sip.talkinip.net expires 60
>> >> > sip-server dns:sip.talkinip.net:5060
>> >> > _______________________________________________
>> >> > cisco-voip mailing list
>> >> > cisco-voip at puck.nether.net
>> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >
>> >> >
>> >
>> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/6fcf0fb2/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 27 Oct 2009 11:41:24 -0600
From: "Norton, Mike" <mikenorton at pwsd76.ab.ca>
To: "Jason Aarons (US)" <jason.aarons at us.didata.com>,
"cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] FXO port Attendant DN won't ring Hunt Pilot
Message-ID:
<096D50507635B645A061351B1308C90B01EFB3245D at pwsdexchange03.pwsb33.ab.ca>
Content-Type: text/plain; charset="us-ascii"
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.
--
Mike Norton
I.T. Support
Peace Wapiti School Division No. 76
Helpdesk: 780-831-3080
Direct: 780-831-3076
From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Jason Aarons (US)
Sent: October-26-09 2:00 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] FXO port Attendant DN won't ring Hunt Pilot
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.
Is this a feature or a bug?
________________________________
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/ed4ff56f/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 27 Oct 2009 14:10:35 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Ryan Ratliff <rratliff at cisco.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID: <4B18CB48-6FE5-4ACF-8D2A-86E267B63193 at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
Sorry this part is the actual DTMF:
a=rtpmap:101 telephone-event/8000
The line you quoted is part of the SDP and references both RTP and DTMF.
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
The fist line means your RTP is on port 11680 and references the
a:rtpmap entries for 0 and 101.
The second line means your RTP is g.711.
The 3rd line is the DTMF with a payload type of 101.
The 4th line means it can accept DTMF 0-16
The last line is pretty self explanatory (silence suppression disabled).
This is a very basic interpretation of the SDP info. RFC 2327 is
where you want to go to get into the nitty-gritty details.
-Ryan
On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
That is RFC2833 DTMF with a payload type of 101.
I do know that CUBE cannot do dynamic RFC2833 payload types. It can
only send the payloadType defined in the voip dial-peer. So if
inbound calls use a different payloadType than outbound calls you will
want to update the dial-peers accordingly.
-Ryan
On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
Well I tried to switch providers just to test it out and now I am
getting something back in the 183 but still no dtmf hmm
I see they are sending me
m=audio 11680 RTP/AVP 0 101
How do I interperate that line?
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57
From: <sip:6782282221 at did.voip.les.net>;tag=419FE94-8A1
To: <sip:18774675464 at did.voip.les.net>;tag=as5677a12c
Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
CSeq: 101 INVITE
User-Agent: LES.NET.VoIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:18774675464 at 64.34.181.47>
Content-Type: application/sdp
Content-Length: 214
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX
*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
No GTD found in inbound container
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoMediaNegotiation: Number of m-lines = 1
SIP: Attribute mid, level 1 instance 1 not found.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
resolve_media_ip_address_to_bind: Media already bound, use existing
source_media_ip_addr
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/
sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on
Static Payload for m-line 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoPtimeNegotiation: No ptime present or multiple ptime
attributes that can't be handled
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: m-line index 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
fmtp list of events.
*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/
sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem
relay
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIGetSDPDirectionAttribute: No direction attribute present or
multiple direction attributes that can't be handled for m-line:1 and
num-a-lines:0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
payload_type=0, codec_bytes=160, codec=g711ulaw,
dtmf_relay=rtp-nte
stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
dest_port=11680
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/
sipSPIChangeStreamState: Stream (callid = -1) State changed from
(STREAM_DEAD) to (STREAM_ADDING)
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/
sipSPIUpdCallWithSdpInfo:
Preferred Codec : g711ulaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>
wrote:
The 200 OK that you've pasted is confirming the CANCEL that we sent.
You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
a 200 OK with the CSeq for 101 INVITE.
I've seen this for certain IVRs/providers - sometimes they don't
properly terminate a call with a 200 OK. If you were not sending an
SDP in your original INVITE, then you would need the PRACK setting
mentioned. You have two problems, either could fix the problem: They
could advertise DTMF in their 183, or they could send you a 200 OK for
the call. It is assumed you would get DTMF in the 200 OK. It's
common for endpoints that support DTMF to not advertise it in the 183
because you technically shouldn't need DTMF to hear ringback.
-nick
On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
wrote:
> There is no SDP in that 200 OK so I would assume the media info is
the same
> as in the 183 Ringing message. You really need your ITSP to tell
you what
> dtmf method they want you to use on your outbound calls. As Nick
said they
> don't appear to be advertising any dtmf method at all.
> -Ryan
> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
> Is the below the ok I should be getting?
>
>
> They did send this with the first debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
> From: <sip:6782282221 at sip.talkinip.net>;tag=32DA608-109A
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> This with the 2nd debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 487 Request Terminated
> To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> Contact: <sip:18774675464 at 64.154.41.200:5060>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 INVITE
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> Content-Length: 0
>
> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews
<matthnick at gmail.com> wrote:
>>
>> In the 183 Session Progress they're not advertising DTMF:
>>
>> m=audio 45846 RTP/AVP 0
>>
>> There should be a 100 or 101 there. Although, 183 is just ringback.
>> You would want to pick up on the other side and they should send a
200
>> OK with a new SDP. If the other side did pick up, you need to tell
>> the provider that they need to send a 200 OK, because they're not.
>>
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Nick
>> >
>> > I removed voice-class sip asymmetric payload dtmf and added in
the
>> > other
>> > line
>> >
>> > Just to state incoming dtmf works but not outbound the ITSP has
told me
>> > they
>> > are using two different sip servers/vendors for processing
inbound and
>> > outbound
>> > How does this translate into what I should sent the following too?
>> >
>> > rtp payload-type nse
>> > rtp payload-type nte
>> >
>> > In the debug trhe following where set
>> >
>> > rtp payload-type nse 101
>> > rtp payload-type nte 100
>> >
>> > In the debug of ccsip If I am looking at it correctly I see me
sending
>> > this
>> >
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>> > Preferred method of dtmf relay is: 6, with payload: 100
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>> > max_event 15
>> >
>> > and
>> >
>> >
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> >
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 101 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> >
>> >
>> > Then when I do a search for fmtp again further down I see
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 102 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Proxy-Authorization: Digest
>> >
>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464 at 64.154.41.200:5060
",response
=
"ab63d4755ff4182631ad2db0f9ed0e44
",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 100 Trying
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Length: 0
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE) to
>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 183 Session Progress
>> > To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Type: application/sdp
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Content-Length: 146
>> > v=0
>> > o=msx71 490 6110 IN IP4 64.154.41.200
>> > s=sip call
>> > c=IN IP4 64.154.41.101
>> > t=0 0
>> > m=audio 45846 RTP/AVP 0
>> > a=ptime:20
>> > a=rtpmap:0 PCMU/8000
>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentGTD: No
>> > GTD
>> > found in inbound container
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>> > Number of m-lines = 1
>> > SIP: Attribute mid, level 1 instance 1 not found.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-
line 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>> > One ptime attribute found - value:20
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes:
Values :Codec:
>> > g711ulaw ptime :20, codecbytes: 160
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes:
160 for
>> > codec
>> > g711ulaw
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
index 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>> > Dynamic payload(100) could not be reserved.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case
of full
>> > named
>> > event(NE) match in fmtp list of events.
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
direction
>> > attribute present or multiple direction attributes that can't be
handled
>> > for
>> > m-line:1 and num-a-lines:0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec negotiation successful for media line 1
>> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>> > dtmf_relay=rtp-nte
>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>> > dest_port=45846
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>> > (STREAM_ADDING)
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Preferred Codec : g711ulaw, bytes :160
>> > Preferred DTMF relay : rtp-nte
>> > Preferred NTE payload : 100
>> > Early Media : No
>> > Delayed Media : No
>> > Bridge Done : No
>> > New Media : No
>> > DSP DNLD Reqd : No
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4A170B28)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Hndl ptype 0 mline 1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Selecting
>> > codec g711ulaw
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>> > Codec to be matched: 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
ADD
>> > AUDIO
>> > CODEC 5
>> > *Oct 27 12:34:10.840:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Media
>> > negotiation done:
>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
coverted
>> > ptime=20 stream->mline_index=1, media_ndx=1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1
ss 1
>> > 64.154.41.101:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > Report initial call media
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
ccb->flags
>> > 0x400018, ccb->pld.flags_ipip 0x200005
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4DEC000C)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>> > 5030: Posting Remote SRTP caps to other callleg.
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>> > cc_api_caps_ind()
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Stream type : voice+dtmf
>> > Media line : 1
>> > State : STREAM_ADDING (2)
>> > Stream address type : 1
>> > Callid : 846
>> > Negotiated Codec : g711ulaw, bytes :160
>> > Nego. Codec payload : 0 (tx), 0 (rx)
>> > Negotiated DTMF relay : rtp-nte
>> > Negotiated NTE payload : 100 (tx), 100 (rx)
>> > Negotiated CN payload : 0
>> > Media Srce Addr/Port : [173.14.220.57]:16462
>> > Media Dest Addr/Port : [64.154.41.101]:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>> > headers
>> > recvd from app container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQSIG:
>> > No
>> > QSIG Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQ931:
>> > No
>> > RawMsg Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPICreateNewRawMsg:
>> > No
>> > Data to form The Raw Message
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>> > SUBSTATE_NONE)
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
Transaction
>> > Complete. Lock on Facilities released.
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
confID =
>> > 6,
>> > srcCallID = 846, dstCallID = 845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old streamcallid=846, new streamcallid=846
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>> > Setting SPI mode to SIP-H323
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
1131891908
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>> > sipSPIProcessRtpSessions
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/
sipSPIAddStream:
>> > Adding
>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > sipSPIUpdateRtcpSession for m-line 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > rtcp_session info
>> > laddr = 173.14.220.57, lport = 16462, raddr =
64.154.41.101,
>> > rport=45846, do_rtcp=TRUE
>> > src_callid = 846, dest_callid = 845, stream type = voice
+dtmf,
>> > stream direction = SENDRECV
>> > media_ip_addr = 64.154.41.101, vrf tableid = 0
media_addr_type =
>> > 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > RTP session already created - update
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>> > New Remote Media Direction = SENDRECV
>> > Present Local Media Direction = SENDRECV
>> > New Local Media Direction = SENDRECV
>> > retVal = 0
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>> > (STREAM_ACTIVE)
>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
really
>> > can't
>> > find peer_stream for
>> > dtmf-relay
interworking
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x23ED
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Setting
>> > CAPS_RECEIVED flag
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Calling
>> > cc_api_caps_ack()
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ack: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Second
>> > TCS
>> > received for transfers across trunk - set CAPS2_RECEIVED
>> > *Oct 27 12:34:15.876:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/
ccsip_call_statistics:
>> > Stats are not supported for IPIP call.
>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>> > Queued
>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 3 for event 7
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/
sipSPISendCancel:
>> > Associated container=0x4E310C1C to Cancel
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/
sipSPISendCancel:
>> > Sending CANCEL to the transport layer
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> > msg=0x4DF0D994,
>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,
transport=1,
>> > switch=0, callBack=0x419703BC
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
Proceedable
>> > for
>> > sending msg immediately
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>> > transport
>> > is 0
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set
to send
>> > the
>> > msg=0x4DF0D994
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:
Posting
>> > send
>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for
UDP
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>> > Sent Cancel Request, starting CancelWaitResponseTimer
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_NONE)
>> > to
>> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Sent:
>> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Max-Forwards: 70
>> > Timestamp: 1256646855
>> > Reason: Q.850;cause=16
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >
>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com
>
>> > wrote:
>> >>
>> >> You would want to check the SDP of 200 OK the provider sends
for your
>> >> outgoing call. It will list the payload type for the dtmf in the
>> >> format a=fmtp 101 1-16, or something similar. You want to find
out
>> >> what payload type they are advertising (or if they are at
all). It
>> >> would be worth checking the incoming INVITE from them to see what
>> >> they're using when they send the first SDP.
>> >>
>> >> On that note, I would also remove the asymmetric payload
command - to
>> >> my knowledge it doesn't do what you're expecting it to. You
may want
>> >> to try this command:
>> >> voice-class sip dtmf-relay force rtp-nte
>> >>
>> >>
>> >> -nick
>> >>
>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com
>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I am having an issue with dtmf working outbound. Inbound
dtmf works
>> >> > fine.
>> >> > It took some playing around with it. At first it didnt work
till the
>> >> > payload was ajusted. I am now trying to get outbound dtmf
working
>> >> > properly.
>> >> >
>> >> > On my 2821 I debugged voip rtp session named-events and then
made a
>> >> > call
>> >> > to
>> >> > a 1800 number and hit digits. I didn't see any dtmf output
on the
>> >> > router
>> >> > nothing showed up in the debug. Does this mean I can safely
asume
>> >> > that
>> >> > the
>> >> > problem for right now is not on the ITSP side but on my side
since
>> >> > dtmf
>> >> > is
>> >> > not being sent down the sip trunk?
>> >> >
>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>> >> > configuration
>> >> > of the cisco 2821 is shown below. Does anyone have any ideas
what I
>> >> > can
>> >> > do
>> >> > so dtmf digits process properly outbound?
>> >> >
>> >> > The settings in my cuc 7.x to add the gateway h323 are
>> >> >
>> >> > h323 cucm gateway configuratration
>> >> > Signaling Port 1720
>> >> > media termination point required yes
>> >> > retry video call as auto yes
>> >> > wait for far end h.245 terminal capability set yes
>> >> > transmit utf-8 calling party name no
>> >> > h.235 pass through allowed no
>> >> > significant digits all
>> >> > redirect number IT deliver - inbound no
>> >> > enable inbound faststart yes
>> >> > display IE deliver no
>> >> > redirect nunmber IT deliver - outbound no
>> >> > enable outbound faststart yes
>> >> >
>> >> >
>> >> > voice service voip
>> >> > allow-connections h323 to h323
>> >> > allow-connections h323 to sip
>> >> > allow-connections sip to h323
>> >> > allow-connections sip to sip
>> >> > fax protocol pass-through g711ulaw
>> >> > h323
>> >> > emptycapability
>> >> > h225 id-passthru
>> >> > h245 passthru tcsnonstd-passthru
>> >> > sip
>> >> >
>> >> >
>> >> > voice class h323 50
>> >> > h225 timeout tcp establish 3
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > voice translation-rule 1
>> >> > rule 1 /.*/ /190/
>> >> > !
>> >> > voice translation-rule 2
>> >> > rule 1 /.*/ /1&/
>> >> > !
>> >> > !
>> >> > voice translation-profile aa
>> >> > translate called 1
>> >> > !
>> >> > voice translation-profile addone
>> >> > translate called 2
>> >> > !
>> >> > !
>> >> > voice-card 0
>> >> > dspfarm
>> >> > dsp services dspfarm
>> >> > !
>> >> > !
>> >> > sccp local GigabitEthernet0/1
>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>> >> > sccp
>> >> > !
>> >> > sccp ccm group 1
>> >> > associate ccm 1 priority 1
>> >> > associate ccm 2 priority 2
>> >> > associate profile 1 register 2821transcode
>> >> > !
>> >> > dspfarm profile 1 transcode
>> >> > codec g711ulaw
>> >> > codec g711alaw
>> >> > codec g729ar8
>> >> > codec g729abr8
>> >> > codec g729r8
>> >> > maximum sessions 4
>> >> > associate application SCCP
>> >> > !
>> >> > !
>> >> > dial-peer voice 100 voip
>> >> > description AA Publisher
>> >> > preference 1
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.10
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 1000 voip
>> >> > description incoming Call
>> >> > translation-profile incoming aa
>> >> > preference 1
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > incoming called-number 6782282221
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > ip qos dscp cs5 media
>> >> > ip qos dscp cs5 signaling
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 101 voip
>> >> > description AA Subscriber
>> >> > preference 2
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.11
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 2000 voip
>> >> > description outbound
>> >> > translation-profile outgoing addone
>> >> > preference 1
>> >> > destination-pattern .T
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > voice-class sip asymmetric payload dtmf
>> >> > session protocol sipv2
>> >> > session target ipv4:64.154.41.200
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > !
>> >> > sip-ua
>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net
>> >> > authentication username ***** password 7 *****
>> >> > authentication username ***** password 7 ***** realm
>> >> > sip.talkinip.net
>> >> > set pstn-cause 3 sip-status 486
>> >> > set pstn-cause 34 sip-status 486
>> >> > set pstn-cause 47 sip-status 486
>> >> > registrar dns:sip.talkinip.net expires 60
>> >> > sip-server dns:sip.talkinip.net:5060
>> >> > _______________________________________________
>> >> > cisco-voip mailing list
>> >> > cisco-voip at puck.nether.net
>> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >
>> >> >
>> >
>> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1e0e0070/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 27 Oct 2009 13:35:19 -0500
From: "Jeff Ruttman" <ruttmanj at carewisc.org>
To: "Cisco VOIP Newsletter - puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: [cisco-voip] Interpret CDR Search Results
Message-ID:
<07365C3161D8D8419EE51C3834C02205B84F06 at ma1-exc01.ec2802.elderc.org>
Content-Type: text/plain; charset="us-ascii"
Greetings,
In the results of a CDR Search by Extension, I see entries like these:
Sl No Call Type GCID CMId
GCID CallId Orig Node Id
Dest Node Id Orig Leg Id
Dest Leg Id Calling No
Calling No Partition Called No
Called No Partition Dest No
Dest No Partition Last Rd No
Last Rd No Partition Media Info
Orig Pkts Rcd Dest Pkts Rcd
Orig Pkts Lost Dest Pkts Lost
CDR - CMR Dump
33 Simple 3
2155334 3
0 50453618
50453619 6174
Phones null
null null
null null
null null null Others
<javascript:fnDetails('Others',13)>
null null View <javascript:fnDetails('View',13)>
24 Simple 3
2155266 3
3 50453393
50453394 null
null 6174
Phones 6174
Phones 6174
Phones 2954 null Others
<javascript:fnDetails('Others',4)>
0 null View <javascript:fnDetails('View',4)>
What do these mean? The first one I can reproduce by going off hook and
waiting for dial tone to time out. Is that all such an entry could
mean? What about the second one?
Thanks
jeff
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/40cdc442/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 27 Oct 2009 14:42:28 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Jeff Ruttman <ruttmanj at carewisc.org>
Cc: "Cisco VOIP Newsletter - puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Interpret CDR Search Results
Message-ID: <13323F5E-5CEB-4E7B-8BE0-2199CF7221EE at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
Take a look at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html
.
The first one you can correlate by the fact that there is no called
party number and the lack of any media information.
The second one was a call to your phone that seems to have no calling
party number and only partial media information.
You can take the GCID and search CCM traces to find more info if you
really want.
-Ryan
On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:
Greetings,
In the results of a CDR Search by Extension, I see entries like these:
Sl No Call Type GCID CMId
GCID CallId Orig Node Id
Dest Node Id Orig Leg Id
Dest Leg Id Calling No
Calling No Partition Called No
Called No Partition Dest No
Dest No Partition Last Rd No
Last Rd No Partition
Media Info
Orig Pkts Rcd Dest Pkts Rcd
Orig Pkts Lost Dest Pkts Lost
CDR - CMR Dump
33 Simple 3
2155334 3
0 50453618
50453619 6174
Phones null
null null
null null
null null null Others
null null View
24 Simple 3
2155266 3
3 50453393
50453394 null
null 6174
Phones 6174
Phones 6174
Phones 2954 null Others
0 null View
What do these mean? The first one I can reproduce by going off hook
and waiting for dial tone to time out. Is that all such an entry
could mean? What about the second one?
Thanks
jeff
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.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/a6ce6439/attachment-0001.html>
------------------------------
Message: 12
Date: Tue, 27 Oct 2009 14:48:21 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Ryan Ratliff <rratliff at cisco.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271148tecac9e4u2c7dcb406d95b964 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The difference I see between the invite and the 183 session progression from
the telco is
invite
a=fmtp:101 0-15
session progression
a=fmtp:101 0-16
Could this miss match in supported digits be what is causing all dtmf not to
work? How can I make my cisco router support 0-16?
Dane
*Invite*
**
**
v=0
o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57
s=SIP Call
c=IN IP4 173.14.220.57
t=0 0
m=audio 18770 RTP/AVP 0 101 19
c=IN IP4 173.14.220.57
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
*session progression*
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 17646 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> Sorry this part is the actual DTMF:
>
> a=rtpmap:101 telephone-event/8000
>
> The line you quoted is part of the SDP and references both RTP and DTMF.
> m=audio 11680 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
>
> The fist line means your RTP is on port 11680 and references the a:rtpmap
> entries for 0 and 101.
> The second line means your RTP is g.711.
> The 3rd line is the DTMF with a payload type of 101.
> The 4th line means it can accept DTMF 0-16
> The last line is pretty self explanatory (silence suppression disabled).
>
> This is a very basic interpretation of the SDP info. RFC 2327 is where you
> want to go to get into the nitty-gritty details.
>
> -Ryan
>
> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
>
> That is RFC2833 DTMF with a payload type of 101.
>
> I do know that CUBE cannot do dynamic RFC2833 payload types. It can only
> send the payloadType defined in the voip dial-peer. So if inbound calls use
> a different payloadType than outbound calls you will want to update the
> dial-peers accordingly.
>
>
> -Ryan
>
> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
>
> Well I tried to switch providers just to test it out and now I am getting
> something back in the 183 but still no dtmf hmm
>
> I see they are sending me
>
> m=audio 11680 RTP/AVP 0 101
>
> How do I interperate that line?
>
>
> Received:
> SIP/2.0 183 Session Progress
> Via: SIP/2.0/UDP 173.14.220.57:5060
> ;branch=z9hG4bK749136B;received=173.14.220.57
> From: <sip:6782282221 at did.voip.les.net <sip%3A6782282221 at did.voip.les.net>
> >;tag=419FE94-8A1
> To: <sip:18774675464 at did.voip.les.net <sip%3A18774675464 at did.voip.les.net>
> >;tag=as5677a12c
> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
> CSeq: 101 INVITE
> User-Agent: LES.NET.VoIP
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
> Contact: <sip:18774675464 at 64.34.181.47 <sip%3A18774675464 at 64.34.181.47>>
> Content-Type: application/sdp
> Content-Length: 214
> v=0
> o=root 5115 5115 IN IP4 64.34.181.47
> s=session
> c=IN IP4 64.34.181.47
> t=0 0
> m=audio 11680 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:
> INVITE response with no RSEQ - disable IS_REL1XX
> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No
> GTD found in inbound container
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation: Number of m-lines = 1
> SIP: Attribute mid, level 1 instance 1 not found.
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already
> bound, use existing source_media_ip_addr
> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:
> Media src addr for stream 1 = 173.14.220.57
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)
> Negotiation Successful on Static Payload for m-line 1
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or
> multiple ptime attributes that can't be handled
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)
> could not be reserved.
> *Oct 27 18:02:12.551:
> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
> relay option
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
> named event(NE) match in fmtp list of events.
> *Oct 27 18:02:12.555:
> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
> from X-cap = 0
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not
> present in SDP. Disable modem relay
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction
> attribute present or multiple direction attributes that can't be handled for
> m-line:1 and num-a-lines:0
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation
> successful for media line 1
> payload_type=0, codec_bytes=160, codec=g711ulaw, dtmf_relay=rtp-nte
> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
> dest_port=11680
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =
> -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)
> *Oct 27 18:02:12.555:
> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:
> Preferred Codec : g711ulaw, bytes :160
> Preferred DTMF relay : rtp-nte
> Preferred NTE payload : 101
> Early Media : No
> Delayed Media : No
> Bridge Done : No
> New Media : No
> DSP DNLD Reqd : No
>
> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>wrote:
>
>> The 200 OK that you've pasted is confirming the CANCEL that we sent.
>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
>> a 200 OK with the CSeq for 101 INVITE.
>>
>> I've seen this for certain IVRs/providers - sometimes they don't
>> properly terminate a call with a 200 OK. If you were not sending an
>> SDP in your original INVITE, then you would need the PRACK setting
>> mentioned. You have two problems, either could fix the problem: They
>> could advertise DTMF in their 183, or they could send you a 200 OK for
>> the call. It is assumed you would get DTMF in the 200 OK. It's
>> common for endpoints that support DTMF to not advertise it in the 183
>> because you technically shouldn't need DTMF to hear ringback.
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com> wrote:
>> > There is no SDP in that 200 OK so I would assume the media info is the
>> same
>> > as in the 183 Ringing message. You really need your ITSP to tell you
>> what
>> > dtmf method they want you to use on your outbound calls. As Nick said
>> they
>> > don't appear to be advertising any dtmf method at all.
>> > -Ryan
>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
>> > Is the below the ok I should be getting?
>> >
>> >
>> > They did send this with the first debug
>> >
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=32DA608-109A
>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
>> > *Oct 27 13:44:12.836:
>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 13:44:12.840:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 13:44:12.840:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 13:44:12.840:
>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >
>> > This with the 2nd debug
>> >
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> > *Oct 27 12:34:15.912:
>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.912:
>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 487 Request Terminated
>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >;tag=3465630735-938664
>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Content-Length: 0
>> >
>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <matthnick at gmail.com>
>> wrote:
>> >>
>> >> In the 183 Session Progress they're not advertising DTMF:
>> >>
>> >> m=audio 45846 RTP/AVP 0
>> >>
>> >> There should be a 100 or 101 there. Although, 183 is just ringback.
>> >> You would want to pick up on the other side and they should send a 200
>> >> OK with a new SDP. If the other side did pick up, you need to tell
>> >> the provider that they need to send a 200 OK, because they're not.
>> >>
>> >>
>> >> -nick
>> >>
>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>> >> wrote:
>> >> > Nick
>> >> >
>> >> > I removed voice-class sip asymmetric payload dtmf and added in the
>> >> > other
>> >> > line
>> >> >
>> >> > Just to state incoming dtmf works but not outbound the ITSP has told
>> me
>> >> > they
>> >> > are using two different sip servers/vendors for processing inbound
>> and
>> >> > outbound
>> >> > How does this translate into what I should sent the following too?
>> >> >
>> >> > rtp payload-type nse
>> >> > rtp payload-type nte
>> >> >
>> >> > In the debug trhe following where set
>> >> >
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> >
>> >> > In the debug of ccsip If I am looking at it correctly I see me
>> sending
>> >> > this
>> >> >
>> >> > *Oct 27 12:34:09.128:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>> >> > Preferred method of dtmf relay is: 6, with payload: 100
>> >> > *Oct 27 12:34:09.128:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>> >> > max_event 15
>> >> >
>> >> > and
>> >> >
>> >> >
>> >> > *Oct 27 12:34:10.836:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> >> > payload
>> >> > from X-cap = 0
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
>> >> > present
>> >> > in SDP. Disable modem relay
>> >> >
>> >> >
>> >> > Sent:
>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>> >> > Remote-Party-ID:
>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>> >;party=calling;screen=yes;privacy=off
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >
>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> >> > Min-SE: 1800
>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> >> > SUBSCRIBE,
>> >> > NOTIFY, INFO, REGISTER
>> >> > CSeq: 101 INVITE
>> >> > Max-Forwards: 70
>> >> > Timestamp: 1256646849
>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> >> > Expires: 180
>> >> > Allow-Events: telephone-event
>> >> > Content-Type: application/sdp
>> >> > Content-Disposition: session;handling=required
>> >> > Content-Length: 250
>> >> > v=0
>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> >> > s=SIP Call
>> >> > c=IN IP4 173.14.220.57
>> >> > t=0 0
>> >> > m=audio 16462 RTP/AVP 0 100
>> >> > c=IN IP4 173.14.220.57
>> >> > a=rtpmap:0 PCMU/8000
>> >> > a=rtpmap:100 telephone-event/8000
>> >> > a=fmtp:100 0-15
>> >> > a=ptime:20
>> >> >
>> >> >
>> >> > Then when I do a search for fmtp again further down I see
>> >> >
>> >> > Sent:
>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> >> > Remote-Party-ID:
>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>> >;party=calling;screen=yes;privacy=off
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >
>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> >> > Min-SE: 1800
>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> >> > SUBSCRIBE,
>> >> > NOTIFY, INFO, REGISTER
>> >> > CSeq: 102 INVITE
>> >> > Max-Forwards: 70
>> >> > Timestamp: 1256646849
>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> >> > Expires: 180
>> >> > Allow-Events: telephone-event
>> >> > Proxy-Authorization: Digest
>> >> >
>> >> > username="1648245954",realm="64.154.41.110",uri="
>> sip:18774675464 at 64.154.41.200:5060
>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>> >> > Content-Type: application/sdp
>> >> > Content-Disposition: session;handling=required
>> >> > Content-Length: 250
>> >> > v=0
>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> >> > s=SIP Call
>> >> > c=IN IP4 173.14.220.57
>> >> > t=0 0
>> >> > m=audio 16462 RTP/AVP 0 100
>> >> > c=IN IP4 173.14.220.57
>> >> > a=rtpmap:0 PCMU/8000
>> >> > a=rtpmap:100 telephone-event/8000
>> >> > a=fmtp:100 0-15
>> >> > a=ptime:20
>> >> > *Oct 27 12:34:09.332:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> >> > *Oct 27 12:34:09.332:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>> >> > *Oct 27 12:34:09.332:
>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> >> > context=0x00000000
>> >> > *Oct 27 12:34:09.332:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> >> > Checking Invite Dialog
>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >> > Received:
>> >> > SIP/2.0 100 Trying
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > CSeq: 102 INVITE
>> >> > Content-Length: 0
>> >> > *Oct 27 12:34:09.332:
>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>> >> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/sipSPIChangeState:
>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to
>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>> >> > *Oct 27 12:34:10.832:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> >> > *Oct 27 12:34:10.832:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>> >> > *Oct 27 12:34:10.832:
>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> >> > context=0x00000000
>> >> > *Oct 27 12:34:10.836:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> >> > Checking Invite Dialog
>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >> > Received:
>> >> > SIP/2.0 183 Session Progress
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >;tag=3465630735-938664
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > CSeq: 102 INVITE
>> >> > Content-Type: application/sdp
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> >> > Content-Length: 146
>> >> > v=0
>> >> > o=msx71 490 6110 IN IP4 64.154.41.200
>> >> > s=sip call
>> >> > c=IN IP4 64.154.41.101
>> >> > t=0 0
>> >> > m=audio 45846 RTP/AVP 0
>> >> > a=ptime:20
>> >> > a=rtpmap:0 PCMU/8000
>> >> > *Oct 27 12:34:10.836:
>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
>> No
>> >> > GTD
>> >> > found in inbound container
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>> >> > Number of m-lines = 1
>> >> > SIP: Attribute mid, level 1 instance 1 not found.
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>> >> > already
>> >> > bound, use existing source_media_ip_addr
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> >> > Media src addr for stream 1 = 173.14.220.57
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line
>> 1
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>> >> > One ptime attribute found - value:20
>> >> > *Oct 27 12:34:10.836:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values
>> :Codec:
>> >> > g711ulaw ptime :20, codecbytes: 160
>> >> > *Oct 27 12:34:10.836:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>> :Codec:
>> >> > g711ulaw codecbytes :160, ptime: 20
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160 for
>> >> > codec
>> >> > g711ulaw
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
>> index 1
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>> >> > Dynamic payload(100) could not be reserved.
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of
>> full
>> >> > named
>> >> > event(NE) match in fmtp list of events.
>> >> > *Oct 27 12:34:10.836:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> >> > payload
>> >> > from X-cap = 0
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
>> >> > present
>> >> > in SDP. Disable modem relay
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
>> direction
>> >> > attribute present or multiple direction attributes that can't be
>> handled
>> >> > for
>> >> > m-line:1 and num-a-lines:0
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> >> > Codec negotiation successful for media line 1
>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>> >> > dtmf_relay=rtp-nte
>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>> >> > dest_port=45846
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>> >> > (STREAM_ADDING)
>> >> > *Oct 27 12:34:10.836:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> >> > Preferred Codec : g711ulaw, bytes :160
>> >> > Preferred DTMF relay : rtp-nte
>> >> > Preferred NTE payload : 100
>> >> > Early Media : No
>> >> > Delayed Media : No
>> >> > Bridge Done : No
>> >> > New Media : No
>> >> > DSP DNLD Reqd : No
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>> >> > already
>> >> > bound, use existing source_media_ip_addr
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> >> > Media src addr for stream 1 = 173.14.220.57
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> >> > callId 846 size 240 ptr 0x4A170B28)
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> >> > Hndl ptype 0 mline 1
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> >> > Selecting
>> >> > codec g711ulaw
>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>> >> > Codec to be matched: 5
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD
>> >> > AUDIO
>> >> > CODEC 5
>> >> > *Oct 27 12:34:10.840:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>> :Codec:
>> >> > g711ulaw codecbytes :160, ptime: 20
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> Media
>> >> > negotiation done:
>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
>> coverted
>> >> > ptime=20 stream->mline_index=1, media_ndx=1
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1
>> >> > 64.154.41.101:45846
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy
>> >> > sdp to
>> >> > channel- AFTER CODEC FILTERING:
>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: Copy
>> >> > sdp to
>> >> > channel- AFTER CODEC FILTERING:
>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> >> > Report initial call media
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> ccb->flags
>> >> > 0x400018, ccb->pld.flags_ipip 0x200005
>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> >> > callId 846 size 240 ptr 0x4DEC000C)
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>> >> > 5030: Posting Remote SRTP caps to other callleg.
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>> >> > cc_api_caps_ind()
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> >> > Stream type : voice+dtmf
>> >> > Media line : 1
>> >> > State : STREAM_ADDING (2)
>> >> > Stream address type : 1
>> >> > Callid : 846
>> >> > Negotiated Codec : g711ulaw, bytes :160
>> >> > Nego. Codec payload : 0 (tx), 0 (rx)
>> >> > Negotiated DTMF relay : rtp-nte
>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)
>> >> > Negotiated CN payload : 0
>> >> > Media Srce Addr/Port : [173.14.220.57]:16462
>> >> > Media Dest Addr/Port : [64.154.41.101]:45846
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>> >> > headers
>> >> > recvd from app container
>> >> > *Oct 27 12:34:10.840:
>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:
>> >> > No
>> >> > QSIG Body found in inbound container
>> >> > *Oct 27 12:34:10.840:
>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:
>> >> > No
>> >> > RawMsg Body found in inbound container
>> >> > *Oct 27 12:34:10.840:
>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:
>> >> > No
>> >> > Data to form The Raw Message
>> >> > *Oct 27 12:34:10.840:
>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/sipSPIChangeState:
>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>> >> > SUBSTATE_NONE)
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction
>> >> > Complete. Lock on Facilities released.
>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> confID =
>> >> > 6,
>> >> > srcCallID = 846, dstCallID = 845
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> >> > Old streamcallid=846, new streamcallid=846
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>> >> > Setting SPI mode to SIP-H323
>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc = 1131891908
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>> >> > sipSPIProcessRtpSessions
>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:
>> >> > Adding
>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>> >> > already
>> >> > bound, use existing source_media_ip_addr
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> >> > Media src addr for stream 1 = 173.14.220.57
>> >> > *Oct 27 12:34:10.844:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> >> > sipSPIUpdateRtcpSession for m-line 1
>> >> > *Oct 27 12:34:10.848:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> >> > rtcp_session info
>> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,
>> >> > rport=45846, do_rtcp=TRUE
>> >> > src_callid = 846, dest_callid = 845, stream type =
>> voice+dtmf,
>> >> > stream direction = SENDRECV
>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0
>> media_addr_type =
>> >> > 1
>> >> > *Oct 27 12:34:10.848:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> >> > RTP session already created - update
>> >> > *Oct 27 12:34:10.848:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> >> > stun is disabled for stream:4A1709F8
>> >> > *Oct 27 12:34:10.848:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>> >> > New Remote Media Direction = SENDRECV
>> >> > Present Local Media Direction = SENDRECV
>> >> > New Local Media Direction = SENDRECV
>> >> > retVal = 0
>> >> > *Oct 27 12:34:10.848:
>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>> >> > (STREAM_ACTIVE)
>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> really
>> >> > can't
>> >> > find peer_stream for
>> >> > dtmf-relay
>> interworking
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Entry
>> >> > *Oct 27 12:34:11.140:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>> CURRENT
>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED
>> >> > *Oct 27 12:34:11.140:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> >> > VALUES:
>> >> > stream_callid=846, current_seq_num=0x11D9
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Load
>> >> > DSP
>> >> > with negotiated codec: g711ulaw, Bytes=160
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set
>> >> > forking flag to 0x0
>> >> > *Oct 27 12:34:11.140:
>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>> payload =
>> >> > 100, tx payload = 100
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> >> > config=0
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Disabling Modem Relay...
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
>> >> > Xcap
>> >> > list
>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Modem
>> >> > Relay & Passthru both disabled
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > nse
>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>> relay=0,
>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> >> > *Oct 27 12:34:11.144:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > 1
>> >> > Active Streams
>> >> > *Oct 27 12:34:11.144:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > Adding stream type (voice+dtmf) from media
>> >> > line 1 codec g711ulaw
>> >> > *Oct 27 12:34:11.144:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> >> > caps.stream_list.xmitFunc=
>> >> > *Oct 27 12:34:11.144:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > voip_rtp_xmit, caps.stream_list.context=
>> >> > *Oct 27 12:34:11.144:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > 0x497E0B60 (gccb)
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Load
>> >> > DSP
>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
>> >> > video
>> >> > caps detected in the caps posted by peer leg
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> >> > Setting
>> >> > CAPS_RECEIVED flag
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> >> > Calling
>> >> > cc_api_caps_ack()
>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack: Set
>> >> > forking flag to 0x0
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Entry
>> >> > *Oct 27 12:34:11.168:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>> CURRENT
>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9
>> >> > *Oct 27 12:34:11.168:
>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> >> > VALUES:
>> >> > stream_callid=846, current_seq_num=0x11D9
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Load
>> >> > DSP
>> >> > with negotiated codec: g711ulaw, Bytes=160
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: Set
>> >> > forking flag to 0x0
>> >> > *Oct 27 12:34:11.168:
>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>> payload =
>> >> > 100, tx payload = 100
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> >> > config=0
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Disabling Modem Relay...
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
>> >> > Xcap
>> >> > list
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > Modem
>> >> > Relay & Passthru both disabled
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>> >> > nse
>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>> relay=0,
>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> >> > *Oct 27 12:34:11.168:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > 1
>> >> > Active Streams
>> >> > *Oct 27 12:34:11.168:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > Adding stream type (voice+dtmf) from media
>> >> > line 1 codec g711ulaw
>> >> > *Oct 27 12:34:11.168:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> >> > caps.stream_list.xmitFunc=
>> >> > *Oct 27 12:34:11.168:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > voip_rtp_xmit, caps.stream_list.context=
>> >> > *Oct 27 12:34:11.168:
>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>> >> > 0x497E0B60 (gccb)
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Load
>> >> > DSP
>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
>> >> > video
>> >> > caps detected in the caps posted by peer leg
>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> Second
>> >> > TCS
>> >> > received for transfers across trunk - set CAPS2_RECEIVED
>> >> > *Oct 27 12:34:15.876:
>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> >> > stun is disabled for stream:4A1709F8
>> >> > *Oct 27 12:34:15.876:
>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:
>> >> > Stats are not supported for IPIP call.
>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>> >> > Queued
>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>> >> > *Oct 27 12:34:15.880:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> >> > ccsip_spi_get_msg_type returned: 3 for event 7
>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:
>> >> > Associated container=0x4E310C1C to Cancel
>> >> > *Oct 27 12:34:15.880:
>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:
>> >> > Sending CANCEL to the transport layer
>> >> > *Oct 27 12:34:15.880:
>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> >> > msg=0x4DF0D994,
>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,
>> >> > switch=0, callBack=0x419703BC
>> >> > *Oct 27 12:34:15.880:
>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> Proceedable
>> >> > for
>> >> > sending msg immediately
>> >> > *Oct 27 12:34:15.880:
>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>> >> > transport
>> >> > is 0
>> >> > *Oct 27 12:34:15.880:
>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to
>> send
>> >> > the
>> >> > msg=0x4DF0D994
>> >> > *Oct 27 12:34:15.880:
>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting
>> >> > send
>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP
>> >> > *Oct 27 12:34:15.880:
>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>> >> > Sent Cancel Request, starting CancelWaitResponseTimer
>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/sipSPIChangeState:
>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING, SUBSTATE_NONE)
>> >> > to
>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >> > Sent:
>> >> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >
>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > CSeq: 102 CANCEL
>> >> > Max-Forwards: 70
>> >> > Timestamp: 1256646855
>> >> > Reason: Q.850;cause=16
>> >> > Content-Length: 0
>> >> > *Oct 27 12:34:15.900:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> >> > *Oct 27 12:34:15.900:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>> >> > *Oct 27 12:34:15.900:
>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> >> > context=0x00000000
>> >> > *Oct 27 12:34:15.900:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> >> > Checking Invite Dialog
>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >> > Received:
>> >> > SIP/2.0 200 OK
>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>> >;tag=2EDA9C8-25D6
>> >> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>> >
>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> >> > CSeq: 102 CANCEL
>> >> > Content-Length: 0
>> >> > *Oct 27 12:34:15.900:
>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> >> > *Oct 27 12:34:15.912:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> >> > *Oct 27 12:34:15.912:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>> >> > *Oct 27 12:34:15.912:
>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> >> > context=0x00000000
>> >> > *Oct 27 12:34:15.912:
>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> >> > Checking Invite Dialog
>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >> >
>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com>
>> >> > wrote:
>> >> >>
>> >> >> You would want to check the SDP of 200 OK the provider sends for
>> your
>> >> >> outgoing call. It will list the payload type for the dtmf in the
>> >> >> format a=fmtp 101 1-16, or something similar. You want to find out
>> >> >> what payload type they are advertising (or if they are at all). It
>> >> >> would be worth checking the incoming INVITE from them to see what
>> >> >> they're using when they send the first SDP.
>> >> >>
>> >> >> On that note, I would also remove the asymmetric payload command -
>> to
>> >> >> my knowledge it doesn't do what you're expecting it to. You may
>> want
>> >> >> to try this command:
>> >> >> voice-class sip dtmf-relay force rtp-nte
>> >> >>
>> >> >>
>> >> >> -nick
>> >> >>
>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com
>> >
>> >> >> wrote:
>> >> >> > Hello,
>> >> >> >
>> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf
>> works
>> >> >> > fine.
>> >> >> > It took some playing around with it. At first it didnt work till
>> the
>> >> >> > payload was ajusted. I am now trying to get outbound dtmf
>> working
>> >> >> > properly.
>> >> >> >
>> >> >> > On my 2821 I debugged voip rtp session named-events and then made
>> a
>> >> >> > call
>> >> >> > to
>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on the
>> >> >> > router
>> >> >> > nothing showed up in the debug. Does this mean I can safely asume
>> >> >> > that
>> >> >> > the
>> >> >> > problem for right now is not on the ITSP side but on my side since
>> >> >> > dtmf
>> >> >> > is
>> >> >> > not being sent down the sip trunk?
>> >> >> >
>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>> >> >> > configuration
>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas what
>> I
>> >> >> > can
>> >> >> > do
>> >> >> > so dtmf digits process properly outbound?
>> >> >> >
>> >> >> > The settings in my cuc 7.x to add the gateway h323 are
>> >> >> >
>> >> >> > h323 cucm gateway configuratration
>> >> >> > Signaling Port 1720
>> >> >> > media termination point required yes
>> >> >> > retry video call as auto yes
>> >> >> > wait for far end h.245 terminal capability set yes
>> >> >> > transmit utf-8 calling party name no
>> >> >> > h.235 pass through allowed no
>> >> >> > significant digits all
>> >> >> > redirect number IT deliver - inbound no
>> >> >> > enable inbound faststart yes
>> >> >> > display IE deliver no
>> >> >> > redirect nunmber IT deliver - outbound no
>> >> >> > enable outbound faststart yes
>> >> >> >
>> >> >> >
>> >> >> > voice service voip
>> >> >> > allow-connections h323 to h323
>> >> >> > allow-connections h323 to sip
>> >> >> > allow-connections sip to h323
>> >> >> > allow-connections sip to sip
>> >> >> > fax protocol pass-through g711ulaw
>> >> >> > h323
>> >> >> > emptycapability
>> >> >> > h225 id-passthru
>> >> >> > h245 passthru tcsnonstd-passthru
>> >> >> > sip
>> >> >> >
>> >> >> >
>> >> >> > voice class h323 50
>> >> >> > h225 timeout tcp establish 3
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > !
>> >> >> > voice translation-rule 1
>> >> >> > rule 1 /.*/ /190/
>> >> >> > !
>> >> >> > voice translation-rule 2
>> >> >> > rule 1 /.*/ /1&/
>> >> >> > !
>> >> >> > !
>> >> >> > voice translation-profile aa
>> >> >> > translate called 1
>> >> >> > !
>> >> >> > voice translation-profile addone
>> >> >> > translate called 2
>> >> >> > !
>> >> >> > !
>> >> >> > voice-card 0
>> >> >> > dspfarm
>> >> >> > dsp services dspfarm
>> >> >> > !
>> >> >> > !
>> >> >> > sccp local GigabitEthernet0/1
>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>> >> >> > sccp
>> >> >> > !
>> >> >> > sccp ccm group 1
>> >> >> > associate ccm 1 priority 1
>> >> >> > associate ccm 2 priority 2
>> >> >> > associate profile 1 register 2821transcode
>> >> >> > !
>> >> >> > dspfarm profile 1 transcode
>> >> >> > codec g711ulaw
>> >> >> > codec g711alaw
>> >> >> > codec g729ar8
>> >> >> > codec g729abr8
>> >> >> > codec g729r8
>> >> >> > maximum sessions 4
>> >> >> > associate application SCCP
>> >> >> > !
>> >> >> > !
>> >> >> > dial-peer voice 100 voip
>> >> >> > description AA Publisher
>> >> >> > preference 1
>> >> >> > destination-pattern 1..
>> >> >> > voice-class h323 50
>> >> >> > session target ipv4:10.1.80.10
>> >> >> > dtmf-relay h245-alphanumeric
>> >> >> > codec g711ulaw
>> >> >> > no vad
>> >> >> > !
>> >> >> > dial-peer voice 1000 voip
>> >> >> > description incoming Call
>> >> >> > translation-profile incoming aa
>> >> >> > preference 1
>> >> >> > rtp payload-type nse 101
>> >> >> > rtp payload-type nte 100
>> >> >> > incoming called-number 6782282221
>> >> >> > dtmf-relay rtp-nte
>> >> >> > codec g711ulaw
>> >> >> > ip qos dscp cs5 media
>> >> >> > ip qos dscp cs5 signaling
>> >> >> > no vad
>> >> >> > !
>> >> >> > dial-peer voice 101 voip
>> >> >> > description AA Subscriber
>> >> >> > preference 2
>> >> >> > destination-pattern 1..
>> >> >> > voice-class h323 50
>> >> >> > session target ipv4:10.1.80.11
>> >> >> > dtmf-relay h245-alphanumeric
>> >> >> > codec g711ulaw
>> >> >> > no vad
>> >> >> > !
>> >> >> > dial-peer voice 2000 voip
>> >> >> > description outbound
>> >> >> > translation-profile outgoing addone
>> >> >> > preference 1
>> >> >> > destination-pattern .T
>> >> >> > rtp payload-type nse 101
>> >> >> > rtp payload-type nte 100
>> >> >> > voice-class sip asymmetric payload dtmf
>> >> >> > session protocol sipv2
>> >> >> > session target ipv4:64.154.41.200
>> >> >> > dtmf-relay rtp-nte
>> >> >> > codec g711ulaw
>> >> >> > no vad
>> >> >> > !
>> >> >> > !
>> >> >> > sip-ua
>> >> >> > credentials username ***** password 7 ***** realm
>> sip.talkinip.net
>> >> >> > authentication username ***** password 7 *****
>> >> >> > authentication username ***** password 7 ***** realm
>> >> >> > sip.talkinip.net
>> >> >> > set pstn-cause 3 sip-status 486
>> >> >> > set pstn-cause 34 sip-status 486
>> >> >> > set pstn-cause 47 sip-status 486
>> >> >> > registrar dns:sip.talkinip.net expires 60
>> >> >> > sip-server dns:sip.talkinip.net:5060
>> >> >> > _______________________________________________
>> >> >> > cisco-voip mailing list
>> >> >> > cisco-voip at puck.nether.net
>> >> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >> >
>> >> >> >
>> >> >
>> >> >
>> >
>> > _______________________________________________
>> > cisco-voip mailing list
>> > cisco-voip at puck.nether.net
>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >
>> >
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/af939459/attachment-0001.html>
------------------------------
Message: 13
Date: Tue, 27 Oct 2009 14:56:23 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID: <A6C76132-8F5E-4424-BB52-B1214B1BD4E6 at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
I doubt that is related to your lack of DTMF but it's most likely the
side sending the 183 is actually counting 1-16 and printing the 0.
The Session Progress is received by the router isn't it?
There are only 16 DTMF characters, the 12 on your keypad and 4 hidden
ones A, B, C, and D.
-Ryan
On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:
The difference I see between the invite and the 183 session
progression from the telco is
invite
a=fmtp:101 0-15
session progression
a=fmtp:101 0-16
Could this miss match in supported digits be what is causing all dtmf
not to work? How can I make my cisco router support 0-16?
Dane
Invite
v=0
o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57
s=SIP Call
c=IN IP4 173.14.220.57
t=0 0
m=audio 18770 RTP/AVP 0 101 19
c=IN IP4 173.14.220.57
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
session progression
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 17646 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <rratliff at cisco.com>
wrote:
Sorry this part is the actual DTMF:
a=rtpmap:101 telephone-event/8000
The line you quoted is part of the SDP and references both RTP and DTMF.
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
The fist line means your RTP is on port 11680 and references the
a:rtpmap entries for 0 and 101.
The second line means your RTP is g.711.
The 3rd line is the DTMF with a payload type of 101.
The 4th line means it can accept DTMF 0-16
The last line is pretty self explanatory (silence suppression disabled).
This is a very basic interpretation of the SDP info. RFC 2327 is
where you want to go to get into the nitty-gritty details.
-Ryan
On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
That is RFC2833 DTMF with a payload type of 101.
I do know that CUBE cannot do dynamic RFC2833 payload types. It can
only send the payloadType defined in the voip dial-peer. So if
inbound calls use a different payloadType than outbound calls you will
want to update the dial-peers accordingly.
-Ryan
On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
Well I tried to switch providers just to test it out and now I am
getting something back in the 183 but still no dtmf hmm
I see they are sending me
m=audio 11680 RTP/AVP 0 101
How do I interperate that line?
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57
From: <sip:6782282221 at did.voip.les.net>;tag=419FE94-8A1
To: <sip:18774675464 at did.voip.les.net>;tag=as5677a12c
Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
CSeq: 101 INVITE
User-Agent: LES.NET.VoIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:18774675464 at 64.34.181.47>
Content-Type: application/sdp
Content-Length: 214
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX
*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
No GTD found in inbound container
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoMediaNegotiation: Number of m-lines = 1
SIP: Attribute mid, level 1 instance 1 not found.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
resolve_media_ip_address_to_bind: Media already bound, use existing
source_media_ip_addr
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/
sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on
Static Payload for m-line 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoPtimeNegotiation: No ptime present or multiple ptime
attributes that can't be handled
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: m-line index 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
fmtp list of events.
*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/
sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem
relay
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIGetSDPDirectionAttribute: No direction attribute present or
multiple direction attributes that can't be handled for m-line:1 and
num-a-lines:0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
payload_type=0, codec_bytes=160, codec=g711ulaw,
dtmf_relay=rtp-nte
stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
dest_port=11680
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/
sipSPIChangeStreamState: Stream (callid = -1) State changed from
(STREAM_DEAD) to (STREAM_ADDING)
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/
sipSPIUpdCallWithSdpInfo:
Preferred Codec : g711ulaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>
wrote:
The 200 OK that you've pasted is confirming the CANCEL that we sent.
You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
a 200 OK with the CSeq for 101 INVITE.
I've seen this for certain IVRs/providers - sometimes they don't
properly terminate a call with a 200 OK. If you were not sending an
SDP in your original INVITE, then you would need the PRACK setting
mentioned. You have two problems, either could fix the problem: They
could advertise DTMF in their 183, or they could send you a 200 OK for
the call. It is assumed you would get DTMF in the 200 OK. It's
common for endpoints that support DTMF to not advertise it in the 183
because you technically shouldn't need DTMF to hear ringback.
-nick
On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
wrote:
> There is no SDP in that 200 OK so I would assume the media info is
the same
> as in the 183 Ringing message. You really need your ITSP to tell
you what
> dtmf method they want you to use on your outbound calls. As Nick
said they
> don't appear to be advertising any dtmf method at all.
> -Ryan
> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
> Is the below the ok I should be getting?
>
>
> They did send this with the first debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
> From: <sip:6782282221 at sip.talkinip.net>;tag=32DA608-109A
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> This with the 2nd debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 487 Request Terminated
> To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> Contact: <sip:18774675464 at 64.154.41.200:5060>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 INVITE
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> Content-Length: 0
>
> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews
<matthnick at gmail.com> wrote:
>>
>> In the 183 Session Progress they're not advertising DTMF:
>>
>> m=audio 45846 RTP/AVP 0
>>
>> There should be a 100 or 101 there. Although, 183 is just ringback.
>> You would want to pick up on the other side and they should send a
200
>> OK with a new SDP. If the other side did pick up, you need to tell
>> the provider that they need to send a 200 OK, because they're not.
>>
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Nick
>> >
>> > I removed voice-class sip asymmetric payload dtmf and added in
the
>> > other
>> > line
>> >
>> > Just to state incoming dtmf works but not outbound the ITSP has
told me
>> > they
>> > are using two different sip servers/vendors for processing
inbound and
>> > outbound
>> > How does this translate into what I should sent the following too?
>> >
>> > rtp payload-type nse
>> > rtp payload-type nte
>> >
>> > In the debug trhe following where set
>> >
>> > rtp payload-type nse 101
>> > rtp payload-type nte 100
>> >
>> > In the debug of ccsip If I am looking at it correctly I see me
sending
>> > this
>> >
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>> > Preferred method of dtmf relay is: 6, with payload: 100
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>> > max_event 15
>> >
>> > and
>> >
>> >
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> >
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 101 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> >
>> >
>> > Then when I do a search for fmtp again further down I see
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 102 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Proxy-Authorization: Digest
>> >
>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464 at 64.154.41.200:5060
",response
=
"ab63d4755ff4182631ad2db0f9ed0e44
",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 100 Trying
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Length: 0
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE) to
>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 183 Session Progress
>> > To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Type: application/sdp
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Content-Length: 146
>> > v=0
>> > o=msx71 490 6110 IN IP4 64.154.41.200
>> > s=sip call
>> > c=IN IP4 64.154.41.101
>> > t=0 0
>> > m=audio 45846 RTP/AVP 0
>> > a=ptime:20
>> > a=rtpmap:0 PCMU/8000
>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentGTD: No
>> > GTD
>> > found in inbound container
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>> > Number of m-lines = 1
>> > SIP: Attribute mid, level 1 instance 1 not found.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-
line 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>> > One ptime attribute found - value:20
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes:
Values :Codec:
>> > g711ulaw ptime :20, codecbytes: 160
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes:
160 for
>> > codec
>> > g711ulaw
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
index 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>> > Dynamic payload(100) could not be reserved.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case
of full
>> > named
>> > event(NE) match in fmtp list of events.
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
direction
>> > attribute present or multiple direction attributes that can't be
handled
>> > for
>> > m-line:1 and num-a-lines:0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec negotiation successful for media line 1
>> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>> > dtmf_relay=rtp-nte
>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>> > dest_port=45846
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>> > (STREAM_ADDING)
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Preferred Codec : g711ulaw, bytes :160
>> > Preferred DTMF relay : rtp-nte
>> > Preferred NTE payload : 100
>> > Early Media : No
>> > Delayed Media : No
>> > Bridge Done : No
>> > New Media : No
>> > DSP DNLD Reqd : No
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4A170B28)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Hndl ptype 0 mline 1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Selecting
>> > codec g711ulaw
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>> > Codec to be matched: 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
ADD
>> > AUDIO
>> > CODEC 5
>> > *Oct 27 12:34:10.840:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Media
>> > negotiation done:
>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
coverted
>> > ptime=20 stream->mline_index=1, media_ndx=1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1
ss 1
>> > 64.154.41.101:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > Report initial call media
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
ccb->flags
>> > 0x400018, ccb->pld.flags_ipip 0x200005
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4DEC000C)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>> > 5030: Posting Remote SRTP caps to other callleg.
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>> > cc_api_caps_ind()
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Stream type : voice+dtmf
>> > Media line : 1
>> > State : STREAM_ADDING (2)
>> > Stream address type : 1
>> > Callid : 846
>> > Negotiated Codec : g711ulaw, bytes :160
>> > Nego. Codec payload : 0 (tx), 0 (rx)
>> > Negotiated DTMF relay : rtp-nte
>> > Negotiated NTE payload : 100 (tx), 100 (rx)
>> > Negotiated CN payload : 0
>> > Media Srce Addr/Port : [173.14.220.57]:16462
>> > Media Dest Addr/Port : [64.154.41.101]:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>> > headers
>> > recvd from app container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQSIG:
>> > No
>> > QSIG Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQ931:
>> > No
>> > RawMsg Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPICreateNewRawMsg:
>> > No
>> > Data to form The Raw Message
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>> > SUBSTATE_NONE)
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
Transaction
>> > Complete. Lock on Facilities released.
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
confID =
>> > 6,
>> > srcCallID = 846, dstCallID = 845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old streamcallid=846, new streamcallid=846
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>> > Setting SPI mode to SIP-H323
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
1131891908
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>> > sipSPIProcessRtpSessions
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/
sipSPIAddStream:
>> > Adding
>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > sipSPIUpdateRtcpSession for m-line 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > rtcp_session info
>> > laddr = 173.14.220.57, lport = 16462, raddr =
64.154.41.101,
>> > rport=45846, do_rtcp=TRUE
>> > src_callid = 846, dest_callid = 845, stream type = voice
+dtmf,
>> > stream direction = SENDRECV
>> > media_ip_addr = 64.154.41.101, vrf tableid = 0
media_addr_type =
>> > 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > RTP session already created - update
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>> > New Remote Media Direction = SENDRECV
>> > Present Local Media Direction = SENDRECV
>> > New Local Media Direction = SENDRECV
>> > retVal = 0
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>> > (STREAM_ACTIVE)
>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
really
>> > can't
>> > find peer_stream for
>> > dtmf-relay
interworking
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x23ED
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Setting
>> > CAPS_RECEIVED flag
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Calling
>> > cc_api_caps_ack()
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ack: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Second
>> > TCS
>> > received for transfers across trunk - set CAPS2_RECEIVED
>> > *Oct 27 12:34:15.876:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/
ccsip_call_statistics:
>> > Stats are not supported for IPIP call.
>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>> > Queued
>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 3 for event 7
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/
sipSPISendCancel:
>> > Associated container=0x4E310C1C to Cancel
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/
sipSPISendCancel:
>> > Sending CANCEL to the transport layer
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> > msg=0x4DF0D994,
>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,
transport=1,
>> > switch=0, callBack=0x419703BC
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
Proceedable
>> > for
>> > sending msg immediately
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>> > transport
>> > is 0
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set
to send
>> > the
>> > msg=0x4DF0D994
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:
Posting
>> > send
>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for
UDP
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>> > Sent Cancel Request, starting CancelWaitResponseTimer
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_NONE)
>> > to
>> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Sent:
>> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Max-Forwards: 70
>> > Timestamp: 1256646855
>> > Reason: Q.850;cause=16
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >
>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com
>
>> > wrote:
>> >>
>> >> You would want to check the SDP of 200 OK the provider sends
for your
>> >> outgoing call. It will list the payload type for the dtmf in the
>> >> format a=fmtp 101 1-16, or something similar. You want to find
out
>> >> what payload type they are advertising (or if they are at
all). It
>> >> would be worth checking the incoming INVITE from them to see what
>> >> they're using when they send the first SDP.
>> >>
>> >> On that note, I would also remove the asymmetric payload
command - to
>> >> my knowledge it doesn't do what you're expecting it to. You
may want
>> >> to try this command:
>> >> voice-class sip dtmf-relay force rtp-nte
>> >>
>> >>
>> >> -nick
>> >>
>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com
>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I am having an issue with dtmf working outbound. Inbound
dtmf works
>> >> > fine.
>> >> > It took some playing around with it. At first it didnt work
till the
>> >> > payload was ajusted. I am now trying to get outbound dtmf
working
>> >> > properly.
>> >> >
>> >> > On my 2821 I debugged voip rtp session named-events and then
made a
>> >> > call
>> >> > to
>> >> > a 1800 number and hit digits. I didn't see any dtmf output
on the
>> >> > router
>> >> > nothing showed up in the debug. Does this mean I can safely
asume
>> >> > that
>> >> > the
>> >> > problem for right now is not on the ITSP side but on my side
since
>> >> > dtmf
>> >> > is
>> >> > not being sent down the sip trunk?
>> >> >
>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>> >> > configuration
>> >> > of the cisco 2821 is shown below. Does anyone have any ideas
what I
>> >> > can
>> >> > do
>> >> > so dtmf digits process properly outbound?
>> >> >
>> >> > The settings in my cuc 7.x to add the gateway h323 are
>> >> >
>> >> > h323 cucm gateway configuratration
>> >> > Signaling Port 1720
>> >> > media termination point required yes
>> >> > retry video call as auto yes
>> >> > wait for far end h.245 terminal capability set yes
>> >> > transmit utf-8 calling party name no
>> >> > h.235 pass through allowed no
>> >> > significant digits all
>> >> > redirect number IT deliver - inbound no
>> >> > enable inbound faststart yes
>> >> > display IE deliver no
>> >> > redirect nunmber IT deliver - outbound no
>> >> > enable outbound faststart yes
>> >> >
>> >> >
>> >> > voice service voip
>> >> > allow-connections h323 to h323
>> >> > allow-connections h323 to sip
>> >> > allow-connections sip to h323
>> >> > allow-connections sip to sip
>> >> > fax protocol pass-through g711ulaw
>> >> > h323
>> >> > emptycapability
>> >> > h225 id-passthru
>> >> > h245 passthru tcsnonstd-passthru
>> >> > sip
>> >> >
>> >> >
>> >> > voice class h323 50
>> >> > h225 timeout tcp establish 3
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > voice translation-rule 1
>> >> > rule 1 /.*/ /190/
>> >> > !
>> >> > voice translation-rule 2
>> >> > rule 1 /.*/ /1&/
>> >> > !
>> >> > !
>> >> > voice translation-profile aa
>> >> > translate called 1
>> >> > !
>> >> > voice translation-profile addone
>> >> > translate called 2
>> >> > !
>> >> > !
>> >> > voice-card 0
>> >> > dspfarm
>> >> > dsp services dspfarm
>> >> > !
>> >> > !
>> >> > sccp local GigabitEthernet0/1
>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>> >> > sccp
>> >> > !
>> >> > sccp ccm group 1
>> >> > associate ccm 1 priority 1
>> >> > associate ccm 2 priority 2
>> >> > associate profile 1 register 2821transcode
>> >> > !
>> >> > dspfarm profile 1 transcode
>> >> > codec g711ulaw
>> >> > codec g711alaw
>> >> > codec g729ar8
>> >> > codec g729abr8
>> >> > codec g729r8
>> >> > maximum sessions 4
>> >> > associate application SCCP
>> >> > !
>> >> > !
>> >> > dial-peer voice 100 voip
>> >> > description AA Publisher
>> >> > preference 1
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.10
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 1000 voip
>> >> > description incoming Call
>> >> > translation-profile incoming aa
>> >> > preference 1
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > incoming called-number 6782282221
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > ip qos dscp cs5 media
>> >> > ip qos dscp cs5 signaling
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 101 voip
>> >> > description AA Subscriber
>> >> > preference 2
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.11
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 2000 voip
>> >> > description outbound
>> >> > translation-profile outgoing addone
>> >> > preference 1
>> >> > destination-pattern .T
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > voice-class sip asymmetric payload dtmf
>> >> > session protocol sipv2
>> >> > session target ipv4:64.154.41.200
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > !
>> >> > sip-ua
>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net
>> >> > authentication username ***** password 7 *****
>> >> > authentication username ***** password 7 ***** realm
>> >> > sip.talkinip.net
>> >> > set pstn-cause 3 sip-status 486
>> >> > set pstn-cause 34 sip-status 486
>> >> > set pstn-cause 47 sip-status 486
>> >> > registrar dns:sip.talkinip.net expires 60
>> >> > sip-server dns:sip.talkinip.net:5060
>> >> > _______________________________________________
>> >> > cisco-voip mailing list
>> >> > cisco-voip at puck.nether.net
>> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >
>> >> >
>> >
>> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/4183b841/attachment-0001.html>
------------------------------
Message: 14
Date: Tue, 27 Oct 2009 14:06:02 -0500
From: "Jeff Ruttman" <ruttmanj at carewisc.org>
To: "Ryan Ratliff" <rratliff at cisco.com>
Cc: "Cisco VOIP Newsletter - puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Interpret CDR Search Results
Message-ID:
<07365C3161D8D8419EE51C3834C02205B84F07 at ma1-exc01.ec2802.elderc.org>
Content-Type: text/plain; charset="us-ascii"
Thanks! I'll have a look at that doc.
On that second one, if the caller had caller ID blocked, would that
produce the "Null"?
jeff
________________________________
From: Ryan Ratliff [mailto:rratliff at cisco.com]
Sent: Tuesday, October 27, 2009 1:42 PM
To: Jeff Ruttman
Cc: Cisco VOIP Newsletter - puck.nether.net
Subject: Re: [cisco-voip] Interpret CDR Search Results
Take a look at
http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/c
arcdrdef.html.
The first one you can correlate by the fact that there is no called
party number and the lack of any media information.
The second one was a call to your phone that seems to have no calling
party number and only partial media information.
You can take the GCID and search CCM traces to find more info if you
really want.
-Ryan
On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:
Greetings,
In the results of a CDR Search by Extension, I see entries like these:
Sl No Call Type GCID CMId
GCID CallId Orig Node Id
Dest Node Id Orig Leg Id
Dest Leg Id Calling No
Calling No Partition Called No
Called No Partition Dest No
Dest No Partition Last Rd No
Last Rd No Partition Media Info
Orig Pkts Rcd Dest Pkts Rcd
Orig Pkts Lost Dest Pkts Lost
CDR - CMR Dump
33 Simple 3
2155334 3
0 50453618
50453619 6174
Phones null
null null
null null
null null null Others
<javascript:fnDetails('Others',13)>
null null View <javascript:fnDetails('View',13)>
24 Simple 3
2155266 3
3 50453393
50453394 null
null 6174
Phones 6174
Phones 6174
Phones 2954 null Others
<javascript:fnDetails('Others',4)>
0 null View <javascript:fnDetails('View',4)>
What do these mean? The first one I can reproduce by going off hook and
waiting for dial tone to time out. Is that all such an entry could
mean? What about the second one?
Thanks
jeff
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.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/f833248c/attachment-0001.html>
------------------------------
Message: 15
Date: Tue, 27 Oct 2009 15:07:29 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: "Jeff Ruttman" <ruttmanj at carewisc.org>
Cc: "Cisco VOIP Newsletter - puck.nether.net"
<cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] Interpret CDR Search Results
Message-ID: <DE773F61-2423-4A47-A52B-6AD95E5542E1 at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
It certainly would.
-Ryan
On Oct 27, 2009, at 3:06 PM, Jeff Ruttman wrote:
Thanks! I'll have a look at that doc.
On that second one, if the caller had caller ID blocked, would that
produce the "Null"?
jeff
From: Ryan Ratliff [mailto:rratliff at cisco.com]
Sent: Tuesday, October 27, 2009 1:42 PM
To: Jeff Ruttman
Cc: Cisco VOIP Newsletter - puck.nether.net
Subject: Re: [cisco-voip] Interpret CDR Search Results
Take a look at http://www.cisco.com/en/US/docs/voice_ip_comm/cucmbe/service/6_0_1/car/carcdrdef.html
.
The first one you can correlate by the fact that there is no called
party number and the lack of any media information.
The second one was a call to your phone that seems to have no calling
party number and only partial media information.
You can take the GCID and search CCM traces to find more info if you
really want.
-Ryan
On Oct 27, 2009, at 2:35 PM, Jeff Ruttman wrote:
Greetings,
In the results of a CDR Search by Extension, I see entries like these:
Sl No Call Type GCID CMId
GCID CallId Orig Node Id
Dest Node Id Orig Leg Id
Dest Leg Id Calling No
Calling No Partition Called No
Called No Partition Dest No
Dest No Partition Last Rd No
Last Rd No Partition
Media Info
Orig Pkts Rcd Dest Pkts Rcd
Orig Pkts Lost Dest Pkts Lost
CDR - CMR Dump
33 Simple 3
2155334 3
0 50453618
50453619 6174
Phones null
null null
null null
null null null Others
null null View
24 Simple 3
2155266 3
3 50453393
50453394 null
null 6174
Phones 6174
Phones 6174
Phones 2954 null Others
0 null View
What do these mean? The first one I can reproduce by going off hook
and waiting for dial tone to time out. Is that all such an entry
could mean? What about the second one?
Thanks
jeff
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.
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/e66ad05d/attachment-0001.html>
------------------------------
Message: 16
Date: Tue, 27 Oct 2009 15:16:46 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Ryan Ratliff <rratliff at cisco.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271216i36f500d5n29ed90a45978cbee at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Yes the session progress is receviced by the router
In all my debugs I noticed I have the same thing
*Oct 27 20:25:37.558: //1528/003E40690D00/SIP/Info/sipSPICheckDynPayloadUse:
Dynamic payload(101) could not be reserved.
*Oct 27 20:25:37.558:
//1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
relay option
*Oct 27 20:25:37.562:
//1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
named event(NE) match in fmtp list of events.
*Oct 27 20:25:37.562:
//-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
from X-cap = 0
*Oct 27 20:25:37.562:
//1528/003E40690D00/SIP/Info/sip_select_modem_relay_params: X-tmr not
present in SDP. Disable modem relay
Is Dynamic payload(101) could not be reserved telling me I have no dtmf
support?
On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> I doubt that is related to your lack of DTMF but it's most likely the side
> sending the 183 is actually counting 1-16 and printing the 0. The Session
> Progress is received by the router isn't it?
>
> There are only 16 DTMF characters, the 12 on your keypad and 4 hidden ones
> A, B, C, and D.
>
> -Ryan
>
> On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:
>
> The difference I see between the invite and the 183 session progression
> from the telco is
>
> invite
> a=fmtp:101 0-15
>
> session progression
> a=fmtp:101 0-16
>
> Could this miss match in supported digits be what is causing all dtmf not
> to work? How can I make my cisco router support 0-16?
>
> Dane
>
> *Invite*
> **
> **
> v=0
> o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57
> s=SIP Call
> c=IN IP4 173.14.220.57
> t=0 0
> m=audio 18770 RTP/AVP 0 101 19
> c=IN IP4 173.14.220.57
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtpmap:19 CN/8000
> a=ptime:20
>
>
>
> *session progression*
>
>
> v=0
> o=root 5115 5115 IN IP4 64.34.181.47
> s=session
> c=IN IP4 64.34.181.47
> t=0 0
> m=audio 17646 RTP/AVP 0 101
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-16
> a=silenceSupp:off - - - -
>
> On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> Sorry this part is the actual DTMF:
>>
>> a=rtpmap:101 telephone-event/8000
>>
>> The line you quoted is part of the SDP and references both RTP and DTMF.
>> m=audio 11680 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=silenceSupp:off - - - -
>>
>> The fist line means your RTP is on port 11680 and references the a:rtpmap
>> entries for 0 and 101.
>> The second line means your RTP is g.711.
>> The 3rd line is the DTMF with a payload type of 101.
>> The 4th line means it can accept DTMF 0-16
>> The last line is pretty self explanatory (silence suppression disabled).
>>
>> This is a very basic interpretation of the SDP info. RFC 2327 is where
>> you want to go to get into the nitty-gritty details.
>>
>> -Ryan
>>
>> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
>>
>> That is RFC2833 DTMF with a payload type of 101.
>>
>> I do know that CUBE cannot do dynamic RFC2833 payload types. It can only
>> send the payloadType defined in the voip dial-peer. So if inbound calls use
>> a different payloadType than outbound calls you will want to update the
>> dial-peers accordingly.
>>
>>
>> -Ryan
>>
>> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
>>
>> Well I tried to switch providers just to test it out and now I am getting
>> something back in the 183 but still no dtmf hmm
>>
>> I see they are sending me
>>
>> m=audio 11680 RTP/AVP 0 101
>>
>> How do I interperate that line?
>>
>>
>> Received:
>> SIP/2.0 183 Session Progress
>> Via: SIP/2.0/UDP 173.14.220.57:5060
>> ;branch=z9hG4bK749136B;received=173.14.220.57
>> From: <sip:6782282221 at did.voip.les.net<sip%3A6782282221 at did.voip.les.net>
>> >;tag=419FE94-8A1
>> To: <sip:18774675464 at did.voip.les.net<sip%3A18774675464 at did.voip.les.net>
>> >;tag=as5677a12c
>> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
>> CSeq: 101 INVITE
>> User-Agent: LES.NET.VoIP
>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>> Contact: <sip:18774675464 at 64.34.181.47 <sip%3A18774675464 at 64.34.181.47>>
>> Content-Type: application/sdp
>> Content-Length: 214
>> v=0
>> o=root 5115 5115 IN IP4 64.34.181.47
>> s=session
>> c=IN IP4 64.34.181.47
>> t=0 0
>> m=audio 11680 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=silenceSupp:off - - - -
>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:
>> INVITE response with no RSEQ - disable IS_REL1XX
>> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No
>> GTD found in inbound container
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation: Number of m-lines = 1
>> SIP: Attribute mid, level 1 instance 1 not found.
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already
>> bound, use existing source_media_ip_addr
>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr:
>> Media src addr for stream 1 = 173.14.220.57
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)
>> Negotiation Successful on Static Payload for m-line 1
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or
>> multiple ptime attributes that can't be handled
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)
>> could not be reserved.
>> *Oct 27 18:02:12.551:
>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
>> relay option
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
>> named event(NE) match in fmtp list of events.
>> *Oct 27 18:02:12.555:
>> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
>> from X-cap = 0
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not
>> present in SDP. Disable modem relay
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction
>> attribute present or multiple direction attributes that can't be handled for
>> m-line:1 and num-a-lines:0
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation
>> successful for media line 1
>> payload_type=0, codec_bytes=160, codec=g711ulaw,
>> dtmf_relay=rtp-nte
>> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
>> dest_port=11680
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =
>> -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)
>> *Oct 27 18:02:12.555:
>> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> Preferred Codec : g711ulaw, bytes :160
>> Preferred DTMF relay : rtp-nte
>> Preferred NTE payload : 101
>> Early Media : No
>> Delayed Media : No
>> Bridge Done : No
>> New Media : No
>> DSP DNLD Reqd : No
>>
>> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>wrote:
>>
>>> The 200 OK that you've pasted is confirming the CANCEL that we sent.
>>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
>>> a 200 OK with the CSeq for 101 INVITE.
>>>
>>> I've seen this for certain IVRs/providers - sometimes they don't
>>> properly terminate a call with a 200 OK. If you were not sending an
>>> SDP in your original INVITE, then you would need the PRACK setting
>>> mentioned. You have two problems, either could fix the problem: They
>>> could advertise DTMF in their 183, or they could send you a 200 OK for
>>> the call. It is assumed you would get DTMF in the 200 OK. It's
>>> common for endpoints that support DTMF to not advertise it in the 183
>>> because you technically shouldn't need DTMF to hear ringback.
>>>
>>> -nick
>>>
>>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
>>> wrote:
>>> > There is no SDP in that 200 OK so I would assume the media info is the
>>> same
>>> > as in the 183 Ringing message. You really need your ITSP to tell you
>>> what
>>> > dtmf method they want you to use on your outbound calls. As Nick said
>>> they
>>> > don't appear to be advertising any dtmf method at all.
>>> > -Ryan
>>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
>>> > Is the below the ok I should be getting?
>>> >
>>> >
>>> > They did send this with the first debug
>>> >
>>> > Received:
>>> > SIP/2.0 200 OK
>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=32DA608-109A
>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
>>> > CSeq: 102 CANCEL
>>> > Content-Length: 0
>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:
>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
>>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
>>> > *Oct 27 13:44:12.836:
>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> > *Oct 27 13:44:12.840:
>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> > *Oct 27 13:44:12.840:
>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> > context=0x00000000
>>> > *Oct 27 13:44:12.840:
>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> > Checking Invite Dialog
>>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >
>>> > This with the 2nd debug
>>> >
>>> > Received:
>>> > SIP/2.0 200 OK
>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> > CSeq: 102 CANCEL
>>> > Content-Length: 0
>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>>> > *Oct 27 12:34:15.912:
>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> > *Oct 27 12:34:15.912:
>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> > *Oct 27 12:34:15.912:
>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> > context=0x00000000
>>> > *Oct 27 12:34:15.912:
>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> > Checking Invite Dialog
>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> > Received:
>>> > SIP/2.0 487 Request Terminated
>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>>> >;tag=3465630735-938664
>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> > CSeq: 102 INVITE
>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> > Content-Length: 0
>>> >
>>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <matthnick at gmail.com>
>>> wrote:
>>> >>
>>> >> In the 183 Session Progress they're not advertising DTMF:
>>> >>
>>> >> m=audio 45846 RTP/AVP 0
>>> >>
>>> >> There should be a 100 or 101 there. Although, 183 is just ringback.
>>> >> You would want to pick up on the other side and they should send a 200
>>> >> OK with a new SDP. If the other side did pick up, you need to tell
>>> >> the provider that they need to send a 200 OK, because they're not.
>>> >>
>>> >>
>>> >> -nick
>>> >>
>>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>>> >> wrote:
>>> >> > Nick
>>> >> >
>>> >> > I removed voice-class sip asymmetric payload dtmf and added in the
>>> >> > other
>>> >> > line
>>> >> >
>>> >> > Just to state incoming dtmf works but not outbound the ITSP has told
>>> me
>>> >> > they
>>> >> > are using two different sip servers/vendors for processing inbound
>>> and
>>> >> > outbound
>>> >> > How does this translate into what I should sent the following too?
>>> >> >
>>> >> > rtp payload-type nse
>>> >> > rtp payload-type nte
>>> >> >
>>> >> > In the debug trhe following where set
>>> >> >
>>> >> > rtp payload-type nse 101
>>> >> > rtp payload-type nte 100
>>> >> >
>>> >> > In the debug of ccsip If I am looking at it correctly I see me
>>> sending
>>> >> > this
>>> >> >
>>> >> > *Oct 27 12:34:09.128:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>>> >> > Preferred method of dtmf relay is: 6, with payload: 100
>>> >> > *Oct 27 12:34:09.128:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>>> >> > max_event 15
>>> >> >
>>> >> > and
>>> >> >
>>> >> >
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>>> >> > payload
>>> >> > from X-cap = 0
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
>>> >> > present
>>> >> > in SDP. Disable modem relay
>>> >> >
>>> >> >
>>> >> > Sent:
>>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>>> >> > Remote-Party-ID:
>>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>>> >;party=calling;screen=yes;privacy=off
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >
>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>> >> > Min-SE: 1800
>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> >> > SUBSCRIBE,
>>> >> > NOTIFY, INFO, REGISTER
>>> >> > CSeq: 101 INVITE
>>> >> > Max-Forwards: 70
>>> >> > Timestamp: 1256646849
>>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>>> >> > Expires: 180
>>> >> > Allow-Events: telephone-event
>>> >> > Content-Type: application/sdp
>>> >> > Content-Disposition: session;handling=required
>>> >> > Content-Length: 250
>>> >> > v=0
>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>>> >> > s=SIP Call
>>> >> > c=IN IP4 173.14.220.57
>>> >> > t=0 0
>>> >> > m=audio 16462 RTP/AVP 0 100
>>> >> > c=IN IP4 173.14.220.57
>>> >> > a=rtpmap:0 PCMU/8000
>>> >> > a=rtpmap:100 telephone-event/8000
>>> >> > a=fmtp:100 0-15
>>> >> > a=ptime:20
>>> >> >
>>> >> >
>>> >> > Then when I do a search for fmtp again further down I see
>>> >> >
>>> >> > Sent:
>>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> >> > Remote-Party-ID:
>>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>>> >;party=calling;screen=yes;privacy=off
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >
>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>> >> > Min-SE: 1800
>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>> >> > SUBSCRIBE,
>>> >> > NOTIFY, INFO, REGISTER
>>> >> > CSeq: 102 INVITE
>>> >> > Max-Forwards: 70
>>> >> > Timestamp: 1256646849
>>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>>> >> > Expires: 180
>>> >> > Allow-Events: telephone-event
>>> >> > Proxy-Authorization: Digest
>>> >> >
>>> >> > username="1648245954",realm="64.154.41.110",uri="
>>> sip:18774675464 at 64.154.41.200:5060
>>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>>> >> > Content-Type: application/sdp
>>> >> > Content-Disposition: session;handling=required
>>> >> > Content-Length: 250
>>> >> > v=0
>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>>> >> > s=SIP Call
>>> >> > c=IN IP4 173.14.220.57
>>> >> > t=0 0
>>> >> > m=audio 16462 RTP/AVP 0 100
>>> >> > c=IN IP4 173.14.220.57
>>> >> > a=rtpmap:0 PCMU/8000
>>> >> > a=rtpmap:100 telephone-event/8000
>>> >> > a=fmtp:100 0-15
>>> >> > a=ptime:20
>>> >> > *Oct 27 12:34:09.332:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> >> > *Oct 27 12:34:09.332:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> >> > *Oct 27 12:34:09.332:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> >> > context=0x00000000
>>> >> > *Oct 27 12:34:09.332:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> >> > Checking Invite Dialog
>>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >> > Received:
>>> >> > SIP/2.0 100 Trying
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > CSeq: 102 INVITE
>>> >> > Content-Length: 0
>>> >> > *Oct 27 12:34:09.332:
>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>>> >> > *Oct 27 12:34:09.332:
>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE)
>>> to
>>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>>> >> > *Oct 27 12:34:10.832:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> >> > *Oct 27 12:34:10.832:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> >> > *Oct 27 12:34:10.832:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> >> > context=0x00000000
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> >> > Checking Invite Dialog
>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >> > Received:
>>> >> > SIP/2.0 183 Session Progress
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >;tag=3465630735-938664
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > CSeq: 102 INVITE
>>> >> > Content-Type: application/sdp
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> >> > Content-Length: 146
>>> >> > v=0
>>> >> > o=msx71 490 6110 IN IP4 64.154.41.200
>>> >> > s=sip call
>>> >> > c=IN IP4 64.154.41.101
>>> >> > t=0 0
>>> >> > m=audio 45846 RTP/AVP 0
>>> >> > a=ptime:20
>>> >> > a=rtpmap:0 PCMU/8000
>>> >> > *Oct 27 12:34:10.836:
>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>>> >> > *Oct 27 12:34:10.836:
>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No
>>> >> > GTD
>>> >> > found in inbound container
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>>> >> > Number of m-lines = 1
>>> >> > SIP: Attribute mid, level 1 instance 1 not found.
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>> >> > already
>>> >> > bound, use existing source_media_ip_addr
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>> >> > Media src addr for stream 1 = 173.14.220.57
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-line
>>> 1
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>>> >> > One ptime attribute found - value:20
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values
>>> :Codec:
>>> >> > g711ulaw ptime :20, codecbytes: 160
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>>> :Codec:
>>> >> > g711ulaw codecbytes :160, ptime: 20
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160
>>> for
>>> >> > codec
>>> >> > g711ulaw
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
>>> index 1
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>>> >> > Dynamic payload(100) could not be reserved.
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of
>>> full
>>> >> > named
>>> >> > event(NE) match in fmtp list of events.
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>>> >> > payload
>>> >> > from X-cap = 0
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr not
>>> >> > present
>>> >> > in SDP. Disable modem relay
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
>>> direction
>>> >> > attribute present or multiple direction attributes that can't be
>>> handled
>>> >> > for
>>> >> > m-line:1 and num-a-lines:0
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>>> >> > Codec negotiation successful for media line 1
>>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>>> >> > dtmf_relay=rtp-nte
>>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>>> >> > dest_port=45846
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>>> >> > (STREAM_ADDING)
>>> >> > *Oct 27 12:34:10.836:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>>> >> > Preferred Codec : g711ulaw, bytes :160
>>> >> > Preferred DTMF relay : rtp-nte
>>> >> > Preferred NTE payload : 100
>>> >> > Early Media : No
>>> >> > Delayed Media : No
>>> >> > Bridge Done : No
>>> >> > New Media : No
>>> >> > DSP DNLD Reqd : No
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>> >> > already
>>> >> > bound, use existing source_media_ip_addr
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>> >> > Media src addr for stream 1 = 173.14.220.57
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>>> >> > callId 846 size 240 ptr 0x4A170B28)
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> >> > Hndl ptype 0 mline 1
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> >> > Selecting
>>> >> > codec g711ulaw
>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>>> >> > Codec to be matched: 5
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo: ADD
>>> >> > AUDIO
>>> >> > CODEC 5
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>>> :Codec:
>>> >> > g711ulaw codecbytes :160, ptime: 20
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> Media
>>> >> > negotiation done:
>>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
>>> coverted
>>> >> > ptime=20 stream->mline_index=1, media_ndx=1
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss 1
>>> >> > 64.154.41.101:45846
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> Copy
>>> >> > sdp to
>>> >> > channel- AFTER CODEC FILTERING:
>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>> Copy
>>> >> > sdp to
>>> >> > channel- AFTER CODEC FILTERING:
>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>> >> > Report initial call media
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>> ccb->flags
>>> >> > 0x400018, ccb->pld.flags_ipip 0x200005
>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>>> >> > callId 846 size 240 ptr 0x4DEC000C)
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>>> >> > 5030: Posting Remote SRTP caps to other callleg.
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>>> >> > cc_api_caps_ind()
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>>> >> > Stream type : voice+dtmf
>>> >> > Media line : 1
>>> >> > State : STREAM_ADDING (2)
>>> >> > Stream address type : 1
>>> >> > Callid : 846
>>> >> > Negotiated Codec : g711ulaw, bytes :160
>>> >> > Nego. Codec payload : 0 (tx), 0 (rx)
>>> >> > Negotiated DTMF relay : rtp-nte
>>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)
>>> >> > Negotiated CN payload : 0
>>> >> > Media Srce Addr/Port : [173.14.220.57]:16462
>>> >> > Media Dest Addr/Port : [64.154.41.101]:45846
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>>> >> > headers
>>> >> > recvd from app container
>>> >> > *Oct 27 12:34:10.840:
>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:
>>> >> > No
>>> >> > QSIG Body found in inbound container
>>> >> > *Oct 27 12:34:10.840:
>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:
>>> >> > No
>>> >> > RawMsg Body found in inbound container
>>> >> > *Oct 27 12:34:10.840:
>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:
>>> >> > No
>>> >> > Data to form The Raw Message
>>> >> > *Oct 27 12:34:10.840:
>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>>> >> > *Oct 27 12:34:10.840:
>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>>> >> > SUBSTATE_NONE)
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress: Transaction
>>> >> > Complete. Lock on Facilities released.
>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>> confID =
>>> >> > 6,
>>> >> > srcCallID = 846, dstCallID = 845
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>>> >> > Old streamcallid=846, new streamcallid=846
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>>> >> > Setting SPI mode to SIP-H323
>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
>>> 1131891908
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>>> >> > sipSPIProcessRtpSessions
>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:
>>> >> > Adding
>>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>> >> > already
>>> >> > bound, use existing source_media_ip_addr
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>> >> > Media src addr for stream 1 = 173.14.220.57
>>> >> > *Oct 27 12:34:10.844:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>> >> > sipSPIUpdateRtcpSession for m-line 1
>>> >> > *Oct 27 12:34:10.848:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>> >> > rtcp_session info
>>> >> > laddr = 173.14.220.57, lport = 16462, raddr = 64.154.41.101,
>>> >> > rport=45846, do_rtcp=TRUE
>>> >> > src_callid = 846, dest_callid = 845, stream type =
>>> voice+dtmf,
>>> >> > stream direction = SENDRECV
>>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0
>>> media_addr_type =
>>> >> > 1
>>> >> > *Oct 27 12:34:10.848:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>> >> > RTP session already created - update
>>> >> > *Oct 27 12:34:10.848:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>>> >> > stun is disabled for stream:4A1709F8
>>> >> > *Oct 27 12:34:10.848:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>>> >> > New Remote Media Direction = SENDRECV
>>> >> > Present Local Media Direction = SENDRECV
>>> >> > New Local Media Direction = SENDRECV
>>> >> > retVal = 0
>>> >> > *Oct 27 12:34:10.848:
>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>>> >> > (STREAM_ACTIVE)
>>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>> really
>>> >> > can't
>>> >> > find peer_stream for
>>> >> > dtmf-relay
>>> interworking
>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Entry
>>> >> > *Oct 27 12:34:11.140:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>>> CURRENT
>>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED
>>> >> > *Oct 27 12:34:11.140:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>>> >> > VALUES:
>>> >> > stream_callid=846, current_seq_num=0x11D9
>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Load
>>> >> > DSP
>>> >> > with negotiated codec: g711ulaw, Bytes=160
>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Set
>>> >> > forking flag to 0x0
>>> >> > *Oct 27 12:34:11.140:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>>> payload =
>>> >> > 100, tx payload = 100
>>> >> > *Oct 27 12:34:11.140:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>>> >> > config=0
>>> >> > *Oct 27 12:34:11.140:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Disabling Modem Relay...
>>> >> > *Oct 27 12:34:11.140:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
>>> >> > Xcap
>>> >> > list
>>> >> > *Oct 27 12:34:11.140:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Modem
>>> >> > Relay & Passthru both disabled
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > nse
>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>>> relay=0,
>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > 1
>>> >> > Active Streams
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > Adding stream type (voice+dtmf) from media
>>> >> > line 1 codec g711ulaw
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>>> >> > caps.stream_list.xmitFunc=
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > voip_rtp_xmit, caps.stream_list.context=
>>> >> > *Oct 27 12:34:11.144:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > 0x497E0B60 (gccb)
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Load
>>> >> > DSP
>>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
>>> >> > video
>>> >> > caps detected in the caps posted by peer leg
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> >> > Setting
>>> >> > CAPS_RECEIVED flag
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> >> > Calling
>>> >> > cc_api_caps_ack()
>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack:
>>> Set
>>> >> > forking flag to 0x0
>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Entry
>>> >> > *Oct 27 12:34:11.168:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>>> CURRENT
>>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9
>>> >> > *Oct 27 12:34:11.168:
>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>>> >> > VALUES:
>>> >> > stream_callid=846, current_seq_num=0x11D9
>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Load
>>> >> > DSP
>>> >> > with negotiated codec: g711ulaw, Bytes=160
>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Set
>>> >> > forking flag to 0x0
>>> >> > *Oct 27 12:34:11.168:
>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>>> payload =
>>> >> > 100, tx payload = 100
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>>> >> > config=0
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Disabling Modem Relay...
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Negotiation already Done. Set negotiated Modem caps and generate SDP
>>> >> > Xcap
>>> >> > list
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > Modem
>>> >> > Relay & Passthru both disabled
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>> >> > nse
>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>>> relay=0,
>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > 1
>>> >> > Active Streams
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > Adding stream type (voice+dtmf) from media
>>> >> > line 1 codec g711ulaw
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>>> >> > caps.stream_list.xmitFunc=
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > voip_rtp_xmit, caps.stream_list.context=
>>> >> > *Oct 27 12:34:11.168:
>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>> >> > 0x497E0B60 (gccb)
>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Load
>>> >> > DSP
>>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind: No
>>> >> > video
>>> >> > caps detected in the caps posted by peer leg
>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>> Second
>>> >> > TCS
>>> >> > received for transfers across trunk - set CAPS2_RECEIVED
>>> >> > *Oct 27 12:34:15.876:
>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>>> >> > stun is disabled for stream:4A1709F8
>>> >> > *Oct 27 12:34:15.876:
>>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:
>>> >> > Stats are not supported for IPIP call.
>>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>>> >> > Queued
>>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> >> > ccsip_spi_get_msg_type returned: 3 for event 7
>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:
>>> >> > Associated container=0x4E310C1C to Cancel
>>> >> > *Oct 27 12:34:15.880:
>>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:
>>> >> > Sending CANCEL to the transport layer
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>>> >> > msg=0x4DF0D994,
>>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1, transport=1,
>>> >> > switch=0, callBack=0x419703BC
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>>> Proceedable
>>> >> > for
>>> >> > sending msg immediately
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>>> >> > transport
>>> >> > is 0
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to
>>> send
>>> >> > the
>>> >> > msg=0x4DF0D994
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage: Posting
>>> >> > send
>>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP
>>> >> > *Oct 27 12:34:15.880:
>>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>>> >> > Sent Cancel Request, starting CancelWaitResponseTimer
>>> >> > *Oct 27 12:34:15.880:
>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>>> SUBSTATE_NONE)
>>> >> > to
>>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >> > Sent:
>>> >> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >
>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > CSeq: 102 CANCEL
>>> >> > Max-Forwards: 70
>>> >> > Timestamp: 1256646855
>>> >> > Reason: Q.850;cause=16
>>> >> > Content-Length: 0
>>> >> > *Oct 27 12:34:15.900:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> >> > *Oct 27 12:34:15.900:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> >> > *Oct 27 12:34:15.900:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> >> > context=0x00000000
>>> >> > *Oct 27 12:34:15.900:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> >> > Checking Invite Dialog
>>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >> > Received:
>>> >> > SIP/2.0 200 OK
>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>> >;tag=2EDA9C8-25D6
>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>> >
>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>> >> > CSeq: 102 CANCEL
>>> >> > Content-Length: 0
>>> >> > *Oct 27 12:34:15.900:
>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>> >> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>>> >> > *Oct 27 12:34:15.912:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>> >> > *Oct 27 12:34:15.912:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>> >> > *Oct 27 12:34:15.912:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>> >> > context=0x00000000
>>> >> > *Oct 27 12:34:15.912:
>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>> >> > Checking Invite Dialog
>>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> >> >
>>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com
>>> >
>>> >> > wrote:
>>> >> >>
>>> >> >> You would want to check the SDP of 200 OK the provider sends for
>>> your
>>> >> >> outgoing call. It will list the payload type for the dtmf in the
>>> >> >> format a=fmtp 101 1-16, or something similar. You want to find out
>>> >> >> what payload type they are advertising (or if they are at all). It
>>> >> >> would be worth checking the incoming INVITE from them to see what
>>> >> >> they're using when they send the first SDP.
>>> >> >>
>>> >> >> On that note, I would also remove the asymmetric payload command -
>>> to
>>> >> >> my knowledge it doesn't do what you're expecting it to. You may
>>> want
>>> >> >> to try this command:
>>> >> >> voice-class sip dtmf-relay force rtp-nte
>>> >> >>
>>> >> >>
>>> >> >> -nick
>>> >> >>
>>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <
>>> dane.newman at gmail.com>
>>> >> >> wrote:
>>> >> >> > Hello,
>>> >> >> >
>>> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf
>>> works
>>> >> >> > fine.
>>> >> >> > It took some playing around with it. At first it didnt work till
>>> the
>>> >> >> > payload was ajusted. I am now trying to get outbound dtmf
>>> working
>>> >> >> > properly.
>>> >> >> >
>>> >> >> > On my 2821 I debugged voip rtp session named-events and then made
>>> a
>>> >> >> > call
>>> >> >> > to
>>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on
>>> the
>>> >> >> > router
>>> >> >> > nothing showed up in the debug. Does this mean I can safely
>>> asume
>>> >> >> > that
>>> >> >> > the
>>> >> >> > problem for right now is not on the ITSP side but on my side
>>> since
>>> >> >> > dtmf
>>> >> >> > is
>>> >> >> > not being sent down the sip trunk?
>>> >> >> >
>>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>>> >> >> > configuration
>>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas
>>> what I
>>> >> >> > can
>>> >> >> > do
>>> >> >> > so dtmf digits process properly outbound?
>>> >> >> >
>>> >> >> > The settings in my cuc 7.x to add the gateway h323 are
>>> >> >> >
>>> >> >> > h323 cucm gateway configuratration
>>> >> >> > Signaling Port 1720
>>> >> >> > media termination point required yes
>>> >> >> > retry video call as auto yes
>>> >> >> > wait for far end h.245 terminal capability set yes
>>> >> >> > transmit utf-8 calling party name no
>>> >> >> > h.235 pass through allowed no
>>> >> >> > significant digits all
>>> >> >> > redirect number IT deliver - inbound no
>>> >> >> > enable inbound faststart yes
>>> >> >> > display IE deliver no
>>> >> >> > redirect nunmber IT deliver - outbound no
>>> >> >> > enable outbound faststart yes
>>> >> >> >
>>> >> >> >
>>> >> >> > voice service voip
>>> >> >> > allow-connections h323 to h323
>>> >> >> > allow-connections h323 to sip
>>> >> >> > allow-connections sip to h323
>>> >> >> > allow-connections sip to sip
>>> >> >> > fax protocol pass-through g711ulaw
>>> >> >> > h323
>>> >> >> > emptycapability
>>> >> >> > h225 id-passthru
>>> >> >> > h245 passthru tcsnonstd-passthru
>>> >> >> > sip
>>> >> >> >
>>> >> >> >
>>> >> >> > voice class h323 50
>>> >> >> > h225 timeout tcp establish 3
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > !
>>> >> >> > voice translation-rule 1
>>> >> >> > rule 1 /.*/ /190/
>>> >> >> > !
>>> >> >> > voice translation-rule 2
>>> >> >> > rule 1 /.*/ /1&/
>>> >> >> > !
>>> >> >> > !
>>> >> >> > voice translation-profile aa
>>> >> >> > translate called 1
>>> >> >> > !
>>> >> >> > voice translation-profile addone
>>> >> >> > translate called 2
>>> >> >> > !
>>> >> >> > !
>>> >> >> > voice-card 0
>>> >> >> > dspfarm
>>> >> >> > dsp services dspfarm
>>> >> >> > !
>>> >> >> > !
>>> >> >> > sccp local GigabitEthernet0/1
>>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>>> >> >> > sccp
>>> >> >> > !
>>> >> >> > sccp ccm group 1
>>> >> >> > associate ccm 1 priority 1
>>> >> >> > associate ccm 2 priority 2
>>> >> >> > associate profile 1 register 2821transcode
>>> >> >> > !
>>> >> >> > dspfarm profile 1 transcode
>>> >> >> > codec g711ulaw
>>> >> >> > codec g711alaw
>>> >> >> > codec g729ar8
>>> >> >> > codec g729abr8
>>> >> >> > codec g729r8
>>> >> >> > maximum sessions 4
>>> >> >> > associate application SCCP
>>> >> >> > !
>>> >> >> > !
>>> >> >> > dial-peer voice 100 voip
>>> >> >> > description AA Publisher
>>> >> >> > preference 1
>>> >> >> > destination-pattern 1..
>>> >> >> > voice-class h323 50
>>> >> >> > session target ipv4:10.1.80.10
>>> >> >> > dtmf-relay h245-alphanumeric
>>> >> >> > codec g711ulaw
>>> >> >> > no vad
>>> >> >> > !
>>> >> >> > dial-peer voice 1000 voip
>>> >> >> > description incoming Call
>>> >> >> > translation-profile incoming aa
>>> >> >> > preference 1
>>> >> >> > rtp payload-type nse 101
>>> >> >> > rtp payload-type nte 100
>>> >> >> > incoming called-number 6782282221
>>> >> >> > dtmf-relay rtp-nte
>>> >> >> > codec g711ulaw
>>> >> >> > ip qos dscp cs5 media
>>> >> >> > ip qos dscp cs5 signaling
>>> >> >> > no vad
>>> >> >> > !
>>> >> >> > dial-peer voice 101 voip
>>> >> >> > description AA Subscriber
>>> >> >> > preference 2
>>> >> >> > destination-pattern 1..
>>> >> >> > voice-class h323 50
>>> >> >> > session target ipv4:10.1.80.11
>>> >> >> > dtmf-relay h245-alphanumeric
>>> >> >> > codec g711ulaw
>>> >> >> > no vad
>>> >> >> > !
>>> >> >> > dial-peer voice 2000 voip
>>> >> >> > description outbound
>>> >> >> > translation-profile outgoing addone
>>> >> >> > preference 1
>>> >> >> > destination-pattern .T
>>> >> >> > rtp payload-type nse 101
>>> >> >> > rtp payload-type nte 100
>>> >> >> > voice-class sip asymmetric payload dtmf
>>> >> >> > session protocol sipv2
>>> >> >> > session target ipv4:64.154.41.200
>>> >> >> > dtmf-relay rtp-nte
>>> >> >> > codec g711ulaw
>>> >> >> > no vad
>>> >> >> > !
>>> >> >> > !
>>> >> >> > sip-ua
>>> >> >> > credentials username ***** password 7 ***** realm
>>> sip.talkinip.net
>>> >> >> > authentication username ***** password 7 *****
>>> >> >> > authentication username ***** password 7 ***** realm
>>> >> >> > sip.talkinip.net
>>> >> >> > set pstn-cause 3 sip-status 486
>>> >> >> > set pstn-cause 34 sip-status 486
>>> >> >> > set pstn-cause 47 sip-status 486
>>> >> >> > registrar dns:sip.talkinip.net expires 60
>>> >> >> > sip-server dns:sip.talkinip.net:5060
>>> >> >> > _______________________________________________
>>> >> >> > cisco-voip mailing list
>>> >> >> > cisco-voip at puck.nether.net
>>> >> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>>> >> >> >
>>> >> >> >
>>> >> >
>>> >> >
>>> >
>>> > _______________________________________________
>>> > cisco-voip mailing list
>>> > cisco-voip at puck.nether.net
>>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>>> >
>>> >
>>>
>>
>>
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/1eb5b65a/attachment-0001.html>
------------------------------
Message: 17
Date: Tue, 27 Oct 2009 15:27:59 -0400
From: "Jeff Cartier" <jcartier at acs.on.ca>
To: <cisco-voip at puck.nether.net>
Subject: [cisco-voip] Cisco 7961 - Wrong Time, No Local Directory, No
Services
Message-ID: <BCD3E762F1767C42A5226BBACDE49BFB010DBD14 at loki.acs.local>
Content-Type: text/plain; charset="us-ascii"
I'm having an issue with a Cisco 7961 phone not showing the proper time,
local directory and services. I think it is somehow related to the 'DNS
Unknown Host' error I'm getting when I look at the status messages.
Anyone seen anything similar? Odd thing is that I have DNS running.
jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/34ea31bc/attachment-0001.html>
------------------------------
Message: 18
Date: Tue, 27 Oct 2009 12:34:35 -0700
From: Scott Voll <svoll.voip at gmail.com>
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] What am I missing with Background images?
Message-ID:
<f84a38d30910271234oe28769bp4548f3cb9b3db7b4 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have uploaded both the thumb nail and full png file for the image I want
to use for a background. (both to the Desktops/320x196x4/ directory)
I have also added the list.xml file to both the root and the
Desktops/320x196x4/ and restarted both phone and TFTP server without being
able to get it to work. What am I missing?
Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/cde88dc2/attachment-0001.html>
------------------------------
Message: 19
Date: Tue, 27 Oct 2009 15:37:03 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID: <7B9D12A7-CBDA-4833-9C07-20172A0C6204 at cisco.com>
Content-Type: text/plain; charset="us-ascii"; Format="flowed";
DelSp="yes"
It means the router can't use payload type 101 for that call. What is
the config for the voip dial-peer getting used on the outbound call?
-Ryan
On Oct 27, 2009, at 3:16 PM, Dane Newman wrote:
Yes the session progress is receviced by the router
In all my debugs I noticed I have the same thing
*Oct 27 20:25:37.558: //1528/003E40690D00/SIP/Info/
sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.
*Oct 27 20:25:37.558: //1528/003E40690D00/SIP/Info/
sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option
*Oct 27 20:25:37.562: //1528/003E40690D00/SIP/Info/
sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
fmtp list of events.
*Oct 27 20:25:37.562: //-1/xxxxxxxxxxxx/SIP/Info/
sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
*Oct 27 20:25:37.562: //1528/003E40690D00/SIP/Info/
sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem
relay
Is Dynamic payload(101) could not be reserved telling me I have no
dtmf support?
On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <rratliff at cisco.com>
wrote:
I doubt that is related to your lack of DTMF but it's most likely the
side sending the 183 is actually counting 1-16 and printing the 0.
The Session Progress is received by the router isn't it?
There are only 16 DTMF characters, the 12 on your keypad and 4 hidden
ones A, B, C, and D.
-Ryan
On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:
The difference I see between the invite and the 183 session
progression from the telco is
invite
a=fmtp:101 0-15
session progression
a=fmtp:101 0-16
Could this miss match in supported digits be what is causing all dtmf
not to work? How can I make my cisco router support 0-16?
Dane
Invite
v=0
o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57
s=SIP Call
c=IN IP4 173.14.220.57
t=0 0
m=audio 18770 RTP/AVP 0 101 19
c=IN IP4 173.14.220.57
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=rtpmap:19 CN/8000
a=ptime:20
session progression
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 17646 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <rratliff at cisco.com>
wrote:
Sorry this part is the actual DTMF:
a=rtpmap:101 telephone-event/8000
The line you quoted is part of the SDP and references both RTP and DTMF.
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
The fist line means your RTP is on port 11680 and references the
a:rtpmap entries for 0 and 101.
The second line means your RTP is g.711.
The 3rd line is the DTMF with a payload type of 101.
The 4th line means it can accept DTMF 0-16
The last line is pretty self explanatory (silence suppression disabled).
This is a very basic interpretation of the SDP info. RFC 2327 is
where you want to go to get into the nitty-gritty details.
-Ryan
On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
That is RFC2833 DTMF with a payload type of 101.
I do know that CUBE cannot do dynamic RFC2833 payload types. It can
only send the payloadType defined in the voip dial-peer. So if
inbound calls use a different payloadType than outbound calls you will
want to update the dial-peers accordingly.
-Ryan
On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
Well I tried to switch providers just to test it out and now I am
getting something back in the 183 but still no dtmf hmm
I see they are sending me
m=audio 11680 RTP/AVP 0 101
How do I interperate that line?
Received:
SIP/2.0 183 Session Progress
Via: SIP/2.0/UDP
173.14.220.57:5060;branch=z9hG4bK749136B;received=173.14.220.57
From: <sip:6782282221 at did.voip.les.net>;tag=419FE94-8A1
To: <sip:18774675464 at did.voip.les.net>;tag=as5677a12c
Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
CSeq: 101 INVITE
User-Agent: LES.NET.VoIP
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Contact: <sip:18774675464 at 64.34.181.47>
Content-Type: application/sdp
Content-Length: 214
v=0
o=root 5115 5115 IN IP4 64.34.181.47
s=session
c=IN IP4 64.34.181.47
t=0 0
m=audio 11680 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckResponse: INVITE response with no RSEQ - disable IS_REL1XX
*Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD:
No GTD found in inbound container
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoMediaNegotiation: Number of m-lines = 1
SIP: Attribute mid, level 1 instance 1 not found.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
resolve_media_ip_address_to_bind: Media already bound, use existing
source_media_ip_addr
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Media/
sipSPISetMediaSrcAddr: Media src addr for stream 1 = 173.14.220.57
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec (g711ulaw) Negotiation Successful on
Static Payload for m-line 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoPtimeNegotiation: No ptime present or multiple ptime
attributes that can't be handled
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: m-line index 1
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPICheckDynPayloadUse: Dynamic payload(101) could not be reserved.
*Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF relay option
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoDTMFRelayNegotiation: Case of full named event(NE) match in
fmtp list of events.
*Oct 27 18:02:12.555: //-1/xxxxxxxxxxxx/SIP/Info/
sip_sdp_get_modem_relay_cap_params: NSE payload from X-cap = 0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sip_select_modem_relay_params: X-tmr not present in SDP. Disable modem
relay
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIGetSDPDirectionAttribute: No direction attribute present or
multiple direction attributes that can't be handled for m-line:1 and
num-a-lines:0
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Info/
sipSPIDoAudioNegotiation: Codec negotiation successful for media line 1
payload_type=0, codec_bytes=160, codec=g711ulaw,
dtmf_relay=rtp-nte
stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
dest_port=11680
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/State/
sipSPIChangeStreamState: Stream (callid = -1) State changed from
(STREAM_DEAD) to (STREAM_ADDING)
*Oct 27 18:02:12.555: //1345/0008DE602400/SIP/Media/
sipSPIUpdCallWithSdpInfo:
Preferred Codec : g711ulaw, bytes :160
Preferred DTMF relay : rtp-nte
Preferred NTE payload : 101
Early Media : No
Delayed Media : No
Bridge Done : No
New Media : No
DSP DNLD Reqd : No
On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>
wrote:
The 200 OK that you've pasted is confirming the CANCEL that we sent.
You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
a 200 OK with the CSeq for 101 INVITE.
I've seen this for certain IVRs/providers - sometimes they don't
properly terminate a call with a 200 OK. If you were not sending an
SDP in your original INVITE, then you would need the PRACK setting
mentioned. You have two problems, either could fix the problem: They
could advertise DTMF in their 183, or they could send you a 200 OK for
the call. It is assumed you would get DTMF in the 200 OK. It's
common for endpoints that support DTMF to not advertise it in the 183
because you technically shouldn't need DTMF to hear ringback.
-nick
On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
wrote:
> There is no SDP in that 200 OK so I would assume the media info is
the same
> as in the 183 Ringing message. You really need your ITSP to tell
you what
> dtmf method they want you to use on your outbound calls. As Nick
said they
> don't appear to be advertising any dtmf method at all.
> -Ryan
> On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
> Is the below the ok I should be getting?
>
>
> They did send this with the first debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
> From: <sip:6782282221 at sip.talkinip.net>;tag=32DA608-109A
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
> *Oct 27 13:44:12.836: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 13:44:12.840:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>
> This with the 2nd debug
>
> Received:
> SIP/2.0 200 OK
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> To: <sip:18774675464 at 64.154.41.200>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 CANCEL
> Content-Length: 0
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
> non-INVITE response with no RSEQ - do not disable IS_REL1XX
> *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
> CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
HandleUdpIPv4SocketReads:
> Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
> ccsip_spi_get_msg_type returned: 2 for event 1
> *Oct 27 12:34:15.912:
> //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
> context=0x00000000
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Info/
ccsip_new_msg_preprocessor:
> Checking Invite Dialog
> *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
> Received:
> SIP/2.0 487 Request Terminated
> To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
> From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
> Contact: <sip:18774675464 at 64.154.41.200:5060>
> Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
> CSeq: 102 INVITE
> Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
> Content-Length: 0
>
> On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews
<matthnick at gmail.com> wrote:
>>
>> In the 183 Session Progress they're not advertising DTMF:
>>
>> m=audio 45846 RTP/AVP 0
>>
>> There should be a 100 or 101 there. Although, 183 is just ringback.
>> You would want to pick up on the other side and they should send a
200
>> OK with a new SDP. If the other side did pick up, you need to tell
>> the provider that they need to send a 200 OK, because they're not.
>>
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Nick
>> >
>> > I removed voice-class sip asymmetric payload dtmf and added in
the
>> > other
>> > line
>> >
>> > Just to state incoming dtmf works but not outbound the ITSP has
told me
>> > they
>> > are using two different sip servers/vendors for processing
inbound and
>> > outbound
>> > How does this translate into what I should sent the following too?
>> >
>> > rtp payload-type nse
>> > rtp payload-type nte
>> >
>> > In the debug trhe following where set
>> >
>> > rtp payload-type nse 101
>> > rtp payload-type nte 100
>> >
>> > In the debug of ccsip If I am looking at it correctly I see me
sending
>> > this
>> >
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>> > Preferred method of dtmf relay is: 6, with payload: 100
>> > *Oct 27 12:34:09.128:
>> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>> > max_event 15
>> >
>> > and
>> >
>> >
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> >
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 101 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> >
>> >
>> > Then when I do a search for fmtp again further down I see
>> >
>> > Sent:
>> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Remote-Party-ID:
>> > <sip:
6782282221 at 173.14.220.57>;party=calling;screen=yes;privacy=off
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>> > Min-SE: 1800
>> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>> > User-Agent: Cisco-SIPGateway/IOS-12.x
>> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>> > SUBSCRIBE,
>> > NOTIFY, INFO, REGISTER
>> > CSeq: 102 INVITE
>> > Max-Forwards: 70
>> > Timestamp: 1256646849
>> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>> > Expires: 180
>> > Allow-Events: telephone-event
>> > Proxy-Authorization: Digest
>> >
>> > username="1648245954",realm="64.154.41.110",uri="sip:18774675464 at 64.154.41.200:5060
",response
=
"ab63d4755ff4182631ad2db0f9ed0e44
",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>> > Content-Type: application/sdp
>> > Content-Disposition: session;handling=required
>> > Content-Length: 250
>> > v=0
>> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>> > s=SIP Call
>> > c=IN IP4 173.14.220.57
>> > t=0 0
>> > m=audio 16462 RTP/AVP 0 100
>> > c=IN IP4 173.14.220.57
>> > a=rtpmap:0 PCMU/8000
>> > a=rtpmap:100 telephone-event/8000
>> > a=fmtp:100 0-15
>> > a=ptime:20
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:09.332:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 100 Trying
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Length: 0
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:09.332: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE) to
>> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:10.832:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 183 Session Progress
>> > To: <sip:18774675464 at 64.154.41.200>;tag=3465630735-938664
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 INVITE
>> > Content-Type: application/sdp
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > Content-Length: 146
>> > v=0
>> > o=msx71 490 6110 IN IP4 64.154.41.200
>> > s=sip call
>> > c=IN IP4 64.154.41.101
>> > t=0 0
>> > m=audio 45846 RTP/AVP 0
>> > a=ptime:20
>> > a=rtpmap:0 PCMU/8000
>> > *Oct 27 12:34:10.836: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > INVITE response with no RSEQ - disable IS_REL1XX
>> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentGTD: No
>> > GTD
>> > found in inbound container
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>> > Number of m-lines = 1
>> > SIP: Attribute mid, level 1 instance 1 not found.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec (g711ulaw) Negotiation Successful on Static Payload for m-
line 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>> > One ptime attribute found - value:20
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes:
Values :Codec:
>> > g711ulaw ptime :20, codecbytes: 160
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes:
160 for
>> > codec
>> > g711ulaw
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
index 1
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>> > Dynamic payload(100) could not be reserved.
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case
of full
>> > named
>> > event(NE) match in fmtp list of events.
>> > *Oct 27 12:34:10.836:
>> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>> > payload
>> > from X-cap = 0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
not
>> > present
>> > in SDP. Disable modem relay
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
direction
>> > attribute present or multiple direction attributes that can't be
handled
>> > for
>> > m-line:1 and num-a-lines:0
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>> > Codec negotiation successful for media line 1
>> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>> > dtmf_relay=rtp-nte
>> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>> > dest_port=45846
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>> > (STREAM_ADDING)
>> > *Oct 27 12:34:10.836:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Preferred Codec : g711ulaw, bytes :160
>> > Preferred DTMF relay : rtp-nte
>> > Preferred NTE payload : 100
>> > Early Media : No
>> > Delayed Media : No
>> > Bridge Done : No
>> > New Media : No
>> > DSP DNLD Reqd : No
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4A170B28)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Hndl ptype 0 mline 1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Selecting
>> > codec g711ulaw
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>> > Codec to be matched: 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
ADD
>> > AUDIO
>> > CODEC 5
>> > *Oct 27 12:34:10.840:
>> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime:
Values :Codec:
>> > g711ulaw codecbytes :160, ptime: 20
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Media
>> > negotiation done:
>> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
coverted
>> > ptime=20 stream->mline_index=1, media_ndx=1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1
ss 1
>> > 64.154.41.101:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
Copy
>> > sdp to
>> > channel- AFTER CODEC FILTERING:
>> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>> > Report initial call media
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
ccb->flags
>> > 0x400018, ccb->pld.flags_ipip 0x200005
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>> > callId 846 size 240 ptr 0x4DEC000C)
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>> > 5030: Posting Remote SRTP caps to other callleg.
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>> > cc_api_caps_ind()
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>> > Stream type : voice+dtmf
>> > Media line : 1
>> > State : STREAM_ADDING (2)
>> > Stream address type : 1
>> > Callid : 846
>> > Negotiated Codec : g711ulaw, bytes :160
>> > Nego. Codec payload : 0 (tx), 0 (rx)
>> > Negotiated DTMF relay : rtp-nte
>> > Negotiated NTE payload : 100 (tx), 100 (rx)
>> > Negotiated CN payload : 0
>> > Media Srce Addr/Port : [173.14.220.57]:16462
>> > Media Dest Addr/Port : [64.154.41.101]:45846
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>> > headers
>> > recvd from app container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQSIG:
>> > No
>> > QSIG Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPIGetContentQ931:
>> > No
>> > RawMsg Body found in inbound container
>> > *Oct 27 12:34:10.840: //-1/xxxxxxxxxxxx/SIP/Info/
sipSPICreateNewRawMsg:
>> > No
>> > Data to form The Raw Message
>> > *Oct 27 12:34:10.840:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>> > SUBSTATE_NONE)
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
Transaction
>> > Complete. Lock on Facilities released.
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
confID =
>> > 6,
>> > srcCallID = 846, dstCallID = 845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>> > Old streamcallid=846, new streamcallid=846
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>> > Setting SPI mode to SIP-H323
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
1131891908
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>> > sipSPIProcessRtpSessions
>> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/
sipSPIAddStream:
>> > Adding
>> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind:
Media
>> > already
>> > bound, use existing source_media_ip_addr
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>> > Media src addr for stream 1 = 173.14.220.57
>> > *Oct 27 12:34:10.844:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > sipSPIUpdateRtcpSession for m-line 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > rtcp_session info
>> > laddr = 173.14.220.57, lport = 16462, raddr =
64.154.41.101,
>> > rport=45846, do_rtcp=TRUE
>> > src_callid = 846, dest_callid = 845, stream type = voice
+dtmf,
>> > stream direction = SENDRECV
>> > media_ip_addr = 64.154.41.101, vrf tableid = 0
media_addr_type =
>> > 1
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>> > RTP session already created - update
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>> > New Remote Media Direction = SENDRECV
>> > Present Local Media Direction = SENDRECV
>> > New Local Media Direction = SENDRECV
>> > retVal = 0
>> > *Oct 27 12:34:10.848:
>> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>> > (STREAM_ACTIVE)
>> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
really
>> > can't
>> > find peer_stream for
>> > dtmf-relay
interworking
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x23ED
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.140:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Setting
>> > CAPS_RECEIVED flag
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > Calling
>> > cc_api_caps_ack()
>> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/
ccsip_caps_ack: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Entry
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
CURRENT
>> > VALUES: stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>> > VALUES:
>> > stream_callid=846, current_seq_num=0x11D9
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with negotiated codec: g711ulaw, Bytes=160
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Set
>> > forking flag to 0x0
>> > *Oct 27 12:34:11.168:
>> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
payload =
>> > 100, tx payload = 100
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>> > config=0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Disabling Modem Relay...
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Negotiation already Done. Set negotiated Modem caps and generate
SDP
>> > Xcap
>> > list
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > Modem
>> > Relay & Passthru both disabled
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
sip_set_modem_caps:
>> > nse
>> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
relay=0,
>> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 1
>> > Active Streams
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > Adding stream type (voice+dtmf) from media
>> > line 1 codec g711ulaw
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>> > caps.stream_list.xmitFunc=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > voip_rtp_xmit, caps.stream_list.context=
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Media/
sipSPISetStreamInfo:
>> > 0x497E0B60 (gccb)
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Load
>> > DSP
>> > with codec : g711ulaw, Bytes=160, payload = 0
>> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: No
>> > video
>> > caps detected in the caps posted by peer leg
>> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/
ccsip_caps_ind: Second
>> > TCS
>> > received for transfers across trunk - set CAPS2_RECEIVED
>> > *Oct 27 12:34:15.876:
>> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>> > stun is disabled for stream:4A1709F8
>> > *Oct 27 12:34:15.876: //846/8094E28C1800/SIP/Info/
ccsip_call_statistics:
>> > Stats are not supported for IPIP call.
>> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>> > Queued
>> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 3 for event 7
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/
sipSPISendCancel:
>> > Associated container=0x4E310C1C to Cancel
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Transport/
sipSPISendCancel:
>> > Sending CANCEL to the transport layer
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>> > msg=0x4DF0D994,
>> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,
transport=1,
>> > switch=0, callBack=0x419703BC
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
Proceedable
>> > for
>> > sending msg immediately
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>> > transport
>> > is 0
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set
to send
>> > the
>> > msg=0x4DF0D994
>> > *Oct 27 12:34:15.880:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:
Posting
>> > send
>> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for
UDP
>> > *Oct 27 12:34:15.880:
>> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>> > Sent Cancel Request, starting CancelWaitResponseTimer
>> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/State/
sipSPIChangeState:
>> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_NONE)
>> > to
>> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Sent:
>> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Max-Forwards: 70
>> > Timestamp: 1256646855
>> > Reason: Q.850;cause=16
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.900:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> > Received:
>> > SIP/2.0 200 OK
>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>> > From: <sip:6782282221 at sip.talkinip.net>;tag=2EDA9C8-25D6
>> > To: <sip:18774675464 at 64.154.41.200>
>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>> > CSeq: 102 CANCEL
>> > Content-Length: 0
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPICheckResponse:
>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/
sipSPIIcpifUpdate:
>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>> > ccsip_spi_get_msg_type returned: 2 for event 1
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>> > context=0x00000000
>> > *Oct 27 12:34:15.912:
>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>> > Checking Invite Dialog
>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>> >
>> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <matthnick at gmail.com
>
>> > wrote:
>> >>
>> >> You would want to check the SDP of 200 OK the provider sends
for your
>> >> outgoing call. It will list the payload type for the dtmf in the
>> >> format a=fmtp 101 1-16, or something similar. You want to find
out
>> >> what payload type they are advertising (or if they are at
all). It
>> >> would be worth checking the incoming INVITE from them to see what
>> >> they're using when they send the first SDP.
>> >>
>> >> On that note, I would also remove the asymmetric payload
command - to
>> >> my knowledge it doesn't do what you're expecting it to. You
may want
>> >> to try this command:
>> >> voice-class sip dtmf-relay force rtp-nte
>> >>
>> >>
>> >> -nick
>> >>
>> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <dane.newman at gmail.com
>
>> >> wrote:
>> >> > Hello,
>> >> >
>> >> > I am having an issue with dtmf working outbound. Inbound
dtmf works
>> >> > fine.
>> >> > It took some playing around with it. At first it didnt work
till the
>> >> > payload was ajusted. I am now trying to get outbound dtmf
working
>> >> > properly.
>> >> >
>> >> > On my 2821 I debugged voip rtp session named-events and then
made a
>> >> > call
>> >> > to
>> >> > a 1800 number and hit digits. I didn't see any dtmf output
on the
>> >> > router
>> >> > nothing showed up in the debug. Does this mean I can safely
asume
>> >> > that
>> >> > the
>> >> > problem for right now is not on the ITSP side but on my side
since
>> >> > dtmf
>> >> > is
>> >> > not being sent down the sip trunk?
>> >> >
>> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>> >> > configuration
>> >> > of the cisco 2821 is shown below. Does anyone have any ideas
what I
>> >> > can
>> >> > do
>> >> > so dtmf digits process properly outbound?
>> >> >
>> >> > The settings in my cuc 7.x to add the gateway h323 are
>> >> >
>> >> > h323 cucm gateway configuratration
>> >> > Signaling Port 1720
>> >> > media termination point required yes
>> >> > retry video call as auto yes
>> >> > wait for far end h.245 terminal capability set yes
>> >> > transmit utf-8 calling party name no
>> >> > h.235 pass through allowed no
>> >> > significant digits all
>> >> > redirect number IT deliver - inbound no
>> >> > enable inbound faststart yes
>> >> > display IE deliver no
>> >> > redirect nunmber IT deliver - outbound no
>> >> > enable outbound faststart yes
>> >> >
>> >> >
>> >> > voice service voip
>> >> > allow-connections h323 to h323
>> >> > allow-connections h323 to sip
>> >> > allow-connections sip to h323
>> >> > allow-connections sip to sip
>> >> > fax protocol pass-through g711ulaw
>> >> > h323
>> >> > emptycapability
>> >> > h225 id-passthru
>> >> > h245 passthru tcsnonstd-passthru
>> >> > sip
>> >> >
>> >> >
>> >> > voice class h323 50
>> >> > h225 timeout tcp establish 3
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > !
>> >> > voice translation-rule 1
>> >> > rule 1 /.*/ /190/
>> >> > !
>> >> > voice translation-rule 2
>> >> > rule 1 /.*/ /1&/
>> >> > !
>> >> > !
>> >> > voice translation-profile aa
>> >> > translate called 1
>> >> > !
>> >> > voice translation-profile addone
>> >> > translate called 2
>> >> > !
>> >> > !
>> >> > voice-card 0
>> >> > dspfarm
>> >> > dsp services dspfarm
>> >> > !
>> >> > !
>> >> > sccp local GigabitEthernet0/1
>> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>> >> > sccp
>> >> > !
>> >> > sccp ccm group 1
>> >> > associate ccm 1 priority 1
>> >> > associate ccm 2 priority 2
>> >> > associate profile 1 register 2821transcode
>> >> > !
>> >> > dspfarm profile 1 transcode
>> >> > codec g711ulaw
>> >> > codec g711alaw
>> >> > codec g729ar8
>> >> > codec g729abr8
>> >> > codec g729r8
>> >> > maximum sessions 4
>> >> > associate application SCCP
>> >> > !
>> >> > !
>> >> > dial-peer voice 100 voip
>> >> > description AA Publisher
>> >> > preference 1
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.10
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 1000 voip
>> >> > description incoming Call
>> >> > translation-profile incoming aa
>> >> > preference 1
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > incoming called-number 6782282221
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > ip qos dscp cs5 media
>> >> > ip qos dscp cs5 signaling
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 101 voip
>> >> > description AA Subscriber
>> >> > preference 2
>> >> > destination-pattern 1..
>> >> > voice-class h323 50
>> >> > session target ipv4:10.1.80.11
>> >> > dtmf-relay h245-alphanumeric
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > dial-peer voice 2000 voip
>> >> > description outbound
>> >> > translation-profile outgoing addone
>> >> > preference 1
>> >> > destination-pattern .T
>> >> > rtp payload-type nse 101
>> >> > rtp payload-type nte 100
>> >> > voice-class sip asymmetric payload dtmf
>> >> > session protocol sipv2
>> >> > session target ipv4:64.154.41.200
>> >> > dtmf-relay rtp-nte
>> >> > codec g711ulaw
>> >> > no vad
>> >> > !
>> >> > !
>> >> > sip-ua
>> >> > credentials username ***** password 7 ***** realm sip.talkinip.net
>> >> > authentication username ***** password 7 *****
>> >> > authentication username ***** password 7 ***** realm
>> >> > sip.talkinip.net
>> >> > set pstn-cause 3 sip-status 486
>> >> > set pstn-cause 34 sip-status 486
>> >> > set pstn-cause 47 sip-status 486
>> >> > registrar dns:sip.talkinip.net expires 60
>> >> > sip-server dns:sip.talkinip.net:5060
>> >> > _______________________________________________
>> >> > cisco-voip mailing list
>> >> > cisco-voip at puck.nether.net
>> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>> >> >
>> >> >
>> >
>> >
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/8a3fd6d4/attachment-0001.html>
------------------------------
Message: 20
Date: Tue, 27 Oct 2009 15:38:59 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Jeff Cartier <jcartier at acs.on.ca>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] Cisco 7961 - Wrong Time, No Local Directory,
No Services
Message-ID: <7D5EAED9-A0A4-45D1-9E94-422BE71EF24D at cisco.com>
Content-Type: text/plain; charset="windows-1252"; Format="flowed";
DelSp="yes"
Regarding the DNS Unknown Host error it's not affecting your time, but
is breaking your services/directories. What version of CUCM are you
using?
Keep in mind that just because you have DNS configured doesn't mean
the phone is able to resolve whatever it is trying to.
-Ryan
On Oct 27, 2009, at 3:27 PM, Jeff Cartier wrote:
I?m having an issue with a Cisco 7961 phone not showing the proper
time, local directory and services. I think it is somehow related to
the ?DNS Unknown Host? error I?m getting when I look at the status
messages. Anyone seen anything similar? Odd thing is that I have DNS
running.
jeff
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/27bbfea4/attachment-0001.html>
------------------------------
Message: 21
Date: Tue, 27 Oct 2009 15:39:52 -0400
From: Ryan Ratliff <rratliff at cisco.com>
To: Scott Voll <svoll.voip at gmail.com>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] What am I missing with Background images?
Message-ID: <02E27121-B64C-43EE-B0A8-1888867A3462 at cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Get a packet capture from behind the phone, is it getting all of the
files it is asking for? If so do cmd-line tftp requests for the same
files and make sure they are valid.
-Ryan
On Oct 27, 2009, at 3:34 PM, Scott Voll wrote:
I have uploaded both the thumb nail and full png file for the image I
want to use for a background. (both to the Desktops/320x196x4/
directory)
I have also added the list.xml file to both the root and the Desktops/
320x196x4/ and restarted both phone and TFTP server without being able
to get it to work. What am I missing?
Scott
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
------------------------------
Message: 22
Date: Tue, 27 Oct 2009 15:38:50 -0400
From: "Joe Pollere (US)" <Joe.Pollere at us.didata.com>
To: "Scott Voll" <svoll.voip at gmail.com>, <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] What am I missing with Background images?
Message-ID:
<C65033A817B5734392E55CB9DF4461041B9E4741 at USNAEXCH.na.didata.local>
Content-Type: text/plain; charset="us-ascii"
It is case sensitive. list.xml should be List.xml
From: cisco-voip-bounces at puck.nether.net
[mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Scott Voll
Sent: Tuesday, October 27, 2009 3:35 PM
To: cisco-voip at puck.nether.net
Subject: [cisco-voip] What am I missing with Background images?
I have uploaded both the thumb nail and full png file for the image I
want to use for a background. (both to the Desktops/320x196x4/
directory)
I have also added the list.xml file to both the root and the
Desktops/320x196x4/ and restarted both phone and TFTP server without
being able to get it to work. What am I missing?
Scott
-----------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/baa97e31/attachment-0001.html>
------------------------------
Message: 23
Date: Tue, 27 Oct 2009 15:45:46 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Ryan Ratliff <rratliff at cisco.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271245m17958ab6i8976410b64f45294 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hmm that does not sound good
This is with the default settings
rtp payload-type nte 101
rtp payload-type nse 100
which don't show up in the config. Could there be any reason why the router
is not able to use 101 below are my dial peers
dial-peer voice 100 voip
description AA Publisher
preference 1
destination-pattern 1..
voice-class h323 50
session target ipv4:10.1.80.10
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
dial-peer voice 1000 voip
description incoming Call
translation-profile incoming aa
preference 1
incoming called-number 6784442454
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
dial-peer voice 101 voip
description AA Subscriber
preference 2
destination-pattern 1..
voice-class h323 50
session target ipv4:10.1.80.11
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
dial-peer voice 2000 voip
description outbound
translation-profile outgoing addone
preference 1
destination-pattern .T
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target dns:did.voip.les.net
dtmf-relay rtp-nte
codec g711ulaw
!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/0d809b65/attachment-0001.html>
------------------------------
Message: 24
Date: Tue, 27 Oct 2009 16:30:02 -0400
From: Nick Matthews <matthnick at gmail.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<56c3b48b0910271330m5895ceco6ab5315dd410c29a at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
That shows up in the debugs in working scenarios too. Not sure what
the importance of those statements are, but it's the type of thing you
see when you add 'all' to a debug.
It's not the 183 you want to look at, but the 200 OK with the CSeq of
your INVITE. And you want a 200 OK. I've seen it where the debugs
will show that we're sending DTMF but the provider won't use it, which
is a conversation you would need to have with the provider.
-nick
On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com> wrote:
> Hmm that does not sound good
>
> This is with the default settings
>
> rtp payload-type nte 101
> rtp payload-type nse 100
>
> which don't show up in the config.? Could there be any reason why the router
> is not able to use 101 below are my dial peers
>
> dial-peer voice 100 voip
> ?description AA Publisher
> ?preference 1
> ?destination-pattern 1..
> ?voice-class h323 50
> ?session target ipv4:10.1.80.10
> ?dtmf-relay h245-alphanumeric
> ?codec g711ulaw
> ?no vad
> !
> dial-peer voice 1000 voip
> ?description incoming Call
> ?translation-profile incoming aa
> ?preference 1
>
> ?incoming called-number 6784442454
>
> ?dtmf-relay rtp-nte
> ?codec g711ulaw
> ?ip qos dscp cs5 media
> ?ip qos dscp cs5 signaling
> ?no vad
> !
> dial-peer voice 101 voip
> ?description AA Subscriber
> ?preference 2
> ?destination-pattern 1..
> ?voice-class h323 50
> ?session target ipv4:10.1.80.11
> ?dtmf-relay h245-alphanumeric
> ?codec g711ulaw
> ?no vad
> !
> dial-peer voice 2000 voip
> ?description outbound
> ?translation-profile outgoing addone
> ?preference 1
> ?destination-pattern .T
>
> ?progress_ind setup enable 3
> ?progress_ind progress enable 8
> ?session protocol sipv2
> ?session target dns:did.voip.les.net
>
> ?dtmf-relay rtp-nte
> ?codec g711ulaw
>
> !
------------------------------
Message: 25
Date: Tue, 27 Oct 2009 15:42:34 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Ryan Ratliff <rratliff at cisco.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271242w6cf18450v4551dd5e7237855 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hmm that does not sound good
This is with the default settings
rtp payload-type nte 101
rtp payload-type nse 100
which don't show up in the config. Could there be any reason why the router
is not able to use 101 below are my dial peers
dial-peer voice 100 voip
description AA Publisher
preference 1
destination-pattern 1..
voice-class h323 50
session target ipv4:10.1.80.10
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
dial-peer voice 1000 voip
description incoming Call
translation-profile incoming aa
preference 1
incoming called-number 6784442454
dtmf-relay rtp-nte
codec g711ulaw
ip qos dscp cs5 media
ip qos dscp cs5 signaling
no vad
!
dial-peer voice 101 voip
description AA Subscriber
preference 2
destination-pattern 1..
voice-class h323 50
session target ipv4:10.1.80.11
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
dial-peer voice 2000 voip
description outbound
translation-profile outgoing addone
preference 1
destination-pattern .T
progress_ind setup enable 3
progress_ind progress enable 8
session protocol sipv2
session target dns:did.voip.les.net
dtmf-relay rtp-nte
codec g711ulaw
!
!
On Tue, Oct 27, 2009 at 3:37 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
> It means the router can't use payload type 101 for that call. What is the
> config for the voip dial-peer getting used on the outbound call?
>
> -Ryan
>
> On Oct 27, 2009, at 3:16 PM, Dane Newman wrote:
>
> Yes the session progress is receviced by the router
>
> In all my debugs I noticed I have the same thing
>
> *Oct 27 20:25:37.558:
> //1528/003E40690D00/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)
> could not be reserved.
> *Oct 27 20:25:37.558:
> //1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
> relay option
> *Oct 27 20:25:37.562:
> //1528/003E40690D00/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
> named event(NE) match in fmtp list of events.
> *Oct 27 20:25:37.562:
> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
> from X-cap = 0
> *Oct 27 20:25:37.562:
> //1528/003E40690D00/SIP/Info/sip_select_modem_relay_params: X-tmr not
> present in SDP. Disable modem relay
>
> Is Dynamic payload(101) could not be reserved telling me I have no dtmf
> support?
>
> On Tue, Oct 27, 2009 at 2:56 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>
>> I doubt that is related to your lack of DTMF but it's most likely the side
>> sending the 183 is actually counting 1-16 and printing the 0. The Session
>> Progress is received by the router isn't it?
>>
>> There are only 16 DTMF characters, the 12 on your keypad and 4 hidden ones
>> A, B, C, and D.
>>
>> -Ryan
>>
>> On Oct 27, 2009, at 2:48 PM, Dane Newman wrote:
>>
>> The difference I see between the invite and the 183 session progression
>> from the telco is
>>
>> invite
>> a=fmtp:101 0-15
>>
>> session progression
>> a=fmtp:101 0-16
>>
>> Could this miss match in supported digits be what is causing all dtmf not
>> to work? How can I make my cisco router support 0-16?
>>
>> Dane
>>
>> *Invite*
>> **
>> **
>> v=0
>> o=CiscoSystemsSIP-GW-UserAgent 2461 126 IN IP4 173.14.220.57
>> s=SIP Call
>> c=IN IP4 173.14.220.57
>> t=0 0
>> m=audio 18770 RTP/AVP 0 101 19
>> c=IN IP4 173.14.220.57
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-15
>> a=rtpmap:19 CN/8000
>> a=ptime:20
>>
>>
>>
>> *session progression*
>>
>>
>> v=0
>> o=root 5115 5115 IN IP4 64.34.181.47
>> s=session
>> c=IN IP4 64.34.181.47
>> t=0 0
>> m=audio 17646 RTP/AVP 0 101
>> a=rtpmap:0 PCMU/8000
>> a=rtpmap:101 telephone-event/8000
>> a=fmtp:101 0-16
>> a=silenceSupp:off - - - -
>>
>> On Tue, Oct 27, 2009 at 2:10 PM, Ryan Ratliff <rratliff at cisco.com> wrote:
>>
>>> Sorry this part is the actual DTMF:
>>>
>>> a=rtpmap:101 telephone-event/8000
>>>
>>> The line you quoted is part of the SDP and references both RTP and DTMF.
>>> m=audio 11680 RTP/AVP 0 101
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=silenceSupp:off - - - -
>>>
>>> The fist line means your RTP is on port 11680 and references the a:rtpmap
>>> entries for 0 and 101.
>>> The second line means your RTP is g.711.
>>> The 3rd line is the DTMF with a payload type of 101.
>>> The 4th line means it can accept DTMF 0-16
>>> The last line is pretty self explanatory (silence suppression disabled).
>>>
>>> This is a very basic interpretation of the SDP info. RFC 2327 is where
>>> you want to go to get into the nitty-gritty details.
>>>
>>> -Ryan
>>>
>>> On Oct 27, 2009, at 2:00 PM, Ryan Ratliff wrote:
>>>
>>> That is RFC2833 DTMF with a payload type of 101.
>>>
>>> I do know that CUBE cannot do dynamic RFC2833 payload types. It can only
>>> send the payloadType defined in the voip dial-peer. So if inbound calls use
>>> a different payloadType than outbound calls you will want to update the
>>> dial-peers accordingly.
>>>
>>>
>>> -Ryan
>>>
>>> On Oct 27, 2009, at 12:56 PM, Dane Newman wrote:
>>>
>>> Well I tried to switch providers just to test it out and now I am getting
>>> something back in the 183 but still no dtmf hmm
>>>
>>> I see they are sending me
>>>
>>> m=audio 11680 RTP/AVP 0 101
>>>
>>> How do I interperate that line?
>>>
>>>
>>> Received:
>>> SIP/2.0 183 Session Progress
>>> Via: SIP/2.0/UDP 173.14.220.57:5060
>>> ;branch=z9hG4bK749136B;received=173.14.220.57
>>> From: <sip:6782282221 at did.voip.les.net<sip%3A6782282221 at did.voip.les.net>
>>> >;tag=419FE94-8A1
>>> To: <sip:18774675464 at did.voip.les.net<sip%3A18774675464 at did.voip.les.net>
>>> >;tag=as5677a12c
>>> Call-ID: AF45B372-C25911DE-80DAC992-790F56B7 at 173.14.220.57
>>> CSeq: 101 INVITE
>>> User-Agent: LES.NET.VoIP
>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
>>> Contact: <sip:18774675464 at 64.34.181.47 <sip%3A18774675464 at 64.34.181.47>>
>>> Content-Type: application/sdp
>>> Content-Length: 214
>>> v=0
>>> o=root 5115 5115 IN IP4 64.34.181.47
>>> s=session
>>> c=IN IP4 64.34.181.47
>>> t=0 0
>>> m=audio 11680 RTP/AVP 0 101
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> a=silenceSupp:off - - - -
>>> *Oct 27 18:02:12.551: //1345/0008DE602400/SIP/Info/sipSPICheckResponse:
>>> INVITE response with no RSEQ - disable IS_REL1XX
>>> *Oct 27 18:02:12.551: //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No
>>> GTD found in inbound container
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoMediaNegotiation: Number of m-lines = 1
>>> SIP: Attribute mid, level 1 instance 1 not found.
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/resolve_media_ip_address_to_bind: Media already
>>> bound, use existing source_media_ip_addr
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Media/sipSPISetMediaSrcAddr: Media src addr for
>>> stream 1 = 173.14.220.57
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec (g711ulaw)
>>> Negotiation Successful on Static Payload for m-line 1
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoPtimeNegotiation: No ptime present or
>>> multiple ptime attributes that can't be handled
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line index 1
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPICheckDynPayloadUse: Dynamic payload(101)
>>> could not be reserved.
>>> *Oct 27 18:02:12.551:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: RTP-NTE DTMF
>>> relay option
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of full
>>> named event(NE) match in fmtp list of events.
>>> *Oct 27 18:02:12.555:
>>> //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE payload
>>> from X-cap = 0
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/Info/sip_select_modem_relay_params: X-tmr not
>>> present in SDP. Disable modem relay
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/Info/sipSPIGetSDPDirectionAttribute: No direction
>>> attribute present or multiple direction attributes that can't be handled for
>>> m-line:1 and num-a-lines:0
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/Info/sipSPIDoAudioNegotiation: Codec negotiation
>>> successful for media line 1
>>> payload_type=0, codec_bytes=160, codec=g711ulaw,
>>> dtmf_relay=rtp-nte
>>> stream_type=voice+dtmf (1), dest_ip_address=64.34.181.47,
>>> dest_port=11680
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/State/sipSPIChangeStreamState: Stream (callid =
>>> -1) State changed from (STREAM_DEAD) to (STREAM_ADDING)
>>> *Oct 27 18:02:12.555:
>>> //1345/0008DE602400/SIP/Media/sipSPIUpdCallWithSdpInfo:
>>> Preferred Codec : g711ulaw, bytes :160
>>> Preferred DTMF relay : rtp-nte
>>> Preferred NTE payload : 101
>>> Early Media : No
>>> Delayed Media : No
>>> Bridge Done : No
>>> New Media : No
>>> DSP DNLD Reqd : No
>>>
>>> On Tue, Oct 27, 2009 at 10:47 AM, Nick Matthews <matthnick at gmail.com>wrote:
>>>
>>>> The 200 OK that you've pasted is confirming the CANCEL that we sent.
>>>> You can tell because in the 200 OK: CSeq: 102 CANCEL. You should see
>>>> a 200 OK with the CSeq for 101 INVITE.
>>>>
>>>> I've seen this for certain IVRs/providers - sometimes they don't
>>>> properly terminate a call with a 200 OK. If you were not sending an
>>>> SDP in your original INVITE, then you would need the PRACK setting
>>>> mentioned. You have two problems, either could fix the problem: They
>>>> could advertise DTMF in their 183, or they could send you a 200 OK for
>>>> the call. It is assumed you would get DTMF in the 200 OK. It's
>>>> common for endpoints that support DTMF to not advertise it in the 183
>>>> because you technically shouldn't need DTMF to hear ringback.
>>>>
>>>> -nick
>>>>
>>>> On Tue, Oct 27, 2009 at 9:30 AM, Ryan Ratliff <rratliff at cisco.com>
>>>> wrote:
>>>> > There is no SDP in that 200 OK so I would assume the media info is the
>>>> same
>>>> > as in the 183 Ringing message. You really need your ITSP to tell you
>>>> what
>>>> > dtmf method they want you to use on your outbound calls. As Nick
>>>> said they
>>>> > don't appear to be advertising any dtmf method at all.
>>>> > -Ryan
>>>> > On Oct 27, 2009, at 8:51 AM, Dane Newman wrote:
>>>> > Is the below the ok I should be getting?
>>>> >
>>>> >
>>>> > They did send this with the first debug
>>>> >
>>>> > Received:
>>>> > SIP/2.0 200 OK
>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK51214CC
>>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=32DA608-109A
>>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>>>> > Call-ID: 9F060E11-C23511DE-8027C992-790F56B7 at 173.14.220.57
>>>> > CSeq: 102 CANCEL
>>>> > Content-Length: 0
>>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPICheckResponse:
>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>>> > *Oct 27 13:44:12.828: //922/009B1B501B00/SIP/Info/sipSPIIcpifUpdate:
>>>> > CallState: 3 Playout: 0 DiscTime:5333362 ConnTime 0
>>>> > *Oct 27 13:44:12.836:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> > *Oct 27 13:44:12.840:
>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> > *Oct 27 13:44:12.840:
>>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> > context=0x00000000
>>>> > *Oct 27 13:44:12.840:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> > Checking Invite Dialog
>>>> > *Oct 27 13:44:12.840: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >
>>>> > This with the 2nd debug
>>>> >
>>>> > Received:
>>>> > SIP/2.0 200 OK
>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>>
>>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> > CSeq: 102 CANCEL
>>>> > Content-Length: 0
>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>>> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>>> > *Oct 27 12:34:15.900: //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>>>> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>>>> > *Oct 27 12:34:15.912:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> > *Oct 27 12:34:15.912:
>>>> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> > *Oct 27 12:34:15.912:
>>>> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> > context=0x00000000
>>>> > *Oct 27 12:34:15.912:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> > Checking Invite Dialog
>>>> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> > Received:
>>>> > SIP/2.0 487 Request Terminated
>>>> > To: <sip:18774675464 at 64.154.41.200 <sip%3A18774675464 at 64.154.41.200>
>>>> >;tag=3465630735-938664
>>>> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>>>> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> > CSeq: 102 INVITE
>>>> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> > Content-Length: 0
>>>> >
>>>> > On Tue, Oct 27, 2009 at 8:43 AM, Nick Matthews <matthnick at gmail.com>
>>>> wrote:
>>>> >>
>>>> >> In the 183 Session Progress they're not advertising DTMF:
>>>> >>
>>>> >> m=audio 45846 RTP/AVP 0
>>>> >>
>>>> >> There should be a 100 or 101 there. Although, 183 is just ringback.
>>>> >> You would want to pick up on the other side and they should send a
>>>> 200
>>>> >> OK with a new SDP. If the other side did pick up, you need to tell
>>>> >> the provider that they need to send a 200 OK, because they're not.
>>>> >>
>>>> >>
>>>> >> -nick
>>>> >>
>>>> >> On Tue, Oct 27, 2009 at 7:36 AM, Dane Newman <dane.newman at gmail.com>
>>>> >> wrote:
>>>> >> > Nick
>>>> >> >
>>>> >> > I removed voice-class sip asymmetric payload dtmf and added in the
>>>> >> > other
>>>> >> > line
>>>> >> >
>>>> >> > Just to state incoming dtmf works but not outbound the ITSP has
>>>> told me
>>>> >> > they
>>>> >> > are using two different sip servers/vendors for processing inbound
>>>> and
>>>> >> > outbound
>>>> >> > How does this translate into what I should sent the following too?
>>>> >> >
>>>> >> > rtp payload-type nse
>>>> >> > rtp payload-type nte
>>>> >> >
>>>> >> > In the debug trhe following where set
>>>> >> >
>>>> >> > rtp payload-type nse 101
>>>> >> > rtp payload-type nte 100
>>>> >> >
>>>> >> > In the debug of ccsip If I am looking at it correctly I see me
>>>> sending
>>>> >> > this
>>>> >> >
>>>> >> > *Oct 27 12:34:09.128:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIAddSDPMediaPayload:
>>>> >> > Preferred method of dtmf relay is: 6, with payload: 100
>>>> >> > *Oct 27 12:34:09.128:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIAddSDPPayloadAttributes:
>>>> >> > max_event 15
>>>> >> >
>>>> >> > and
>>>> >> >
>>>> >> >
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>>>> >> > payload
>>>> >> > from X-cap = 0
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
>>>> not
>>>> >> > present
>>>> >> > in SDP. Disable modem relay
>>>> >> >
>>>> >> >
>>>> >> > Sent:
>>>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A01ECD
>>>> >> > Remote-Party-ID:
>>>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>>>> >;party=calling;screen=yes;privacy=off
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >
>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>> >> > Min-SE: 1800
>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> >> > SUBSCRIBE,
>>>> >> > NOTIFY, INFO, REGISTER
>>>> >> > CSeq: 101 INVITE
>>>> >> > Max-Forwards: 70
>>>> >> > Timestamp: 1256646849
>>>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>>>> >> > Expires: 180
>>>> >> > Allow-Events: telephone-event
>>>> >> > Content-Type: application/sdp
>>>> >> > Content-Disposition: session;handling=required
>>>> >> > Content-Length: 250
>>>> >> > v=0
>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>>>> >> > s=SIP Call
>>>> >> > c=IN IP4 173.14.220.57
>>>> >> > t=0 0
>>>> >> > m=audio 16462 RTP/AVP 0 100
>>>> >> > c=IN IP4 173.14.220.57
>>>> >> > a=rtpmap:0 PCMU/8000
>>>> >> > a=rtpmap:100 telephone-event/8000
>>>> >> > a=fmtp:100 0-15
>>>> >> > a=ptime:20
>>>> >> >
>>>> >> >
>>>> >> > Then when I do a search for fmtp again further down I see
>>>> >> >
>>>> >> > Sent:
>>>> >> > INVITE sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> >> > Remote-Party-ID:
>>>> >> > <sip:6782282221 at 173.14.220.57 <sip%3A6782282221 at 173.14.220.57>
>>>> >;party=calling;screen=yes;privacy=off
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >
>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>>> >> > Min-SE: 1800
>>>> >> > Cisco-Guid: 2157240972-3604177326-402682881-167847941
>>>> >> > User-Agent: Cisco-SIPGateway/IOS-12.x
>>>> >> > Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
>>>> >> > SUBSCRIBE,
>>>> >> > NOTIFY, INFO, REGISTER
>>>> >> > CSeq: 102 INVITE
>>>> >> > Max-Forwards: 70
>>>> >> > Timestamp: 1256646849
>>>> >> > Contact: <sip:6782282221 at 173.14.220.57:5060>
>>>> >> > Expires: 180
>>>> >> > Allow-Events: telephone-event
>>>> >> > Proxy-Authorization: Digest
>>>> >> >
>>>> >> > username="1648245954",realm="64.154.41.110",uri="
>>>> sip:18774675464 at 64.154.41.200:5060
>>>> ",response="ab63d4755ff4182631ad2db0f9ed0e44",nonce="12901115532:303fa5d884d6d0a5a0328a838545395b",algorithm=MD5
>>>> >> > Content-Type: application/sdp
>>>> >> > Content-Disposition: session;handling=required
>>>> >> > Content-Length: 250
>>>> >> > v=0
>>>> >> > o=CiscoSystemsSIP-GW-UserAgent 7043 4703 IN IP4 173.14.220.57
>>>> >> > s=SIP Call
>>>> >> > c=IN IP4 173.14.220.57
>>>> >> > t=0 0
>>>> >> > m=audio 16462 RTP/AVP 0 100
>>>> >> > c=IN IP4 173.14.220.57
>>>> >> > a=rtpmap:0 PCMU/8000
>>>> >> > a=rtpmap:100 telephone-event/8000
>>>> >> > a=fmtp:100 0-15
>>>> >> > a=ptime:20
>>>> >> > *Oct 27 12:34:09.332:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> >> > *Oct 27 12:34:09.332:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> >> > *Oct 27 12:34:09.332:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> >> > context=0x00000000
>>>> >> > *Oct 27 12:34:09.332:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> >> > Checking Invite Dialog
>>>> >> > *Oct 27 12:34:09.332: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >> > Received:
>>>> >> > SIP/2.0 100 Trying
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > CSeq: 102 INVITE
>>>> >> > Content-Length: 0
>>>> >> > *Oct 27 12:34:09.332:
>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>>>> >> > *Oct 27 12:34:09.332:
>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>>> >> > 0x4A357FCC : State change from (STATE_SENT_INVITE, SUBSTATE_NONE)
>>>> to
>>>> >> > (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)
>>>> >> > *Oct 27 12:34:10.832:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> >> > *Oct 27 12:34:10.832:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> >> > *Oct 27 12:34:10.832:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> >> > context=0x00000000
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> >> > Checking Invite Dialog
>>>> >> > *Oct 27 12:34:10.836: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >> > Received:
>>>> >> > SIP/2.0 183 Session Progress
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >;tag=3465630735-938664
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > Contact: <sip:18774675464 at 64.154.41.200:5060>
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > CSeq: 102 INVITE
>>>> >> > Content-Type: application/sdp
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> >> > Content-Length: 146
>>>> >> > v=0
>>>> >> > o=msx71 490 6110 IN IP4 64.154.41.200
>>>> >> > s=sip call
>>>> >> > c=IN IP4 64.154.41.101
>>>> >> > t=0 0
>>>> >> > m=audio 45846 RTP/AVP 0
>>>> >> > a=ptime:20
>>>> >> > a=rtpmap:0 PCMU/8000
>>>> >> > *Oct 27 12:34:10.836:
>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>>> >> > INVITE response with no RSEQ - disable IS_REL1XX
>>>> >> > *Oct 27 12:34:10.836:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentGTD: No
>>>> >> > GTD
>>>> >> > found in inbound container
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoMediaNegotiation:
>>>> >> > Number of m-lines = 1
>>>> >> > SIP: Attribute mid, level 1 instance 1 not found.
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>>> >> > already
>>>> >> > bound, use existing source_media_ip_addr
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>>> >> > Media src addr for stream 1 = 173.14.220.57
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>>>> >> > Codec (g711ulaw) Negotiation Successful on Static Payload for
>>>> m-line 1
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoPtimeNegotiation:
>>>> >> > One ptime attribute found - value:20
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_ptime_to_codec_bytes: Values
>>>> :Codec:
>>>> >> > g711ulaw ptime :20, codecbytes: 160
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>>>> :Codec:
>>>> >> > g711ulaw codecbytes :160, ptime: 20
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIDoPtimeNegotiation:
>>>> >> > Offered ptime:20, Negotiated ptime:20 Negotiated codec bytes: 160
>>>> for
>>>> >> > codec
>>>> >> > g711ulaw
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: m-line
>>>> index 1
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPICheckDynPayloadUse:
>>>> >> > Dynamic payload(100) could not be reserved.
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoDTMFRelayNegotiation: Case of
>>>> full
>>>> >> > named
>>>> >> > event(NE) match in fmtp list of events.
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/sip_sdp_get_modem_relay_cap_params: NSE
>>>> >> > payload
>>>> >> > from X-cap = 0
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sip_select_modem_relay_params: X-tmr
>>>> not
>>>> >> > present
>>>> >> > in SDP. Disable modem relay
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIGetSDPDirectionAttribute: No
>>>> direction
>>>> >> > attribute present or multiple direction attributes that can't be
>>>> handled
>>>> >> > for
>>>> >> > m-line:1 and num-a-lines:0
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIDoAudioNegotiation:
>>>> >> > Codec negotiation successful for media line 1
>>>> >> > payload_type=0, codec_bytes=160, codec=g711ulaw,
>>>> >> > dtmf_relay=rtp-nte
>>>> >> > stream_type=voice+dtmf (1), dest_ip_address=64.154.41.101,
>>>> >> > dest_port=45846
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>>>> >> > Stream (callid = -1) State changed from (STREAM_DEAD) to
>>>> >> > (STREAM_ADDING)
>>>> >> > *Oct 27 12:34:10.836:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>>>> >> > Preferred Codec : g711ulaw, bytes :160
>>>> >> > Preferred DTMF relay : rtp-nte
>>>> >> > Preferred NTE payload : 100
>>>> >> > Early Media : No
>>>> >> > Delayed Media : No
>>>> >> > Bridge Done : No
>>>> >> > New Media : No
>>>> >> > DSP DNLD Reqd : No
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>>> >> > already
>>>> >> > bound, use existing source_media_ip_addr
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>>> >> > Media src addr for stream 1 = 173.14.220.57
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>>> >> > callId 846 peer 845 flags 0x200005 state STATE_RECD_PROCEEDING
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> >> > CallID 846, sdp 0x497E29C0 channels 0x4A35926C
>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>>>> >> > callId 846 size 240 ptr 0x4A170B28)
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> >> > Hndl ptype 0 mline 1
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> >> > Selecting
>>>> >> > codec g711ulaw
>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/codec_found:
>>>> >> > Codec to be matched: 5
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> ADD
>>>> >> > AUDIO
>>>> >> > CODEC 5
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/convert_codec_bytes_to_ptime: Values
>>>> :Codec:
>>>> >> > g711ulaw codecbytes :160, ptime: 20
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> Media
>>>> >> > negotiation done:
>>>> >> > stream->negotiated_ptime=20,stream->negotiated_codec_bytes=160,
>>>> coverted
>>>> >> > ptime=20 stream->mline_index=1, media_ndx=1
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> >> > Adding codec 5 ptype 0 time 20, bytes 160 as channel 0 mline 1 ss
>>>> 1
>>>> >> > 64.154.41.101:45846
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> Copy
>>>> >> > sdp to
>>>> >> > channel- AFTER CODEC FILTERING:
>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = 5
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_copy_sdp_to_channelInfo:
>>>> Copy
>>>> >> > sdp to
>>>> >> > channel- AFTER CODEC FILTERING:
>>>> >> > ccb->pld.ipip_caps.codecInfo[channel_ndx].codec = -1
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>>> >> > callId 846 flags 0x100 state STATE_RECD_PROCEEDING
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>>> >> > Report initial call media
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer:
>>>> ccb->flags
>>>> >> > 0x400018, ccb->pld.flags_ipip 0x200005
>>>> >> > *Oct 27 12:34:10.840: //846/8094E28C1800/SIP/Info/copy_channels:
>>>> >> > callId 846 size 240 ptr 0x4DEC000C)
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_update_srtp_caps:
>>>> >> > 5030: Posting Remote SRTP caps to other callleg.
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPI_ipip_report_media_to_peer: do
>>>> >> > cc_api_caps_ind()
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdCallWithSdpInfo:
>>>> >> > Stream type : voice+dtmf
>>>> >> > Media line : 1
>>>> >> > State : STREAM_ADDING (2)
>>>> >> > Stream address type : 1
>>>> >> > Callid : 846
>>>> >> > Negotiated Codec : g711ulaw, bytes :160
>>>> >> > Nego. Codec payload : 0 (tx), 0 (rx)
>>>> >> > Negotiated DTMF relay : rtp-nte
>>>> >> > Negotiated NTE payload : 100 (tx), 100 (rx)
>>>> >> > Negotiated CN payload : 0
>>>> >> > Media Srce Addr/Port : [173.14.220.57]:16462
>>>> >> > Media Dest Addr/Port : [64.154.41.101]:45846
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIProcessHistoryInfoHeader: No HI
>>>> >> > headers
>>>> >> > recvd from app container
>>>> >> > *Oct 27 12:34:10.840:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQSIG:
>>>> >> > No
>>>> >> > QSIG Body found in inbound container
>>>> >> > *Oct 27 12:34:10.840:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPIGetContentQ931:
>>>> >> > No
>>>> >> > RawMsg Body found in inbound container
>>>> >> > *Oct 27 12:34:10.840:
>>>> //-1/xxxxxxxxxxxx/SIP/Info/sipSPICreateNewRawMsg:
>>>> >> > No
>>>> >> > Data to form The Raw Message
>>>> >> > *Oct 27 12:34:10.840:
>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>>>> >> > ccsip_api_call_cut_progress returned: SIP_SUCCESS
>>>> >> > *Oct 27 12:34:10.840:
>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>>>> >> > SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING,
>>>> >> > SUBSTATE_NONE)
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Info/HandleSIP1xxSessionProgress:
>>>> Transaction
>>>> >> > Complete. Lock on Facilities released.
>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>>> confID =
>>>> >> > 6,
>>>> >> > srcCallID = 846, dstCallID = 845
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>>>> >> > Old src/dest ccCallids: -1/-1, new src/dest ccCallids: 846/845
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPIUupdateCcCallIds:
>>>> >> > Old streamcallid=846, new streamcallid=846
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_gw_set_sipspi_mode:
>>>> >> > Setting SPI mode to SIP-H323
>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>>> >> > xcoder_attached = 0, xmitFunc = 1131891908, ccb xmitFunc =
>>>> 1131891908
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIProcessRtpSessions:
>>>> >> > sipSPIProcessRtpSessions
>>>> >> > *Oct 27 12:34:10.844: //846/8094E28C1800/SIP/Media/sipSPIAddStream:
>>>> >> > Adding
>>>> >> > stream 1 of type voice+dtmf (callid 846) to the VOIP RTP library
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Info/resolve_media_ip_address_to_bind: Media
>>>> >> > already
>>>> >> > bound, use existing source_media_ip_addr
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPISetMediaSrcAddr:
>>>> >> > Media src addr for stream 1 = 173.14.220.57
>>>> >> > *Oct 27 12:34:10.844:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>>> >> > sipSPIUpdateRtcpSession for m-line 1
>>>> >> > *Oct 27 12:34:10.848:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>>> >> > rtcp_session info
>>>> >> > laddr = 173.14.220.57, lport = 16462, raddr =
>>>> 64.154.41.101,
>>>> >> > rport=45846, do_rtcp=TRUE
>>>> >> > src_callid = 846, dest_callid = 845, stream type =
>>>> voice+dtmf,
>>>> >> > stream direction = SENDRECV
>>>> >> > media_ip_addr = 64.154.41.101, vrf tableid = 0
>>>> media_addr_type =
>>>> >> > 1
>>>> >> > *Oct 27 12:34:10.848:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtcpSession:
>>>> >> > RTP session already created - update
>>>> >> > *Oct 27 12:34:10.848:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>>>> >> > stun is disabled for stream:4A1709F8
>>>> >> > *Oct 27 12:34:10.848:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIGetNewLocalMediaDirection:
>>>> >> > New Remote Media Direction = SENDRECV
>>>> >> > Present Local Media Direction = SENDRECV
>>>> >> > New Local Media Direction = SENDRECV
>>>> >> > retVal = 0
>>>> >> > *Oct 27 12:34:10.848:
>>>> >> > //846/8094E28C1800/SIP/State/sipSPIChangeStreamState:
>>>> >> > Stream (callid = 846) State changed from (STREAM_ADDING) to
>>>> >> > (STREAM_ACTIVE)
>>>> >> > *Oct 27 12:34:10.848: //846/8094E28C1800/SIP/Info/ccsip_bridge:
>>>> really
>>>> >> > can't
>>>> >> > find peer_stream for
>>>> >> > dtmf-relay
>>>> interworking
>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Entry
>>>> >> > *Oct 27 12:34:11.140:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>>>> CURRENT
>>>> >> > VALUES: stream_callid=846, current_seq_num=0x23ED
>>>> >> > *Oct 27 12:34:11.140:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>>>> >> > VALUES:
>>>> >> > stream_callid=846, current_seq_num=0x11D9
>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Load
>>>> >> > DSP
>>>> >> > with negotiated codec: g711ulaw, Bytes=160
>>>> >> > *Oct 27 12:34:11.140: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Set
>>>> >> > forking flag to 0x0
>>>> >> > *Oct 27 12:34:11.140:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>>>> payload =
>>>> >> > 100, tx payload = 100
>>>> >> > *Oct 27 12:34:11.140:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>>>> >> > config=0
>>>> >> > *Oct 27 12:34:11.140:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Disabling Modem Relay...
>>>> >> > *Oct 27 12:34:11.140:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate
>>>> SDP
>>>> >> > Xcap
>>>> >> > list
>>>> >> > *Oct 27 12:34:11.140:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Modem
>>>> >> > Relay & Passthru both disabled
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > nse
>>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>>>> relay=0,
>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > 1
>>>> >> > Active Streams
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > Adding stream type (voice+dtmf) from media
>>>> >> > line 1 codec g711ulaw
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>>>> >> > caps.stream_list.xmitFunc=
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > voip_rtp_xmit, caps.stream_list.context=
>>>> >> > *Oct 27 12:34:11.144:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > 0x497E0B60 (gccb)
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Load
>>>> >> > DSP
>>>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200405
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> No
>>>> >> > video
>>>> >> > caps detected in the caps posted by peer leg
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> >> > Setting
>>>> >> > CAPS_RECEIVED flag
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> >> > Calling
>>>> >> > cc_api_caps_ack()
>>>> >> > *Oct 27 12:34:11.144: //846/8094E28C1800/SIP/Info/ccsip_caps_ack:
>>>> Set
>>>> >> > forking flag to 0x0
>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Entry
>>>> >> > *Oct 27 12:34:11.168:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters:
>>>> CURRENT
>>>> >> > VALUES: stream_callid=846, current_seq_num=0x11D9
>>>> >> > *Oct 27 12:34:11.168:
>>>> >> > //846/8094E28C1800/SIP/Info/ccsip_get_rtcp_session_parameters: NEW
>>>> >> > VALUES:
>>>> >> > stream_callid=846, current_seq_num=0x11D9
>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Load
>>>> >> > DSP
>>>> >> > with negotiated codec: g711ulaw, Bytes=160
>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Set
>>>> >> > forking flag to 0x0
>>>> >> > *Oct 27 12:34:11.168:
>>>> >> > //846/8094E28C1800/SIP/Info/sipSPISetDTMFRelayMode:
>>>> >> > Set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_NTE_AND_OOB with rx
>>>> payload =
>>>> >> > 100, tx payload = 100
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Preferred (or the one that came from DSM) modem relay=0, from CLI
>>>> >> > config=0
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Disabling Modem Relay...
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Negotiation already Done. Set negotiated Modem caps and generate
>>>> SDP
>>>> >> > Xcap
>>>> >> > list
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > Modem
>>>> >> > Relay & Passthru both disabled
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Info/sip_set_modem_caps:
>>>> >> > nse
>>>> >> > payload = 0, ptru mode = 0, ptru-codec=0, redundancy=0, xid=0,
>>>> relay=0,
>>>> >> > sprt-retry=12, latecncy=200, compres-dir=3, dict=1024, strnlen=32
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > 1
>>>> >> > Active Streams
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > Adding stream type (voice+dtmf) from media
>>>> >> > line 1 codec g711ulaw
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > caps.stream_count=1,caps.stream[0].stream_type=0x3,
>>>> >> > caps.stream_list.xmitFunc=
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > voip_rtp_xmit, caps.stream_list.context=
>>>> >> > *Oct 27 12:34:11.168:
>>>> //846/8094E28C1800/SIP/Media/sipSPISetStreamInfo:
>>>> >> > 0x497E0B60 (gccb)
>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Load
>>>> >> > DSP
>>>> >> > with codec : g711ulaw, Bytes=160, payload = 0
>>>> >> > *Oct 27 12:34:11.168: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> >> > ccsip_caps_ind: ccb->pld.flags_ipip = 0x200425
>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> No
>>>> >> > video
>>>> >> > caps detected in the caps posted by peer leg
>>>> >> > *Oct 27 12:34:11.172: //846/8094E28C1800/SIP/Info/ccsip_caps_ind:
>>>> Second
>>>> >> > TCS
>>>> >> > received for transfers across trunk - set CAPS2_RECEIVED
>>>> >> > *Oct 27 12:34:15.876:
>>>> >> > //846/8094E28C1800/SIP/Media/sipSPIUpdateRtpSession:
>>>> >> > stun is disabled for stream:4A1709F8
>>>> >> > *Oct 27 12:34:15.876:
>>>> //846/8094E28C1800/SIP/Info/ccsip_call_statistics:
>>>> >> > Stats are not supported for IPIP call.
>>>> >> > *Oct 27 12:34:15.876: //-1/xxxxxxxxxxxx/SIP/Event/sipSPIEventInfo:
>>>> >> > Queued
>>>> >> > event from SIP SPI : SIPSPI_EV_CC_CALL_DISCONNECT
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> >> > ccsip_spi_get_msg_type returned: 3 for event 7
>>>> >> > *Oct 27 12:34:15.880: //846/8094E28C1800/SIP/Info/sipSPISendCancel:
>>>> >> > Associated container=0x4E310C1C to Cancel
>>>> >> > *Oct 27 12:34:15.880:
>>>> //846/8094E28C1800/SIP/Transport/sipSPISendCancel:
>>>> >> > Sending CANCEL to the transport layer
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>>>> >> > msg=0x4DF0D994,
>>>> >> > addr=64.154.41.200, port=5060, sentBy_port=0, is_req=1,
>>>> transport=1,
>>>> >> > switch=0, callBack=0x419703BC
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //846/8094E28C1800/SIP/Transport/sipSPITransportSendMessage:
>>>> Proceedable
>>>> >> > for
>>>> >> > sending msg immediately
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: switch
>>>> >> > transport
>>>> >> > is 0
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //846/8094E28C1800/SIP/Transport/sipTransportLogicSendMsg: Set to
>>>> send
>>>> >> > the
>>>> >> > msg=0x4DF0D994
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportPostSendMessage:
>>>> Posting
>>>> >> > send
>>>> >> > for msg=0x4DF0D994, addr=64.154.41.200, port=5060, connId=2 for UDP
>>>> >> > *Oct 27 12:34:15.880:
>>>> >> > //846/8094E28C1800/SIP/Info/sentCancelDisconnecting:
>>>> >> > Sent Cancel Request, starting CancelWaitResponseTimer
>>>> >> > *Oct 27 12:34:15.880:
>>>> //846/8094E28C1800/SIP/State/sipSPIChangeState:
>>>> >> > 0x4A357FCC : State change from (STATE_RECD_PROCEEDING,
>>>> SUBSTATE_NONE)
>>>> >> > to
>>>> >> > (STATE_DISCONNECTING, SUBSTATE_NONE)
>>>> >> > *Oct 27 12:34:15.888: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >> > Sent:
>>>> >> > CANCEL sip:18774675464 at 64.154.41.200:5060 SIP/2.0
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >
>>>> >> > Date: Tue, 27 Oct 2009 12:34:09 GMT
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > CSeq: 102 CANCEL
>>>> >> > Max-Forwards: 70
>>>> >> > Timestamp: 1256646855
>>>> >> > Reason: Q.850;cause=16
>>>> >> > Content-Length: 0
>>>> >> > *Oct 27 12:34:15.900:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> >> > *Oct 27 12:34:15.900:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> >> > *Oct 27 12:34:15.900:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> >> > context=0x00000000
>>>> >> > *Oct 27 12:34:15.900:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> >> > Checking Invite Dialog
>>>> >> > *Oct 27 12:34:15.900: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >> > Received:
>>>> >> > SIP/2.0 200 OK
>>>> >> > Via: SIP/2.0/UDP 173.14.220.57:5060;branch=z9hG4bK4A18DE
>>>> >> > From: <sip:6782282221 at sip.talkinip.net<sip%3A6782282221 at sip.talkinip.net>
>>>> >;tag=2EDA9C8-25D6
>>>> >> > To: <sip:18774675464 at 64.154.41.200<sip%3A18774675464 at 64.154.41.200>
>>>> >
>>>> >> > Call-ID: DB9895B8-C22B11DE-801EC992-790F56B7 at 173.14.220.57
>>>> >> > CSeq: 102 CANCEL
>>>> >> > Content-Length: 0
>>>> >> > *Oct 27 12:34:15.900:
>>>> //846/8094E28C1800/SIP/Info/sipSPICheckResponse:
>>>> >> > non-INVITE response with no RSEQ - do not disable IS_REL1XX
>>>> >> > *Oct 27 12:34:15.900:
>>>> //846/8094E28C1800/SIP/Info/sipSPIIcpifUpdate:
>>>> >> > CallState: 3 Playout: 0 DiscTime:4913670 ConnTime 0
>>>> >> > *Oct 27 12:34:15.912:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/HandleUdpIPv4SocketReads:
>>>> >> > Msg enqueued for SPI with IP addr: [64.154.41.200]:5060
>>>> >> > *Oct 27 12:34:15.912:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_process_sipspi_queue_event:
>>>> >> > ccsip_spi_get_msg_type returned: 2 for event 1
>>>> >> > *Oct 27 12:34:15.912:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Transport/sipTransportProcessNWNewConnMsg:
>>>> >> > context=0x00000000
>>>> >> > *Oct 27 12:34:15.912:
>>>> >> > //-1/xxxxxxxxxxxx/SIP/Info/ccsip_new_msg_preprocessor:
>>>> >> > Checking Invite Dialog
>>>> >> > *Oct 27 12:34:15.912: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>>> >> >
>>>> >> > On Mon, Oct 26, 2009 at 7:36 PM, Nick Matthews <
>>>> matthnick at gmail.com>
>>>> >> > wrote:
>>>> >> >>
>>>> >> >> You would want to check the SDP of 200 OK the provider sends for
>>>> your
>>>> >> >> outgoing call. It will list the payload type for the dtmf in the
>>>> >> >> format a=fmtp 101 1-16, or something similar. You want to find
>>>> out
>>>> >> >> what payload type they are advertising (or if they are at all).
>>>> It
>>>> >> >> would be worth checking the incoming INVITE from them to see what
>>>> >> >> they're using when they send the first SDP.
>>>> >> >>
>>>> >> >> On that note, I would also remove the asymmetric payload command -
>>>> to
>>>> >> >> my knowledge it doesn't do what you're expecting it to. You may
>>>> want
>>>> >> >> to try this command:
>>>> >> >> voice-class sip dtmf-relay force rtp-nte
>>>> >> >>
>>>> >> >>
>>>> >> >> -nick
>>>> >> >>
>>>> >> >> On Mon, Oct 26, 2009 at 5:16 PM, Dane Newman <
>>>> dane.newman at gmail.com>
>>>> >> >> wrote:
>>>> >> >> > Hello,
>>>> >> >> >
>>>> >> >> > I am having an issue with dtmf working outbound. Inbound dtmf
>>>> works
>>>> >> >> > fine.
>>>> >> >> > It took some playing around with it. At first it didnt work
>>>> till the
>>>> >> >> > payload was ajusted. I am now trying to get outbound dtmf
>>>> working
>>>> >> >> > properly.
>>>> >> >> >
>>>> >> >> > On my 2821 I debugged voip rtp session named-events and then
>>>> made a
>>>> >> >> > call
>>>> >> >> > to
>>>> >> >> > a 1800 number and hit digits. I didn't see any dtmf output on
>>>> the
>>>> >> >> > router
>>>> >> >> > nothing showed up in the debug. Does this mean I can safely
>>>> asume
>>>> >> >> > that
>>>> >> >> > the
>>>> >> >> > problem for right now is not on the ITSP side but on my side
>>>> since
>>>> >> >> > dtmf
>>>> >> >> > is
>>>> >> >> > not being sent down the sip trunk?
>>>> >> >> >
>>>> >> >> > I have my cuc 7.x configured to talk to my 2821 via h323. The
>>>> >> >> > configuration
>>>> >> >> > of the cisco 2821 is shown below. Does anyone have any ideas
>>>> what I
>>>> >> >> > can
>>>> >> >> > do
>>>> >> >> > so dtmf digits process properly outbound?
>>>> >> >> >
>>>> >> >> > The settings in my cuc 7.x to add the gateway h323 are
>>>> >> >> >
>>>> >> >> > h323 cucm gateway configuratration
>>>> >> >> > Signaling Port 1720
>>>> >> >> > media termination point required yes
>>>> >> >> > retry video call as auto yes
>>>> >> >> > wait for far end h.245 terminal capability set yes
>>>> >> >> > transmit utf-8 calling party name no
>>>> >> >> > h.235 pass through allowed no
>>>> >> >> > significant digits all
>>>> >> >> > redirect number IT deliver - inbound no
>>>> >> >> > enable inbound faststart yes
>>>> >> >> > display IE deliver no
>>>> >> >> > redirect nunmber IT deliver - outbound no
>>>> >> >> > enable outbound faststart yes
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > voice service voip
>>>> >> >> > allow-connections h323 to h323
>>>> >> >> > allow-connections h323 to sip
>>>> >> >> > allow-connections sip to h323
>>>> >> >> > allow-connections sip to sip
>>>> >> >> > fax protocol pass-through g711ulaw
>>>> >> >> > h323
>>>> >> >> > emptycapability
>>>> >> >> > h225 id-passthru
>>>> >> >> > h245 passthru tcsnonstd-passthru
>>>> >> >> > sip
>>>> >> >> >
>>>> >> >> >
>>>> >> >> > voice class h323 50
>>>> >> >> > h225 timeout tcp establish 3
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > voice translation-rule 1
>>>> >> >> > rule 1 /.*/ /190/
>>>> >> >> > !
>>>> >> >> > voice translation-rule 2
>>>> >> >> > rule 1 /.*/ /1&/
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > voice translation-profile aa
>>>> >> >> > translate called 1
>>>> >> >> > !
>>>> >> >> > voice translation-profile addone
>>>> >> >> > translate called 2
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > voice-card 0
>>>> >> >> > dspfarm
>>>> >> >> > dsp services dspfarm
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > sccp local GigabitEthernet0/1
>>>> >> >> > sccp ccm 10.1.80.11 identifier 2 version 7.0
>>>> >> >> > sccp ccm 10.1.80.10 identifier 1 version 7.0
>>>> >> >> > sccp
>>>> >> >> > !
>>>> >> >> > sccp ccm group 1
>>>> >> >> > associate ccm 1 priority 1
>>>> >> >> > associate ccm 2 priority 2
>>>> >> >> > associate profile 1 register 2821transcode
>>>> >> >> > !
>>>> >> >> > dspfarm profile 1 transcode
>>>> >> >> > codec g711ulaw
>>>> >> >> > codec g711alaw
>>>> >> >> > codec g729ar8
>>>> >> >> > codec g729abr8
>>>> >> >> > codec g729r8
>>>> >> >> > maximum sessions 4
>>>> >> >> > associate application SCCP
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > dial-peer voice 100 voip
>>>> >> >> > description AA Publisher
>>>> >> >> > preference 1
>>>> >> >> > destination-pattern 1..
>>>> >> >> > voice-class h323 50
>>>> >> >> > session target ipv4:10.1.80.10
>>>> >> >> > dtmf-relay h245-alphanumeric
>>>> >> >> > codec g711ulaw
>>>> >> >> > no vad
>>>> >> >> > !
>>>> >> >> > dial-peer voice 1000 voip
>>>> >> >> > description incoming Call
>>>> >> >> > translation-profile incoming aa
>>>> >> >> > preference 1
>>>> >> >> > rtp payload-type nse 101
>>>> >> >> > rtp payload-type nte 100
>>>> >> >> > incoming called-number 6782282221
>>>> >> >> > dtmf-relay rtp-nte
>>>> >> >> > codec g711ulaw
>>>> >> >> > ip qos dscp cs5 media
>>>> >> >> > ip qos dscp cs5 signaling
>>>> >> >> > no vad
>>>> >> >> > !
>>>> >> >> > dial-peer voice 101 voip
>>>> >> >> > description AA Subscriber
>>>> >> >> > preference 2
>>>> >> >> > destination-pattern 1..
>>>> >> >> > voice-class h323 50
>>>> >> >> > session target ipv4:10.1.80.11
>>>> >> >> > dtmf-relay h245-alphanumeric
>>>> >> >> > codec g711ulaw
>>>> >> >> > no vad
>>>> >> >> > !
>>>> >> >> > dial-peer voice 2000 voip
>>>> >> >> > description outbound
>>>> >> >> > translation-profile outgoing addone
>>>> >> >> > preference 1
>>>> >> >> > destination-pattern .T
>>>> >> >> > rtp payload-type nse 101
>>>> >> >> > rtp payload-type nte 100
>>>> >> >> > voice-class sip asymmetric payload dtmf
>>>> >> >> > session protocol sipv2
>>>> >> >> > session target ipv4:64.154.41.200
>>>> >> >> > dtmf-relay rtp-nte
>>>> >> >> > codec g711ulaw
>>>> >> >> > no vad
>>>> >> >> > !
>>>> >> >> > !
>>>> >> >> > sip-ua
>>>> >> >> > credentials username ***** password 7 ***** realm
>>>> sip.talkinip.net
>>>> >> >> > authentication username ***** password 7 *****
>>>> >> >> > authentication username ***** password 7 ***** realm
>>>> >> >> > sip.talkinip.net
>>>> >> >> > set pstn-cause 3 sip-status 486
>>>> >> >> > set pstn-cause 34 sip-status 486
>>>> >> >> > set pstn-cause 47 sip-status 486
>>>> >> >> > registrar dns:sip.talkinip.net expires 60
>>>> >> >> > sip-server dns:sip.talkinip.net:5060
>>>> >> >> > _______________________________________________
>>>> >> >> > cisco-voip mailing list
>>>> >> >> > cisco-voip at puck.nether.net
>>>> >> >> > https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> >> >> >
>>>> >> >> >
>>>> >> >
>>>> >> >
>>>> >
>>>> > _______________________________________________
>>>> > cisco-voip mailing list
>>>> > cisco-voip at puck.nether.net
>>>> > https://puck.nether.net/mailman/listinfo/cisco-voip
>>>> >
>>>> >
>>>>
>>>
>>>
>>> _______________________________________________
>>> cisco-voip mailing list
>>> cisco-voip at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/2b6ae4ba/attachment-0001.html>
------------------------------
Message: 26
Date: Tue, 27 Oct 2009 14:24:53 -0700
From: Scott Voll <svoll.voip at gmail.com>
To: "Joe Pollere (US)" <Joe.Pollere at us.didata.com>
Cc: cisco-voip at puck.nether.net
Subject: [cisco-voip] answer: Re: What am I missing with Background
images?
Message-ID:
<f84a38d30910271424k22e8c102ne7890347569c2951 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
it's all depended on phone model.
7941 goes into the x4 directory and the 7965 goes into the x12 directory.
just my lack of understanding. Thanks for the help.
Scott
On Tue, Oct 27, 2009 at 12:38 PM, Joe Pollere (US) <
Joe.Pollere at us.didata.com> wrote:
> It is case sensitive. list.xml should be List.xml
>
>
>
> *From:* cisco-voip-bounces at puck.nether.net [mailto:
> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Scott Voll
> *Sent:* Tuesday, October 27, 2009 3:35 PM
> *To:* cisco-voip at puck.nether.net
> *Subject:* [cisco-voip] What am I missing with Background images?
>
>
>
> I have uploaded both the thumb nail and full png file for the image I want
> to use for a background. (both to the Desktops/320x196x4/ directory)
>
>
>
> I have also added the list.xml file to both the root and the
> Desktops/320x196x4/ and restarted both phone and TFTP server without being
> able to get it to work. What am I missing?
>
>
>
> Scott
>
> ------------------------------
>
> * 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. *
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/fc94ba0f/attachment-0001.html>
------------------------------
Message: 27
Date: Tue, 27 Oct 2009 17:46:45 -0500
From: "Philip Walenta" <pwalenta at wi.rr.com>
To: <cisco-voip at puck.nether.net>
Subject: [cisco-voip] SIP phones and caller ID
Message-ID: <01e001ca5757$5cf371f0$16da55d0$@rr.com>
Content-Type: text/plain; charset="us-ascii"
Has anyone who is using SIP phones ever seen it where instead of the caller
id you get an IP address sent instead?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c8a94cd2/attachment-0001.html>
------------------------------
Message: 28
Date: Tue, 27 Oct 2009 19:23:06 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Nick Matthews <matthnick at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271623m5dd6c4d8md557649bffb5dc at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Thanks for the reply Nick
I debugged voip rtp named-event and when I tried to hit 1 in the call for
dtmf nothing came out of the debug. Could this possibly mean on my side Im
not sending dtmf to the service provider?
Dane
On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com> wrote:
> That shows up in the debugs in working scenarios too. Not sure what
> the importance of those statements are, but it's the type of thing you
> see when you add 'all' to a debug.
>
> It's not the 183 you want to look at, but the 200 OK with the CSeq of
> your INVITE. And you want a 200 OK. I've seen it where the debugs
> will show that we're sending DTMF but the provider won't use it, which
> is a conversation you would need to have with the provider.
>
> -nick
>
> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
> wrote:
> > Hmm that does not sound good
> >
> > This is with the default settings
> >
> > rtp payload-type nte 101
> > rtp payload-type nse 100
> >
> > which don't show up in the config. Could there be any reason why the
> router
> > is not able to use 101 below are my dial peers
> >
> > dial-peer voice 100 voip
> > description AA Publisher
> > preference 1
> > destination-pattern 1..
> > voice-class h323 50
> > session target ipv4:10.1.80.10
> > dtmf-relay h245-alphanumeric
> > codec g711ulaw
> > no vad
> > !
> > dial-peer voice 1000 voip
> > description incoming Call
> > translation-profile incoming aa
> > preference 1
> >
> > incoming called-number 6784442454
> >
> > dtmf-relay rtp-nte
> > codec g711ulaw
> > ip qos dscp cs5 media
> > ip qos dscp cs5 signaling
> > no vad
> > !
> > dial-peer voice 101 voip
> > description AA Subscriber
> > preference 2
> > destination-pattern 1..
> > voice-class h323 50
> > session target ipv4:10.1.80.11
> > dtmf-relay h245-alphanumeric
> > codec g711ulaw
> > no vad
> > !
> > dial-peer voice 2000 voip
> > description outbound
> > translation-profile outgoing addone
> > preference 1
> > destination-pattern .T
> >
> > progress_ind setup enable 3
> > progress_ind progress enable 8
> > session protocol sipv2
> > session target dns:did.voip.les.net
> >
> > dtmf-relay rtp-nte
> > codec g711ulaw
> >
> > !
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/c1726f17/attachment-0001.html>
------------------------------
Message: 29
Date: Tue, 27 Oct 2009 20:14:58 -0400
From: Nick Matthews <matthnick at gmail.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<56c3b48b0910271714q68993636p4b157c41f3879d4b at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Yes, as long as your debugs are setup correctly (they show output).
-nick
On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman at gmail.com> wrote:
> Thanks for the reply Nick
>
> I debugged voip rtp named-event and when I tried to hit 1 in the call for
> dtmf nothing came out of the debug.? Could this possibly mean on my side Im
> not sending dtmf to the service provider?
> Dane
>
> On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com> wrote:
>>
>> That shows up in the debugs in working scenarios too. ?Not sure what
>> the importance of those statements are, but it's the type of thing you
>> see when you add 'all' to a debug.
>>
>> It's not the 183 you want to look at, but the 200 OK with the CSeq of
>> your INVITE. ?And you want a 200 OK. ?I've seen it where the debugs
>> will show that we're sending DTMF but the provider won't use it, which
>> is a conversation you would need to have with the provider.
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Hmm that does not sound good
>> >
>> > This is with the default settings
>> >
>> > rtp payload-type nte 101
>> > rtp payload-type nse 100
>> >
>> > which don't show up in the config.? Could there be any reason why the
>> > router
>> > is not able to use 101 below are my dial peers
>> >
>> > dial-peer voice 100 voip
>> > ?description AA Publisher
>> > ?preference 1
>> > ?destination-pattern 1..
>> > ?voice-class h323 50
>> > ?session target ipv4:10.1.80.10
>> > ?dtmf-relay h245-alphanumeric
>> > ?codec g711ulaw
>> > ?no vad
>> > !
>> > dial-peer voice 1000 voip
>> > ?description incoming Call
>> > ?translation-profile incoming aa
>> > ?preference 1
>> >
>> > ?incoming called-number 6784442454
>> >
>> > ?dtmf-relay rtp-nte
>> > ?codec g711ulaw
>> > ?ip qos dscp cs5 media
>> > ?ip qos dscp cs5 signaling
>> > ?no vad
>> > !
>> > dial-peer voice 101 voip
>> > ?description AA Subscriber
>> > ?preference 2
>> > ?destination-pattern 1..
>> > ?voice-class h323 50
>> > ?session target ipv4:10.1.80.11
>> > ?dtmf-relay h245-alphanumeric
>> > ?codec g711ulaw
>> > ?no vad
>> > !
>> > dial-peer voice 2000 voip
>> > ?description outbound
>> > ?translation-profile outgoing addone
>> > ?preference 1
>> > ?destination-pattern .T
>> >
>> > ?progress_ind setup enable 3
>> > ?progress_ind progress enable 8
>> > ?session protocol sipv2
>> > ?session target dns:did.voip.les.net
>> >
>> > ?dtmf-relay rtp-nte
>> > ?codec g711ulaw
>> >
>> > !
>
>
------------------------------
Message: 30
Date: Tue, 27 Oct 2009 20:17:41 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Nick Matthews <matthnick at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271717p382ed08bs2a7f1f72e5237173 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco
2821 --> ITSP sip trunk
I am using the CUBE feature on the gateway...DTMF works calling internally
to my cisco unity connection voice mail so it is able to be sent.
Does anyone have any ideas how I could go about troubleshooting this?
Dane
On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <matthnick at gmail.com> wrote:
> Yes, as long as your debugs are setup correctly (they show output).
>
> -nick
>
> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman at gmail.com>
> wrote:
> > Thanks for the reply Nick
> >
> > I debugged voip rtp named-event and when I tried to hit 1 in the call for
> > dtmf nothing came out of the debug. Could this possibly mean on my side
> Im
> > not sending dtmf to the service provider?
> > Dane
> >
> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com>
> wrote:
> >>
> >> That shows up in the debugs in working scenarios too. Not sure what
> >> the importance of those statements are, but it's the type of thing you
> >> see when you add 'all' to a debug.
> >>
> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of
> >> your INVITE. And you want a 200 OK. I've seen it where the debugs
> >> will show that we're sending DTMF but the provider won't use it, which
> >> is a conversation you would need to have with the provider.
> >>
> >> -nick
> >>
> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
> >> wrote:
> >> > Hmm that does not sound good
> >> >
> >> > This is with the default settings
> >> >
> >> > rtp payload-type nte 101
> >> > rtp payload-type nse 100
> >> >
> >> > which don't show up in the config. Could there be any reason why the
> >> > router
> >> > is not able to use 101 below are my dial peers
> >> >
> >> > dial-peer voice 100 voip
> >> > description AA Publisher
> >> > preference 1
> >> > destination-pattern 1..
> >> > voice-class h323 50
> >> > session target ipv4:10.1.80.10
> >> > dtmf-relay h245-alphanumeric
> >> > codec g711ulaw
> >> > no vad
> >> > !
> >> > dial-peer voice 1000 voip
> >> > description incoming Call
> >> > translation-profile incoming aa
> >> > preference 1
> >> >
> >> > incoming called-number 6784442454
> >> >
> >> > dtmf-relay rtp-nte
> >> > codec g711ulaw
> >> > ip qos dscp cs5 media
> >> > ip qos dscp cs5 signaling
> >> > no vad
> >> > !
> >> > dial-peer voice 101 voip
> >> > description AA Subscriber
> >> > preference 2
> >> > destination-pattern 1..
> >> > voice-class h323 50
> >> > session target ipv4:10.1.80.11
> >> > dtmf-relay h245-alphanumeric
> >> > codec g711ulaw
> >> > no vad
> >> > !
> >> > dial-peer voice 2000 voip
> >> > description outbound
> >> > translation-profile outgoing addone
> >> > preference 1
> >> > destination-pattern .T
> >> >
> >> > progress_ind setup enable 3
> >> > progress_ind progress enable 8
> >> > session protocol sipv2
> >> > session target dns:did.voip.les.net
> >> >
> >> > dtmf-relay rtp-nte
> >> > codec g711ulaw
> >> >
> >> > !
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/006c32d3/attachment-0001.html>
------------------------------
Message: 31
Date: Tue, 27 Oct 2009 20:49:12 -0400
From: Nick Matthews <matthnick at gmail.com>
To: Dane Newman <dane.newman at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<56c3b48b0910271749i1e8ea360gf7202f1f084ba785 at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
So you have a H323-SIP CUBE, and your DTMF isn't working. This is
probably the most common problem with CUBE users.
For this #1 problem, the number one cause is 'incoming called-number .'
Most people don't really understand inbound dial peer matching, and
have used this for ages on normal TDM gateways that were
single-protocol. The best way to fix this is to read the 'Understand
Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring
out the best way to match dial peers for both your incoming/outgoing
SIP/H323 legs. You can prefix digits and match on incoming called
number, or ditch incoming called-numbers completely and use
answer-address.
I like using 'debug voip ccapi inout' to determine this. You can do a
search for peer= after you've got the debug to find out which dial
peers you're hitting for each case, plus what the numbers look like
after translations, etc. 'debug voip dialpeer' is an alternative, but
I personally find it more confusing.
For h323-SIP your dial peers should look something like this:
incoming h323 dial peer for outgoing call: dtmf-relay h245-alpha or h245-signal
outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte
digit-drop (plus any payload commands required)
incoming sip dial peer for incoming call: same as sip option above
outgoing h323 dial peer for incoming call: same as h323 option above
My best guess is that if you look at your incoming/outgoing dial peers
something isn't matched correctly.
-nick
On Tue, Oct 27, 2009 at 8:17 PM, Dane Newman <dane.newman at gmail.com> wrote:
> I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco
> 2821 --> ITSP sip trunk
>
> I am using the CUBE feature on the gateway...DTMF works calling internally
> to my cisco unity connection voice mail so it is able to be sent.
>
> Does anyone have any ideas how I could go about troubleshooting this?
>
> Dane
>
> On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <matthnick at gmail.com> wrote:
>>
>> Yes, as long as your debugs are setup correctly (they show output).
>>
>> -nick
>>
>> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman at gmail.com>
>> wrote:
>> > Thanks for the reply Nick
>> >
>> > I debugged voip rtp named-event and when I tried to hit 1 in the call
>> > for
>> > dtmf nothing came out of the debug.? Could this possibly mean on my side
>> > Im
>> > not sending dtmf to the service provider?
>> > Dane
>> >
>> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com>
>> > wrote:
>> >>
>> >> That shows up in the debugs in working scenarios too. ?Not sure what
>> >> the importance of those statements are, but it's the type of thing you
>> >> see when you add 'all' to a debug.
>> >>
>> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of
>> >> your INVITE. ?And you want a 200 OK. ?I've seen it where the debugs
>> >> will show that we're sending DTMF but the provider won't use it, which
>> >> is a conversation you would need to have with the provider.
>> >>
>> >> -nick
>> >>
>> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
>> >> wrote:
>> >> > Hmm that does not sound good
>> >> >
>> >> > This is with the default settings
>> >> >
>> >> > rtp payload-type nte 101
>> >> > rtp payload-type nse 100
>> >> >
>> >> > which don't show up in the config.? Could there be any reason why the
>> >> > router
>> >> > is not able to use 101 below are my dial peers
>> >> >
>> >> > dial-peer voice 100 voip
>> >> > ?description AA Publisher
>> >> > ?preference 1
>> >> > ?destination-pattern 1..
>> >> > ?voice-class h323 50
>> >> > ?session target ipv4:10.1.80.10
>> >> > ?dtmf-relay h245-alphanumeric
>> >> > ?codec g711ulaw
>> >> > ?no vad
>> >> > !
>> >> > dial-peer voice 1000 voip
>> >> > ?description incoming Call
>> >> > ?translation-profile incoming aa
>> >> > ?preference 1
>> >> >
>> >> > ?incoming called-number 6784442454
>> >> >
>> >> > ?dtmf-relay rtp-nte
>> >> > ?codec g711ulaw
>> >> > ?ip qos dscp cs5 media
>> >> > ?ip qos dscp cs5 signaling
>> >> > ?no vad
>> >> > !
>> >> > dial-peer voice 101 voip
>> >> > ?description AA Subscriber
>> >> > ?preference 2
>> >> > ?destination-pattern 1..
>> >> > ?voice-class h323 50
>> >> > ?session target ipv4:10.1.80.11
>> >> > ?dtmf-relay h245-alphanumeric
>> >> > ?codec g711ulaw
>> >> > ?no vad
>> >> > !
>> >> > dial-peer voice 2000 voip
>> >> > ?description outbound
>> >> > ?translation-profile outgoing addone
>> >> > ?preference 1
>> >> > ?destination-pattern .T
>> >> >
>> >> > ?progress_ind setup enable 3
>> >> > ?progress_ind progress enable 8
>> >> > ?session protocol sipv2
>> >> > ?session target dns:did.voip.les.net
>> >> >
>> >> > ?dtmf-relay rtp-nte
>> >> > ?codec g711ulaw
>> >> >
>> >> > !
>> >
>> >
>
>
------------------------------
Message: 32
Date: Tue, 27 Oct 2009 21:34:44 -0400
From: Dane Newman <dane.newman at gmail.com>
To: Nick Matthews <matthnick at gmail.com>
Cc: cisco-voip <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Message-ID:
<a54820e50910271834q5021c6a4raa7bd9eb003cf1b5 at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I feel embarasssed I been blaming a telco all day when it was my own
ignorance that made it not work
I was not matching the inbound dialpeer for my outbound calling.
I added the following dial peer and the problem was solved
dial-peer voice 150 voip
description incoming outbound
preference 1
voice-class h323 50
incoming called-number .T
dtmf-relay h245-alphanumeric
codec g711ulaw
no vad
!
Thanks alot Nick and Ryan for all your help on this!
Dane
On Tue, Oct 27, 2009 at 8:49 PM, Nick Matthews <matthnick at gmail.com> wrote:
> So you have a H323-SIP CUBE, and your DTMF isn't working. This is
> probably the most common problem with CUBE users.
>
> For this #1 problem, the number one cause is 'incoming called-number .'
>
> Most people don't really understand inbound dial peer matching, and
> have used this for ages on normal TDM gateways that were
> single-protocol. The best way to fix this is to read the 'Understand
> Incoming and Outgoing Dial-Peers" document on Cisco.com, and figuring
> out the best way to match dial peers for both your incoming/outgoing
> SIP/H323 legs. You can prefix digits and match on incoming called
> number, or ditch incoming called-numbers completely and use
> answer-address.
>
> I like using 'debug voip ccapi inout' to determine this. You can do a
> search for peer= after you've got the debug to find out which dial
> peers you're hitting for each case, plus what the numbers look like
> after translations, etc. 'debug voip dialpeer' is an alternative, but
> I personally find it more confusing.
>
> For h323-SIP your dial peers should look something like this:
>
> incoming h323 dial peer for outgoing call: dtmf-relay h245-alpha or
> h245-signal
> outgoing sip dial peer for outgoing call: dtmf-relay rtp-nte
> digit-drop (plus any payload commands required)
> incoming sip dial peer for incoming call: same as sip option above
> outgoing h323 dial peer for incoming call: same as h323 option above
>
> My best guess is that if you look at your incoming/outgoing dial peers
> something isn't matched correctly.
>
> -nick
>
> On Tue, Oct 27, 2009 at 8:17 PM, Dane Newman <dane.newman at gmail.com>
> wrote:
> > I have a cisco 7975 phone connected to a cucm 7.x --> h323 gateway cisco
> > 2821 --> ITSP sip trunk
> >
> > I am using the CUBE feature on the gateway...DTMF works calling
> internally
> > to my cisco unity connection voice mail so it is able to be sent.
> >
> > Does anyone have any ideas how I could go about troubleshooting this?
> >
> > Dane
> >
> > On Tue, Oct 27, 2009 at 8:14 PM, Nick Matthews <matthnick at gmail.com>
> wrote:
> >>
> >> Yes, as long as your debugs are setup correctly (they show output).
> >>
> >> -nick
> >>
> >> On Tue, Oct 27, 2009 at 7:23 PM, Dane Newman <dane.newman at gmail.com>
> >> wrote:
> >> > Thanks for the reply Nick
> >> >
> >> > I debugged voip rtp named-event and when I tried to hit 1 in the call
> >> > for
> >> > dtmf nothing came out of the debug. Could this possibly mean on my
> side
> >> > Im
> >> > not sending dtmf to the service provider?
> >> > Dane
> >> >
> >> > On Tue, Oct 27, 2009 at 4:30 PM, Nick Matthews <matthnick at gmail.com>
> >> > wrote:
> >> >>
> >> >> That shows up in the debugs in working scenarios too. Not sure what
> >> >> the importance of those statements are, but it's the type of thing
> you
> >> >> see when you add 'all' to a debug.
> >> >>
> >> >> It's not the 183 you want to look at, but the 200 OK with the CSeq of
> >> >> your INVITE. And you want a 200 OK. I've seen it where the debugs
> >> >> will show that we're sending DTMF but the provider won't use it,
> which
> >> >> is a conversation you would need to have with the provider.
> >> >>
> >> >> -nick
> >> >>
> >> >> On Tue, Oct 27, 2009 at 3:45 PM, Dane Newman <dane.newman at gmail.com>
> >> >> wrote:
> >> >> > Hmm that does not sound good
> >> >> >
> >> >> > This is with the default settings
> >> >> >
> >> >> > rtp payload-type nte 101
> >> >> > rtp payload-type nse 100
> >> >> >
> >> >> > which don't show up in the config. Could there be any reason why
> the
> >> >> > router
> >> >> > is not able to use 101 below are my dial peers
> >> >> >
> >> >> > dial-peer voice 100 voip
> >> >> > description AA Publisher
> >> >> > preference 1
> >> >> > destination-pattern 1..
> >> >> > voice-class h323 50
> >> >> > session target ipv4:10.1.80.10
> >> >> > dtmf-relay h245-alphanumeric
> >> >> > codec g711ulaw
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 1000 voip
> >> >> > description incoming Call
> >> >> > translation-profile incoming aa
> >> >> > preference 1
> >> >> >
> >> >> > incoming called-number 6784442454
> >> >> >
> >> >> > dtmf-relay rtp-nte
> >> >> > codec g711ulaw
> >> >> > ip qos dscp cs5 media
> >> >> > ip qos dscp cs5 signaling
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 101 voip
> >> >> > description AA Subscriber
> >> >> > preference 2
> >> >> > destination-pattern 1..
> >> >> > voice-class h323 50
> >> >> > session target ipv4:10.1.80.11
> >> >> > dtmf-relay h245-alphanumeric
> >> >> > codec g711ulaw
> >> >> > no vad
> >> >> > !
> >> >> > dial-peer voice 2000 voip
> >> >> > description outbound
> >> >> > translation-profile outgoing addone
> >> >> > preference 1
> >> >> > destination-pattern .T
> >> >> >
> >> >> > progress_ind setup enable 3
> >> >> > progress_ind progress enable 8
> >> >> > session protocol sipv2
> >> >> > session target dns:did.voip.les.net
> >> >> >
> >> >> > dtmf-relay rtp-nte
> >> >> > codec g711ulaw
> >> >> >
> >> >> > !
> >> >
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091027/aee9cc8d/attachment-0001.html>
------------------------------
Message: 33
Date: Wed, 28 Oct 2009 21:04:24 +1100
From: "Dana Tong (AU)" <Dana.Tong at didata.com.au>
To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
Message-ID:
<B9B345954EE2444284E3DC802DF6333A5D24E9537C at AUNDDEXMBS01.au.didata.local>
Content-Type: text/plain; charset="windows-1252"
Hey guys,
I've upgraded CUCM to 7.1(3) and CUPS to 7.0(5) but the customer still cannot get deskphone control.
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.
He is able to login and become "available" but no deskphone control.
My PC is not part of the domain and I can get deskphone control but no presence.
Any thoughts guys?
Cheers
Dana
________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Dana Tong (AU) [Dana.Tong at didata.com.au]
Sent: Tuesday, 27 October 2009 8:05 AM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
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.
From: Adam Frankel [mailto:afrankel at cisco.com]
Sent: Monday, 26 October 2009 7:35 PM
To: Dana Tong (AU)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
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.
Adam
-----Original Message-----
From: Dana Tong (AU) <Dana.Tong at didata.com.au><mailto:Dana.Tong at didata.com.au>
Sent: Sun, Oct 25, 2009 10:48:16 Pm
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> <cisco-voip at puck.nether.net><mailto:cisco-voip at puck.nether.net>
CC:
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
[cid:image001.png at 01CA56DC.4577E680]
[cid:image002.jpg at 01CA56DC.4577E680]
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Dana Tong (AU)
Sent: Monday, 26 October 2009 11:10 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] CUPC troubleshooting tips?
Hi everyone,
I am having an issue with a CUPS / CUPC installation. This is still in the deployment phase.
CUCM = 7.0.2.20000-5
CUPS = 7.0.4
CUPC = 7.0.2.13496
CUCM is being upgraded to 7.1(3) on Wednesday night.
My issues are:
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.
Instant Messaging:
My client cannot instant message another user. The CUPC client reports ?Contact cannot receive Instant Messages?.
Any thoughts on these problems?
Thanks
Dana
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
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.
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.
******************************************************************************
________________________________
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16877 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 26208 bytes
Desc: image002.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/b052fb1f/attachment-0001.jpg>
------------------------------
Message: 34
Date: Wed, 28 Oct 2009 21:59:51 +1100
From: "Dana Tong (AU)" <Dana.Tong at didata.com.au>
To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
Message-ID:
<B9B345954EE2444284E3DC802DF6333A5D24E9537E at AUNDDEXMBS01.au.didata.local>
Content-Type: text/plain; charset="windows-1252"
My bad. It's all good.
VT advantage was screwing up deskphone control!
Cheers
________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Dana Tong (AU) [Dana.Tong at didata.com.au]
Sent: Wednesday, 28 October 2009 8:04 PM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
Hey guys,
I've upgraded CUCM to 7.1(3) and CUPS to 7.0(5) but the customer still cannot get deskphone control.
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.
He is able to login and become "available" but no deskphone control.
My PC is not part of the domain and I can get deskphone control but no presence.
Any thoughts guys?
Cheers
Dana
________________________________
From: cisco-voip-bounces at puck.nether.net [cisco-voip-bounces at puck.nether.net] On Behalf Of Dana Tong (AU) [Dana.Tong at didata.com.au]
Sent: Tuesday, 27 October 2009 8:05 AM
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
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.
From: Adam Frankel [mailto:afrankel at cisco.com]
Sent: Monday, 26 October 2009 7:35 PM
To: Dana Tong (AU)
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
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.
Adam
-----Original Message-----
From: Dana Tong (AU) <Dana.Tong at didata.com.au><mailto:Dana.Tong at didata.com.au>
Sent: Sun, Oct 25, 2009 10:48:16 Pm
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net> <cisco-voip at puck.nether.net><mailto:cisco-voip at puck.nether.net>
CC:
Subject: Re: [cisco-voip] CUPC troubleshooting tips?
[cid:image001.png at 01CA56DC.4577E680]
[cid:image002.jpg at 01CA56DC.4577E680]
From: cisco-voip-bounces at puck.nether.net<mailto:cisco-voip-bounces at puck.nether.net> [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Dana Tong (AU)
Sent: Monday, 26 October 2009 11:10 AM
To: cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
Subject: [cisco-voip] CUPC troubleshooting tips?
Hi everyone,
I am having an issue with a CUPS / CUPC installation. This is still in the deployment phase.
CUCM = 7.0.2.20000-5
CUPS = 7.0.4
CUPC = 7.0.2.13496
CUCM is being upgraded to 7.1(3) on Wednesday night.
My issues are:
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.
Instant Messaging:
My client cannot instant message another user. The CUPC client reports ?Contact cannot receive Instant Messages?.
Any thoughts on these problems?
Thanks
Dana
******************************************************************************
- NOTICE FROM DIMENSION DATA AUSTRALIA
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.
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.
******************************************************************************
________________________________
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 16877 bytes
Desc: image001.png
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 26208 bytes
Desc: image002.jpg
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/dc496a05/attachment-0001.jpg>
------------------------------
Message: 35
Date: Wed, 28 Oct 2009 13:44:33 +0200
From: Kelemen Zolt?n <keli at carocomp.ro>
To: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] 7960 to SIP server
Message-ID: <4AE82EA1.90602 at carocomp.ro>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Generally speaking, it should be, though as they are not a "supported
type", it probably won't be straight-forward and the phones might need
some external provisioning server (ie tftp)
I don't have any experience with talkswitch itself, but a SIP server
should be a registrar server if you need to add phones to it.
The talkswitch site has a pdf guide for installing phones here:
http://www.talkswitch.com/us/en/support/documentation/phones/#ipphones
(Adding IP Phones to TalkSwitch
<http://www.talkswitch.com/dms/?domain=www.talkswitch.com&get=845CBD73CDC4929EE877848D96FBEB2D>
) and you might find this one helpful as well (except of course the bits
related to configuring the Asterisk server):
http://wiki.siftah.com/Cisco_7960G_IP_Phone_on_Asterisk
According to the talkswitch guide, you might try "other IP phone" as
"phone type" on the talkswitch.
regards,
Zoltan
On 10/26/2009 8:36 PM, VoiceNoob wrote:
>
> So I am trying to see if something a customer is doing is even
> possible. They have several 7960 IP phones they want to load the SIP
> image on and deploy. They want to register to a Talkswitch 484 VS. I
> need to know where I should start in this process. I have some packet
> captures of the phone trying to register but I don't even know if this
> is possible or not. Should the Talkswitch device be a SIP registrar
> server?
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/2f66e1d5/attachment-0001.html>
------------------------------
Message: 36
Date: Wed, 28 Oct 2009 09:28:43 -0400
From: "c3voip" <c3voip at nc.rr.com>
To: <cisco-voip at puck.nether.net>
Subject: [cisco-voip] LDAP Sync vs AD Integration
Message-ID: <003001ca57d2$91bcf930$b536eb90$@rr.com>
Content-Type: text/plain; charset="us-ascii"
Now that I have upgraded to CUCM 7.1.2, I am having to find new ways to do
old tasks.
The first of which is user management.
Adding a user with CCM 4.1.3 with AD Integration:
We used to be able to create a Subscriber using Unity, which would create
the AD user. We could find the user in Global Directory and edit their
telephone number for the Corporate Directory.
Deleting a user with CCM 4.1.3 with AD Integration:
We used to be able to delete a Subscriber using Unity, then go into Global
Directory and delete the user which would delete the user in AD.
Now with CUCM 7.1.2 with LDAP Sync:
It looks like we need to grant some type of AD domain admin rights to people
that didn't have them before in order to give them access to the AD Users
and Computers plugin to perform these same tasks.
Am I missing something?
Thanks,
-C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/4ecd79d1/attachment-0001.html>
------------------------------
Message: 37
Date: Wed, 28 Oct 2009 07:40:10 -0700
From: Scott Voll <svoll.voip at gmail.com>
To: c3voip <c3voip at nc.rr.com>
Cc: cisco-voip at puck.nether.net
Subject: Re: [cisco-voip] LDAP Sync vs AD Integration
Message-ID:
<f84a38d30910280740t3dfd6cfp56f51a9bc1ae9229 at mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
your not missing anything.
The AD sync is only that. it only looks to your LDAP for authentication.
it will not add / delete users.
Couple questions:
is your Unity VM only and is that the LDAP your looking at?
Are you doing your add / delete stuff from CM or Unity.
if unity, I would not think anything would change.
if CM you are correct and they would need to have access via the LDAP.
hope that helps.
Scott
On Wed, Oct 28, 2009 at 6:28 AM, c3voip <c3voip at nc.rr.com> wrote:
> Now that I have upgraded to CUCM 7.1.2, I am having to find new ways to
> do old tasks.
>
>
>
> The first of which is user management.
>
>
>
> Adding a user with CCM 4.1.3 with AD Integration:
>
> We used to be able to create a Subscriber using Unity, which would create
> the AD user. We could find the user in Global Directory and edit their
> telephone number for the Corporate Directory.
>
>
>
> Deleting a user with CCM 4.1.3 with AD Integration:
>
> We used to be able to delete a Subscriber using Unity, then go into Global
> Directory and delete the user which would delete the user in AD.
>
>
>
> Now with CUCM 7.1.2 with LDAP Sync:
>
> It looks like we need to grant some type of AD domain admin rights to
> people that didn?t have them before in order to give them access to the AD
> Users and Computers plugin to perform these same tasks.
>
>
>
> Am I missing something?
>
>
>
> Thanks,
>
> -C
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/55b5b6d9/attachment-0001.html>
------------------------------
Message: 38
Date: Wed, 28 Oct 2009 11:55:40 -0400
From: Matthew Loraditch <MLoraditch at heliontechnologies.com>
To: "cisco-voip at puck.nether.net" <cisco-voip at puck.nether.net>
Subject: [cisco-voip] Mobility Calls: Transform Internal Extensions to
DIDs
Message-ID:
<530C67FE62559C42857C78B962454E6203B8B57A78 at hermes.helion.local>
Content-Type: text/plain; charset="us-ascii"
All,
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.
Any suggestions?
Thanks!!
Matthew Loraditch
1965 Greenspring Drive
Timonium, MD 21093
support at heliontechnologies.com<mailto:support at heliontechnologies.com>
(p) (410) 252-8830
(F) (443) 541-1593
Visit us at www.heliontechnologies.com<http://www.heliontechnologies.com>
Support Issue? Email support at heliontechnologies.com<mailto:support at heliontechnologies.com> for fast assistance!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091028/0a6453fa/attachment-0001.html>
------------------------------
_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-voip
End of cisco-voip Digest, Vol 72, Issue 28
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20091029/80ca6aab/attachment.html>
More information about the cisco-voip
mailing list