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

Dane Newman dane.newman at gmail.com
Tue Oct 27 15:42:34 EDT 2009


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


More information about the cisco-voip mailing list