[cisco-voip] dtmf from cucm to 2821 cube to sip trunk

Ryan Ratliff rratliff at cisco.com
Tue Oct 27 15:37:03 EDT 2009


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.html>


More information about the cisco-voip mailing list