[cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2

Mon Jul 20 10:44:04 EDT 2015

Hello List,

So the SIP error has returned.  Here is the SIP messages from RTMT.   
Could someone help me decipher this to see if its still a problem with 
my CUCM system -

*Message Details*

*SENDER*: [SIP_Trunk_to_Avaya_SM_in_Waterman] 132.198.214.142
*GUID*: 762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10
*MSG_LABEL*: BYE
*RECEIVER*: 132.198.212.10
*MAC_ADDRESS*: SIP_Trunk_to_Avaya_SM_in_Waterman
*MSGTAG*: 247636
*MSG_TYPE*: UCM_CTRACE
*CORRELATIONID*: 1,100,14,52831.13^132.198.214.142^*
*TIMESTAMP*: 2015/07/20 10:13:30.151

*Detailed Sip Message*

BYE sip:69989 at 132.198.212.10:5060;transport=tcp SIP/2.0
Supported: 100rel, x-nortel-sipvc, replaces
User-Agent: Nortel CS1000 SIP GW release_7.0 version_ssLinux-7.50.17 
AVAYA-SM-6.3.4.0.634014
Av-Global-Session-ID: 77c7ab20-2ee9-11e5-847c-441ea147e4bc
Via: SIP/2.0/TCP 132.198.214.142;branch=z9hG4bK931848089746318-AP;ft=6
Via: SIP/2.0/TCP 
132.198.214.143:15060;rport=35524;ibmsid=local.1395266134606_56407986_67625207;branch=z9hG4bK931848089746318
Via: SIP/2.0/TCP 
132.198.214.142;branch=z9hG4bK-fdd6d8-df8f3c38-31f77891-AP;ft=36420;received=132.198.214.142;rport=30320
Via: SIP/2.0/TCP 
132.198.214.130:5060;branch=z9hG4bK-fdd6d8-df8f3c38-31f77891
Allow: INVITE, ACK, BYE, REGISTER, REFER, NOTIFY, CANCEL, PRACK, 
OPTIONS, INFO, SUBSCRIBE, UPDATE
From: < sip:68008 at 132.198.214.142> 
;tag=ad4defa8-82d6c684-13c4-55013-fdd6cb-2559fabb-fdd6cb
To: " 200 19 ROOSEVELT HWY" < sip:69989 at 132.198.212.10> 
;tag=99915~0beb0a3f-1893-4c98-817f-0979807ce2fb-26487138
Call-ID: 762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10
Max-Forwards: 67
CSeq: 1 BYE
Content-Length: 0

*Message In Log File*

2015/07/20 10:13:17.606|CC|SETUP|26487137|26487138|69989|68008|68008
2015/07/20 
10:13:17.642|CC|OFFERED|26487137|26487138|69989|68008|68008|SEPF02572786B0B|SIP_Trunk_to_Avaya_SM_in_Waterman
2015/07/20 
10:13:17.642|SIPT|26487138|TCP|OUT|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|5060|1,100,14,16.18836^132.198.212.10^MTP_SWICK01|247610|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|INVITE
2015/07/20 
10:13:17.645|SIPT|26487138|TCP|IN|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|5060|1,100,14,44771.1445^132.198.214.142^*|247611|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|100 
Trying
2015/07/20 
10:13:17.660|SIPT|26487138|TCP|IN|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|5060|1,100,14,44771.1446^132.198.214.142^*|247612|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|180 
Ringing
2015/07/20 
10:13:27.535|SIPT|26487138|TCP|IN|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|5060|1,100,14,44771.1447^132.198.214.142^*|247632|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|200 
OK
2015/07/20 
10:13:27.536|SIPT|26487138|TCP|OUT|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|5060|1,100,14,44771.1447^132.198.214.142^*|247633|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|ACK
2015/07/20 
10:13:30.151|SIPT|26487138|TCP|IN|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|48525|1,100,14,52831.13^132.198.214.142^*|247636|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|BYE
2015/07/20 10:13:30.156|CC|RELEASE|26487137|26487138|16
2015/07/20 
10:13:30.157|SIPT|26487138|TCP|OUT|132.198.212.10|5060|SIP_Trunk_to_Avaya_SM_in_Waterman|132.198.214.142|48525|1,100,14,52831.13^132.198.214.142^*|247637|762c8200-5ad101fd-b8bc-ad4c684 at 132.198.212.10|200 
OK

Michael T. Voity
Network Engineer
University of Vermont

On 7/14/2015 9:48 AM, Michael T. Voity wrote:
> Hi Dan,
>
>
> Last night I migrated to 10.5.2.SU2 and then this morning applied the 
> ciscocm.FQDNwithDNS-v1.0.k3.cop.sgn patch.
>
> On both CUCM and CS1000 we are using straight IP address and not a 
> FQDN for comm.    Since I did this patch's I am going to let things 
> bake and see if the error(s) returns.
>
> I will keep my eyes on RTMT too see how things behave.
>
> -Mike
>
>
>
>
>
> Michael T. Voity
> Network Engineer
> University of Vermont
> (802) 656-8112
>
> On 7/14/2015 9:29 AM, Daniel Pagan wrote:
>> Is your Nortel PBX sending a FQDN in the Contact header? This is 
>> important because in 10.5(2) CUCM performs a SRV and A Record lookup 
>> on FQDNs contained in a SIP Contact header. If this lookup fails, 
>> then expect to see a CANCEL followed by a BYE. I encountered this a 
>> few times over the past few months and ended up creating a defect 
>> against it. Check out CSCuu84269. If you want, I wouldn't mind taking 
>> a quick look at your detailed CCM SDL traces offline and letting you 
>> know if you're experiencing this defect. If you are, I'll send you a 
>> sample LUA script to use for converting the FQDN to IP address as a 
>> workaround which you can use for testing and workaround purposes (... 
>> and I can't guarantee this will work for you).
>>
>> Hope this helps.
>>
>> - Dan
>>   -----Original Message-----
>> From: cisco-voip [mailto:cisco-voip-bounces at puck.nether.net] On 
>> Behalf Of Michael T. Voity
>> Sent: Monday, July 13, 2015 9:56 AM
>> To: voip puck
>> Subject: [cisco-voip] Nortel 81C / CS1000 SIP Trunk to CUCM 10.5.2
>>
>> Hello,
>>
>> Before we installed our Cisco CM 10.5.2 system everything here at the
>> University is fed from a Nortel Avaya 81c / CS1000 system.   The Telcom
>> group has a bunch of systems on it that support SIP and SIP gateways.
>> We setup a SIP trunk between the two systems from a guide that Avaya
>> provided.   It works fine like 99% of the time.
>>
>> I am finding that I have to reset the SIP trunk every couple of days 
>> because it looks like the Nortel is busying out all the channels and it
>> can only pass certain traffic.   Example is that someone from Nortel
>> land dials a 5 digit extension that has been routed to CUCM, the line 
>> on CUCM rings once and then discos the call.
>>
>> Looking at RTMT on the SIP traffic I can tell that the Nortel is sending
>> the "BYE" message on the trunk right when the CUCM sends the "RINGING"
>> The only way that I have found to correct this is to reset the SIP 
>> trunk from CUCM.
>>
>> Has anyone see an issue like this and or heard of this?
>>
>> Any ideas would be helpful!
>>
>> -Mike
>>
>> -- 
>> Michael T. Voity
>> Network Engineer
>> University of Vermont
>>
>> _______________________________________________
>> 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/20150720/ff4a3628/attachment.html>