{"id":85,"date":"2020-01-22T15:25:48","date_gmt":"2020-01-22T14:25:48","guid":{"rendered":"https:\/\/www.collabeer.com\/?p=85"},"modified":"2020-06-08T10:56:12","modified_gmt":"2020-06-08T10:56:12","slug":"cisco-phone-not-receiving-calls-from-a-3rd-party-pbx-via-sip-trunk","status":"publish","type":"post","link":"https:\/\/collabeer.com\/?p=85","title":{"rendered":"Cisco Phone not receiving calls from a 3rd party PBX via SIP-Trunk"},"content":{"rendered":"\n

Today I had\nan issue on an incoming SIP Trunk from an Avaya PBX to a CUCM. The calling name\nof the Avaya users included a \u201cgreater as\u201d-sign ( > ). This mixed up the\nContact field on CUCM and the phones were sending back a \u201c400 Bad Request\u201d.<\/p>\n\n\n\n

In the incoming INVITE, the Contact field looked like this:<\/p>\n\n\n\n

Contact: “John Doe >1000” <sip:1000@10.xxx.xxx.xxx:5061;transport=tls;gsid=80b03730-2d3d-4a01-958f-5bff121d0000><\/p><\/blockquote>\n\n\n\n

The CUCM then sent it to the phone like this:<\/p>\n\n\n\n

Contact: <sip:1000@10.xxx.xxx.xxx:5060;transport=tcp>1000″ <sip:1000@10.xxx.xxx.xxx:5061;transport=tls;gsid=80644a7a-4f3c-4a01-9830-5bff121d0000><\/p><\/blockquote>\n\n\n\n

The phone came back with a 400:<\/p>\n\n\n\n

\n

SIP\/2.0 400 Bad Request
Via: SIP\/2.0\/TCP 10.xxx.xxx.xxx:5060;branch=z9hG4bK5391c7ca89d90
From: “John Doe >1000” <sip:1000@10.xxx.xxx.xxx >;tag=2812787~ab46fa2c-6c59-41ed-818f-ce5a53804375-44072776
To: <sip:+41xxxxxxxxx@cucm-002.example.com>
Call-ID: 545dc800-1eb15a39-4d012-1620ed0a@10.xxx.xxx.xxx
Session-ID: 157ee9db00105000a0000072784970f4;remote=9f1f3bd2c18dc694892250dab2812786
Date: Wed, 22 Jan 2020 10:11:04 GMT
Warning: 399 Cisco-CP8851 “Bad Request – ‘Malformed\/Missing Contact field'”
CSeq: 101 INVITE
Content-Length: 0<\/p><\/blockquote>\n<\/div><\/div>\n\n\n\n

As you can see, the CUCM malformed the Contact fiel with putting the \u201c>1000\u201d after the first part:<\/p>\n\n\n\n

Contact: <sip:1000@10.xxx.xxx.xxx:5060;transport=tcp>1000″<\/strong> <sip:1000@10.xxx.xxx.xxx:5061;transport=tls;gsid=80644a7a-4f3c-4a01-9830-5bff121d0000><\/p><\/blockquote>\n\n\n\n

Because it was not possible to change all the names in the Avaya system because of different reasons, I had to fix it on the CUCM. I decided to create a SIP Normalization script, which removes the calling name from the INVITE coming from the Avaya PBX.<\/p>\n\n\n\n

After the normalization, the Contact field looked then like this:<\/p>\n\n\n\n

Contact:<sip:1000@10.xxx.xxx.xxx:5061;transport=tls;gsid=80b03730-2d3d-4a01-958f-5bff121d0000><\/p><\/blockquote>\n\n\n\n

The CUCM\ncan now handle the correctly and the phones are receiving the calls.<\/p>\n\n\n\n

An interesting thing we saw, the calls which were routed to an MRA-Device via Expressway, could receive the calls despite the issue. Probably the Expressway could handle the malformed INVITE or does not check the Contact Field.<\/p>\n\n\n\n

Here the script I\u2019ve created:<\/p>\n\n\n\n

M = {}
function M.inbound_ANY(msg)
trace.enable()
trace.format(“Fix malformed contact” )
— Get Contact-Info Header. If there was no Call-Info header then return
local contactInfo = msg:getHeader(“Contact”)
if not contactInfo
then
trace.format(“Contact is empty, returning” )
return
end
trace.format(“ContactInfo is %s”, contactInfo )
— extract the contact-Info
local start_contact = string.find(contactInfo, “sip:”)
local contact_new = string.sub(contactInfo, start_contact-1)
trace.format(“ContactInfo New is %s”, contact_new )
— replace the header
msg:modifyHeader(“Contact”, contact_new)
trace.format(“header modified”)
end
return M<\/p><\/blockquote>\n","protected":false},"excerpt":{"rendered":"

Today I had an issue on an incoming SIP Trunk from an Avaya PBX to a CUCM. The calling name of the Avaya users included a \u201cgreater as\u201d-sign ( > ). This mixed up the Contact field on CUCM and the phones were sending back a \u201c400 Bad Request\u201d. In the incoming INVITE, the Contact […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"footnotes":""},"categories":[3,4],"tags":[8,9,10,13,21,22,23],"class_list":["post-85","post","type-post","status-publish","format-standard","hentry","category-cisco","category-cucm","tag-3rdparty","tag-bad-request","tag-calling-name","tag-cucm","tag-normalization","tag-sip","tag-trunk"],"_links":{"self":[{"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/posts\/85","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/collabeer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=85"}],"version-history":[{"count":1,"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/posts\/85\/revisions"}],"predecessor-version":[{"id":168,"href":"https:\/\/collabeer.com\/index.php?rest_route=\/wp\/v2\/posts\/85\/revisions\/168"}],"wp:attachment":[{"href":"https:\/\/collabeer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=85"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/collabeer.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=85"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/collabeer.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=85"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}