[cisco-voip] SIP gateway config

Brian Schultz bms314 at gmail.com
Mon Apr 26 18:16:23 EDT 2010


That was it, thanks Justin.  Somehow digest authentication was checked on
the SIP security profile.

Now, I have a new problem.  So far this problem has been intermittent.  On
some calls, the SIP setup messages don't start until 7 seconds after the
call hits the gateway.  I see the ISDN debug and hear a message from the
provider that the call couldn't be completed as dialed.  Then ISDN releases
the call and I immediately see a SIP invite and my phone starts to ring and
completes as normal.  I've reproduced it several times already.  Very
strange.  Here is an example:


002234: Apr 26 17:13:54 Central: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd =
8  callref = 0x8001
        Channel ID i = 0xA98381
                Exclusive, Channel 1
002235: Apr 26 17:13:54 Central: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8
callref = 0x00A0
        Bearer Capability i = 0x8090A2
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98397
                Exclusive, Channel 23
        Calling Party Number i = 0x2183, '9528183360'
                Plan:ISDN, Type:National
        Called Party Number i = 0xC1, '7715'
                Plan:ISDN, Type:Subscriber(local)
002236: Apr 26 17:13:54 Central: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd =
8  callref = 0x80A0
        Channel ID i = 0xA98397
                Exclusive, Channel 23
UHD.EAST.RTR1#
002237: Apr 26 17:13:54 Central: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd =
8  callref = 0x80A0
        Cause i = 0x8283 - No route to destination
        Progress Ind i = 0x8288 - In-band info or appropriate now available
002238: Apr 26 17:13:54 Central: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd =
8  callref = 0x8001
        Progress Ind i = 0x8288 - In-band info or appropriate now available
UHD.EAST.RTR1#
002239: Apr 26 17:14:01 Central: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd =
8  callref = 0x80A0
        Cause i = 0x8290 - Normal call clearing
002240: Apr 26 17:14:01 Central: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8
callref = 0x00A0
002241: Apr 26 17:14:01 Central: ISDN Se0/0/0:23 Q931: RX <- RELEASE_COMP pd
= 8  callref = 0x80A0
002242: Apr 26 17:14:01 Central: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
INVITE sip:7715 at 172.21.20.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5ED1B0D
Remote-Party-ID: <sip:9528183360 at 172.21.20.254<sip%3A9528183360 at 172.21.20.254>
>;party=calling;screen=yes;privacy=off
From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>;tag=3388AB18-55
To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
Date: Mon, 26 Apr 2010 22:14:01 GMT
Call-ID: DA74D879-50B711DF-819BFADB-42390B at 172.21.20.254
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE:  1800
Cisco-Guid: 3595010882-1354174943-2151188547-3779644176
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: 1272320041
Contact: <sip:9528183360 at 172.21.20.254:5060>
Expires: 180
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 330
v=0
o=CiscoSystemsSIP-GW-UserAgent 5784 5366 IN IP4 172.21.20.254
s=SIP Call
c=IN IP4 172.21.20.254
t=0 0
m=audio 26090 RTP/AVP 0 18 9 101
c=IN IP4 172.21.20.254
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:9 G722/8000
a=fmtp:9 bitrate=64
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
002243: Apr 26 17:14:01 Central: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5ED1B0D
From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>;tag=3388AB18-55
To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
Date: Mon, 26 Apr 2010 22:14:20 GMT
Call-ID: DA74D879-50B711DF-819BFADB-42390B at 172.21.20.254
CSeq: 101 INVITE
Allow-Events: presence
Content-Length: 0

002244: Apr 26 17:14:01 Central: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5ED1B0D
From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>;tag=3388AB18-55
To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>
>;tag=fc6aef00-fcb6-4e1c-a8c0-e38242535154-20774950
Date: Mon, 26 Apr 2010 22:14:20 GMT
Call-ID: DA74D879-50B711DF-819BFADB-42390B at 172.21.20.254
CSeq: 101 INVITE
Allow: INVITE, OPTIONS, INFO, BYE, CANCEL, ACK, PRACK, UPDATE, REFER,
SUBSCRIBE, NOTIFY
Allow-Events: presence
Contact: <sip:7715 at 172.21.20.10:5060>
Supported: X-cisco-srtp-fallback
UHD.EAST.RTR1#Supported: Geolocation
P-Asserted-Identity: "Phenomenal Networks"
<sip:7715 at 172.21.20.10<sip%3A7715 at 172.21.20.10>
>
Remote-Party-ID: "Phenomenal Networks"
<sip:7715 at 172.21.20.10<sip%3A7715 at 172.21.20.10>
>;party=called;screen=yes;privacy=off
Content-Length: 0

UHD.EAST.RTR1#
002245: Apr 26 17:14:06 Central: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT pd =
8  callref = 0x0001
        Cause i = 0x8290 - Normal call clearing
002246: Apr 26 17:14:06 Central: ISDN Se0/0/0:23 Q931: TX -> RELEASE pd = 8
callref = 0x8001
002247: Apr 26 17:14:06 Central: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
CANCEL sip:7715 at 172.21.20.10:5060 SIP/2.0
Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5ED1B0D
From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>;tag=3388AB18-55
To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
Date: Mon, 26 Apr 2010 22:14:01 GMT
Call-ID: DA74D879-50B711DF-819BFADB-42390B at 172.21.20.254
CSeq: 101 CANCEL
Max-Forwards: 70
Timestamp: 1272320046
Reason: Q.850;cause=16
Content-Length: 0

002248: Apr 26 17:14:06 Central: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5ED1B0D
From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>;tag=3388AB18-55
To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
Date: Mon, 26 Apr 2010 22:14:25 GMT
Call-ID: DA74D879-50B711DF-819BFADB-42390B at 172.21.20.254
CSeq: 101 CANCEL
Content-Length: 0


On Mon, Apr 26, 2010 at 5:01 PM, Justin Steinberg <jsteinberg at gmail.com>wrote:

> brian,
>
> The CM trunk is challenging the IOS for digest authentication.   take a
> look at the SIP security profile you've assigned to the CM SIP trunk and
> configure it for a profile that doesn't require digest authentication.
>
>  On Mon, Apr 26, 2010 at 5:56 PM, Peter Slow <peter.slow at gmail.com> wrote:
>
>> Brian,
>>
>>
>> 002008: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8
>> callref = 0x0097
>> <snip>
>>
>>         Called Party Number i = 0xC1, '7715'
>>                 Plan:ISDN, Type:Subscriber(local)
>>
>>
>> -Pete
>>
>>
>> On Mon, Apr 26, 2010 at 5:35 PM, Brian Schultz <bms314 at gmail.com> wrote:
>>
>>> I only have MTP configured on the CUCM server as part of the Device
>>> Pool.  Do I need separate MTP configured on the router?
>>>
>>> Here is my debug.  7715 is the DID which I have configured on my soft
>>> phone.  I used RDM to create base config with SIP trunks to gateways.  Trunk
>>> is in the same CSS and Device Pool as the phone.
>>>
>>>
>>> 002000: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: RX <- SETUP pd =
>>> 8  callref = 0x0001
>>>         Bearer Capability i = 0x8090A2
>>>                 Standard = CCITT
>>>                 Transfer Capability = Speech
>>>                 Transfer Mode = Circuit
>>>                 Transfer Rate = 64 kbit/s
>>>         Channel ID i = 0xA98381
>>>                 Exclusive, Channel 1
>>>         Calling Party Number i = 0x2183, '9528183360'
>>>                 Plan:ISDN, Type:National
>>>         Called Party Number i = 0xC1, '7715'
>>>                 Plan:ISDN, Type:Subscriber(local)
>>> 002001: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: Received SETUP
>>> callref = 0x8001 callID = 0x0042 switch = primary-5ess interface = User
>>> 002002: Apr 26 16:31:12 Central:
>>> //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> Sent:
>>> INVITE sip:7715 at 172.21.20.10:5060 SIP/2.0
>>> Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5DDED4
>>> Remote-Party-ID: <sip:9528183360 at 172.21.20.254<sip%3A9528183360 at 172.21.20.254>
>>> >;party=calling;screen=yes;privacy=off
>>> From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>>> >;tag=33617790-169F
>>> To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
>>> Date: Mon, 26 Apr 2010 21:31:12 GMT
>>> Call-ID: DF28E48D-50B111DF-814BFADB-42390B at 172.21.20.254
>>> Supported: 100rel,timer,resource-priority,replaces,sdp-anat
>>> Min-SE:  1800
>>> Cisco-Guid: 3743959142-1353781727-2150402115-3779644176
>>> 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: 1272317472
>>> Contact: <sip:9528183360 at 172.21.20.254:5060>
>>> Expires: 180
>>> Allow-Events: telephone-event
>>> Content-Type: application/sdp
>>> Content-Disposition: session;handling=required
>>> Content-Length: 285
>>> v=0
>>> o=CiscoSystemsSIP-GW-UserAgent 9351 4649 IN IP4 172.21.20.254
>>> s=SIP Call
>>> c=IN IP4 172.21.20.254
>>> t=0 0
>>> m=audio 25022 RTP/AVP 0 18 101
>>> c=IN IP4 172.21.20.254
>>> a=rtpmap:0 PCMU/8000
>>> a=rtpmap:18 G729/8000
>>> a=fmtp:18 annexb=no
>>> a=rtpmap:101 telephone-event/8000
>>> a=fmtp:101 0-16
>>> 002003: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: TX -> CALL_PROC pd
>>> = 8  callref = 0x8001
>>>         Channel ID i = 0xA98381
>>>                 Exclusive, Channel 1
>>> 002004: Apr 26 16:31:12 Central:
>>> //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> Received:
>>> SIP/2.0 100 Trying
>>> Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5DDED4
>>> From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>>> >;tag=33617790-169F
>>> To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>
>>> Date: Mon, 26 Apr 2010 21:31:31 GMT
>>> Call-ID: DF28E48D-50B111DF-814BFADB-42390B at 172.21.20.254
>>> CSeq: 101 INVITE
>>> Allow-Events: presence
>>> Content-Length: 0
>>>
>>> 002005: Apr 26 16:31:12 Central:
>>> //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> Received:
>>> SIP/2.0 401 Unauthorized
>>> Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5DDED4
>>> From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>>> >;tag=33617790-169F
>>> To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>;tag=205608936
>>> Date: Mon, 26 Apr 2010 21:31:31 GMT
>>> Call-ID: DF28E48D-50B111DF-814BFADB-42390B at 172.21.20.254
>>> CSeq: 101 INVITE
>>> Allow-Events: presence
>>> WWW-Authenticate: Digest realm="StandAloneCluster",
>>> nonce="oQbua7BD9UUXn7PtEyhEPuxTU4a5UWsT", algorithm=MD5
>>> Content-Length: 0
>>>
>>> 002006: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: Applying typeplan
>>> for sw-type 0x3 is 0x2 0x1, Calling num 9528183360
>>> 002007: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: Sending SETUP
>>> callref = 0x0097 callID = 0x8018 switch = primary-5ess interface = User
>>> 002008: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: TX -> SETUP pd =
>>> 8  callref = 0x0097
>>>         Bearer Capability i = 0x8090A2
>>>                 Standard = CCITT
>>>                 Transfer Capability = Speech
>>>                 Transfer Mode = Circuit
>>>                 Transfer Rate = 64 kbit/s
>>>         Channel ID i = 0xA98397
>>>                 Exclusive, Channel 23
>>>         Calling Party Number i = 0x2183, '9528183360'
>>>                 Plan:ISDN, Type:National
>>>         Called Party Number i = 0xC1, '7715'
>>>                 Plan:ISDN, Type:Subscriber(local)
>>> 002009: Apr 26 16:31:12 Central:
>>> //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>>> Sent:
>>> ACK sip:7715 at 172.21.20.10:5060 SIP/2.0
>>> Via: SIP/2.0/UDP 172.21.20.254:5060;branch=z9hG4bK5DDED4
>>> From: <sip:9528183360 at 172.21.20.254 <sip%3A9528183360 at 172.21.20.254>
>>> >;tag=33617790-169F
>>> To: <sip:7715 at 172.21.20.10 <sip%3A7715 at 172.21.20.10>>;tag=205608936
>>> Date: Mon, 26 Apr 2010 21:31:12 GMT
>>> Call-ID: DF28E48D-50B111DF-814BFADB-42390B at 172.21.20.254
>>> Max-Forwards: 70
>>> CSeq: 101 ACK
>>> Allow-Events: telephone-event
>>> Content-Length: 0
>>>
>>> 002010: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd
>>> = 8  callref = 0x8097
>>>         Channel ID i = 0xA98397
>>>                 Exclusive, Channel 23
>>> UHD.EAST.RTR1#
>>> 002011: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd
>>> = 8  callref = 0x8097
>>>         Cause i = 0x8283 - No route to destination
>>>         Progress Ind i = 0x8288 - In-band info or appropriate now
>>> available
>>> 002012: Apr 26 16:31:12 Central: ISDN Se0/0/0:23 Q931: TX -> ALERTING pd
>>> = 8  callref = 0x8001
>>>         Progress Ind i = 0x8288 - In-band info or appropriate now
>>> available
>>> UHD.EAST.RTR1#
>>> 002013: Apr 26 16:31:18 Central: ISDN Se0/0/0:23 Q931: RX <- DISCONNECT
>>> pd = 8  callref = 0x0001
>>>         Cause i = 0x8290 - Normal call clearing
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Apr 26, 2010 at 4:06 PM, miken miken <miken at sisna.com> wrote:
>>>
>>>> MTP configured and box checked mandatory in SIP trunk configuration on
>>>> CUCM?
>>>>
>>>> Thanks
>>>> MikeN
>>>>
>>>>   On Mon, Apr 26, 2010 at 3:00 PM, Brian Schultz <bms314 at gmail.com>wrote:
>>>>
>>>>>   Yep, have that already.  Gig0/1.110 has the IP address configured on
>>>>> the SIP trunk in CUCM.
>>>>>
>>>>> voice service voip
>>>>>  sip
>>>>>   bind control source-interface GigabitEthernet0/1.110
>>>>>   bind media source-interface GigabitEthernet0/1.110
>>>>>
>>>>> I also have the following:
>>>>>
>>>>> voice class codec 1
>>>>>  codec preference 1 g711ulaw
>>>>>  codec preference 2 g729r8
>>>>> dial-peer voice 100 voip
>>>>>  destination-pattern ....
>>>>>  session protocol sipv2
>>>>>  session target ipv4:172.21.20.10
>>>>>  voice-class codec 1
>>>>>  dtmf-relay rtp-nte
>>>>>  no vad
>>>>> dial-peer voice 1 pots
>>>>>  incoming called-number .
>>>>>  direct-inward-dial
>>>>>
>>>>>
>>>>>
>>>>> On Mon, Apr 26, 2010 at 3:58 PM, Ahmed Elnagar <
>>>>> ahmed_elnagar at rayacorp.com> wrote:
>>>>>
>>>>>>  You have to bind signal and media traffic out of the router to the
>>>>>> CUCM with the IP address you have configured on CUCM “by default CUCM reject
>>>>>> calls with source address other than the configured”
>>>>>>
>>>>>>
>>>>>>
>>>>>> Try the below on the gateway:
>>>>>>
>>>>>>
>>>>>>
>>>>>> voice service voip
>>>>>>
>>>>>> sip
>>>>>>
>>>>>> bind all source-interface “interface configured on CUCM”
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>  Best Regards;
>>>>>>
>>>>>>   Ahmed Elnagar
>>>>>>
>>>>>>   Senior Network PS Engineer
>>>>>>
>>>>>>   Mob: +2019-0016211
>>>>>>
>>>>>>  [image: ccie_voice_large.gif][image: ccvp_voice_large.gif]
>>>>>>
>>>>>>
>>>>>>
>>>>>> *From:* cisco-voip-bounces at puck.nether.net [mailto:
>>>>>> cisco-voip-bounces at puck.nether.net] *On Behalf Of *Brian Schultz
>>>>>> *Sent:* Monday, April 26, 2010 10:34 PM
>>>>>> *To:* cisco-voip at puck.nether.net
>>>>>> *Subject:* [cisco-voip] SIP gateway config
>>>>>>
>>>>>>
>>>>>>
>>>>>> Does anyone happen to have an example SIP gateway config for an ISR?
>>>>>> CUCM 8.0(2) with a SIP trunk to a 2921 gateway (15.0.M1.12) with a standard
>>>>>> PRI for PSTN access.  I have outbound working, but inbound gives a fast busy
>>>>>> with a 401 Unauthorized in the SIP debug.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Disclaimer: NOTICE The information contained in this message is
>>>>>> confidential and is intended for the addressee(s) only. If you have received
>>>>>> this message in error or there are any problems please notify the originator
>>>>>> immediately. The unauthorized use, disclosure, copying or alteration of this
>>>>>> message is strictly forbidden. Raya will not be liable for direct, special,
>>>>>> indirect or consequential damages arising from alteration of the contents of
>>>>>> this message by a third party or as a result of any malicious code or virus
>>>>>> being passed on. Views expressed in this communication are not necessarily
>>>>>> those of Raya.If you have received this message in error, please notify the
>>>>>> sender immediately by email, facsimile or telephone and return and/or
>>>>>> destroy the original message.
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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/20100426/3357e36a/attachment.html>


More information about the cisco-voip mailing list