[cisco-voip] dtmf from cucm to 2821 cube to sip trunk
Ryan Ratliff
rratliff at cisco.com
Tue Oct 27 14:56:23 EDT 2009
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.html>
More information about the cisco-voip
mailing list