Re: MRA Multiline Phone

aalejo · ‎01-07-2019

Dear Community:

Looking to traces on MRA multi lines phone registration, i don't see second or tertiary lines numbers on the registration process (on the REGISTER message specifically)?

Does someone knows how those secondary and tertiary lines get register?

Thanks

Mohammed al Baqari · ‎01-07-2019

Hi,

Jabber uses the primary extension assigned to end user for registration.
Even in multiline, only primary extension is used for registration.

The other remaining extensions are handed over to Jabber during the
authentication process with cucm/ldap through the device configuration file
(in this case the device is jabber).

Exp-E

2017-04-04T10:40:50.628+04:00 EXE01-V traffic_server[19291]:
UTCTime="2017-04-04 06:40:50,628" Module="network.http.trafficserver"
Level="INFO": Detail="Receive Request" Txn-id="15723" Src-ip="150.11.2.33"
Src-port="56258" Msg="GET https
:///qwe2emwk32hlbGZkcmlsbGlFbNxeRuZy5jb2e0EdwvaHR0cHMvdfewZHhdiY2NtMD4nz1sS7Etdi5zaGVsZmRyaWxsaW5nLmNvbS82OTcy/CSF1300.cnf.xml<>HTTP/1.1"

Exp-C

2017-04-04T10:40:50.661+04:00 EXC01-V traffic_server[19681]:
UTCTime="2017-04-04 06:40:50,661" Module="network.http.trafficserver"
Level="INFO": Detail="Receive Request" Txn-id="30835" Src-ip="127.0.0.1"
Src-port="34444" Last-via-addr="10.80.50.25" Msg="GET http://vcs_control.testdomain.com:8443/qwe2emwk32hlbGZkcmlsbGlFbNxeRuZy5jb2e0EdwvaHR0cHMvdfewZHhdiY2NtMD4nz1sS7Etdi5zaGVsZmRyaWxsaW5nLmNvbS82OTcy/CSF1300.cnf.xml HTTP/1.1"

The primary extension is obtained before these messages during the login
process

Exp-C

2017-04-04T10:40:50.417+04:00 EXC01-V traffic_server[19681]:
UTCTime="2017-04-04 06:40:50,417" Module="network.http.trafficserver"
Level="INFO": Detail="Sending Response" Txn-id="30831" Dst-ip="127.0.0.1"
Dst-port="34986" Msg="HTTP/1.1 200 OK"

Exp-E

2017-04-04T10:40:50.422+04:00 EXE01-V traffic_server[19291]:
UTCTime="2017-04-04 06:40:50,421" Module="network.http.trafficserver"
Level="INFO": Detail="Sending Response" Txn-id="15721" Dst-ip="150.11.2.33"
Dst-port="56258" Msg="HTTP/1.1 200 OK"

Jabber client logfile

2017-04-04 10:40:50,278 DEBUG [0x00003c28] [netutils\src\http\CurlHttpUtils.cpp(733)] [csf.httpclient] [csf::http::CurlHttpUtils::curlHeaderCallback] - Request #6 got status line: HTTP/1.1 200 OK

2017-04-04 10:40:50,281 DEBUG [0x00003c28] [l\ucm-config\uds\HomeUds100Query.cpp(91)] [csf.config] [csf::ucm90::HomeUds100Query::run] - XML file response:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<id>c60dd912fbe-9e6129-ad7b7-8094-817afcfa1b6ca1f</id>

<userName>mohammed.baqari</userName>

<firstName>Mohammed</firstName>

<lastName>Al Baqari</lastName>

.......

........

.......

<primaryExtension>

<description>Mohammed Al Baqari</description>

<directoryNumber>1300</directoryNumber>

<sendToVoiceMailPilotNumber>false</sendToVoiceMailPilotNumber>

</callForwardAllDestination>

.......

**** Please remember to rate useful posts

HARIS_HUSSAIN · ‎01-07-2019

Great Info Mohammed al Baqari [+5] .

aalejo · ‎01-08-2019

Hey Mohammed

Yes, i understand that provisioning on CUCM is by downloading a configuration file. My question is on Line registration, not on line provisioning.

AFTER PROVISIONING, Device needs to register a line. If device does not register a line on call engine (using any means), it can not receive calls on that line. Also during a call that line needs to be updated (to reflect call status).

Any ideas?

Thanks!

Maren Mahoney · ‎01-08-2019

Is the problem that the additional lines do not appear when Jabber is registered via MRA? (But do appear when logged in on-prem?) If so, the problem may be MRA version rather than a Jabber/CUCM issue. I seem to remember that you need VCS/Expressway X8.10.1 or later for Jabber Multiline. Certain handsets had MRA Multiline support as early as X8.9, but Jabber multiline support was later.

aalejo · ‎01-08-2019

No Problem. Simply trying to understand the process that Cisco uses to register a secondary/tertiary line.

Alex

Maren Mahoney · ‎01-08-2019

Roger that. The last time I set up Jabber Multiline via MRA I noticed that calls outbound to the Jabber client made to any of the 8 lines in CUCM all went to the primary line on Jabber client, while inbound calls from the Jabber client could come into CUCM from any of the lines on the client. It may be (theorizing here) that only the primary line actually registers and the other lines are seen akin to alternate extensions when in MRA mode. That said, different Jabber/CUCM/MRA version combinations may give different results.

I'd say "HTH" at this point, but I suspect it doesn't....lol

Mohammed al Baqari · ‎01-08-2019

You don't need each DN to register with CUCM. Only the 1st DN should is used for the device to register with CUCM. Once the device is registered, cucm can send INVITE calls to all DNs in the device. See sample register message below for a multiline phone. The primary DN is used to fill FROM/TO header but isn't used is register UI.

For status update, unsolicited notify messages are used hence you don't need to register it.

REGISTER sip:ccm02.testdomain.com SIP/2.0
Via: SIP/2.0/TCP 10.170.4.14:5060;egress-zone=CEtcpccm02.testdomain.com;branch=z9hG4bK64a5bd4df7b84856c20c238b1c097d6d1388612.b007120ebf6556c31532ae1bf943110d;proxy-call-id=0903b87f-0c98-4b93-832d-947498f407a9;rport
Via: SIP/2.0/TLS 50.50.50.50:7001;egress-zone=TraversalServer;branch=z9hG4bK511b61ad0e12510736c5f341c6f1a5c0800314.34e7418c55ecab3b253e03fc3ef92da9;proxy-call-id=954c181d-d4ae-4fd5-90b9-59e5ec92a16a;received=50.50.50.50;rport=7001;ingress-zone=TraversalClient
Via: SIP/2.0/TLS 10.80.1.50:59573;branch=z9hG4bK000026ab;received=10.80.1.50;ingress-zone=CollaborationEdgeZone
Call-ID: 8cec4b01-10890031-000065c6-00004d90@10.80.1.50
CSeq: 30725 REGISTER
Contact: <sip:419d175d-7315-ab73-758b-6500f6008a1f@172.16.10.10:5060;transport=tcp;orig-hostport=10.80.1.50:59573>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-8cec4b011089>";+u.sip!devicename.ccm.cisco.com="CSF1300";+u.sip!model.ccm.cisco.com="503";video;bfcp;+u.sip!userid.ccm.cisco.com="mohammed.baqari"
From: <sip:1300@ccm02.testdomain.com>;tag=8cec4b01108960210000445b-00001123
To: <sip:1300@ccm02.testdomain.com>
Max-Forwards: 14
Route: <sip:ccm02.testdomain.com;transport=tcp;lr>
User-Agent: Cisco-CSF
Expires: 660
Date: Wed, 09 Jan 2019 04:23:10 GMT
Supported: replaces,join,sdp-anat,norefersub,resource-priority,extended-refer,X-cisco-callinfo,X-cisco-serviceuri,X-cisco-escapecodes,X-cisco-service-control,X-cisco-srtp-fallback,X-cisco-monrec,X-cisco-config,X-cisco-sis-7.0.0,X-cisco-xsi-8.5.1,X-cisco-graceful-reg,X-cisco-duplicate-reg
P-Asserted-Identity: <sip:1300@ccm02.testdomain.com>
X-TAATag: f43129a5-22c0-4658-a205-87a171077acc
Session-ID: 7049a00f00255000a000078ef1180000;remote=00000000000000000000000000000000
Content-Length: 0