Hi László,
if I get you right, the ;transport=udp parameter is missing in the
authorization uri in the message sent by SIPp as compared to the message
sent by the Avaya phone, correct? Can you confirm that it is missing
also in the uri in the WWW-Authenticate header in the 407 received by
the Avaya phone (i.e. that the Avaya phone actually doesn't respond by
exactly the same uri which it has received in the WWW-Authenticate header)?
Next, I can see a difference in Call-ID value between steps 1-3 on one
side and step 4 on the other, is it just due to copying from different
test runs or you really generate the REGISTER with the Authorization
header by a different instance of your SIPp scenario than the original
one? I could imagine that the registrar expects the REGISTER with
Authorization to have the same Call-ID value like the previous one.
Pavel
Dne 10.8.2016 v 16:23 Olah Laszlo napsal(a):
Dear Colleagues,
Since a MoH test case I would like to register two SIPp endpoints as a
3rd party device (w. digest authentication) under a Cisco UCM, but I
stucked.
Unfortunately I do not see any response from UCM after the
authenticated REGISTER, neither in the SIPp nor UCM log.
Here you can see the process:
1. Unauthenticated REGISTER request - SIPp > UCM
REGISTER sip:10.10.10.10;transport=udp SIP/2.0
Via: SIP/2.0/udp 10.10.10.20:5060;rport;branch=z9hG4bK-22782-1-0;alias
Route: <sip:10.10.10.10;transport=udp;lr>
Max-Forwards: 70
From: <sip:141@10.10.10.10
<mailto:141@10.10.10.10>>;tag=wE0HzCtlw8Ha9KJQ3hhWpgd3qJzehRIf
To: <sip:141@10.10.10.10 <mailto:141@10.10.10.10>>
Call-ID: 1-22782@10.10.10.20 <mailto:1-22782@10.10.10.20>
CSeq: 30608 REGISTER
Contact: <sip:141@10.10.10.20 <mailto:141@10.10.10.20>:5060;ob>
Expires: 1800
User-Agent: SIPp
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
NOTIFY, REFER, MESSAGE, OPTIONS
Content-Length: 0
2. TRYING - UCM > SIPp
SIP/2.0 100 Trying
Via: SIP/2.0/udp 10.10.10.20:5060;rport;branch=z9hG4bK-22836-1-0;alias
From: <sip:141@10.10.10.10
<mailto:141@10.10.10.10>>;tag=wE0HzCtlw8Ha9KJQ3hhWpgd3qJzehRIf
To: <sip:141@10.10.10.10 <mailto:141@10.10.10.10>>
Call-ID: 1-22836@10.10.10.20 <mailto:1-22836@10.10.10.20>
CSeq: 1 REGISTER
Content-Length: 0
3. 401 Unauthorized - UCM > SIPp
SIP/2.0 401 Unauthorized
Via: SIP/2.0/udp 10.10.10.20:5060;rport;branch=z9hG4bK-22836-1-0;alias
From: <sip:141@10.10.10.10
<mailto:141@10.10.10.10>>;tag=wE0HzCtlw8Ha9KJQ3hhWpgd3qJzehRIf
To: <sip:141@10.10.10.10 <mailto:141@10.10.10.10>>;tag=2017397520
<tel:2017397520>
Call-ID: 1-22836@10.10.10.20 <mailto:1-22836@10.10.10.20>
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm=""ccmsipline"",
nonce=""VhK7c6C8gtbZoejccG9AAst5zAYlfpGw"", algorithm=MD5
Content-Length: 0
4. Authenticated REGISTER request SIPp > UCM
REGISTER sip:10.10.10.10;transport=udp SIP/2.0
Via: SIP/2.0/udp 10.10.10.20:5060;rport;branch=z9hG4bK-22782-1-3;alias
Route: <sip:10.10.10.10;transport=udp;lr>
Max-Forwards: 70
From: <sip:141@10.10.10.10
<mailto:141@10.10.10.10>>;tag=wE0HzCtlw8Ha9KJQ3hhWpgd3qJzehRIf
To: <sip:141@10.10.10.10 <mailto:141@10.10.10.10>>
Call-ID: 1-22782@10.10.10.20 <mailto:1-22782@10.10.10.20>
CSeq: 30609 REGISTER
Contact: <sip:141@10.10.10.20 <mailto:141@10.10.10.20>:5060;ob>
Expires: 1800
User-Agent: SIPp
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
NOTIFY, REFER, MESSAGE, OPTIONS
Authorization: Digest
username=""digest1"",realm=""ccmsipline"",uri=""sip:10.10.10.10:5060"",nonce=""VhK7c6C8gtbZoejccG9AAst5zAYlfpGw"",response=""eb4cd4b46230e24464e806dd018a43fc"",algorithm=MD5
Content-Length: 0
I have registered an AVAYA device to see and compare the SIP log
during the registration. I saw one difference between the SIP logs, at
the 4th step the transport=udp is missing from the Authorization line,
right after the "uri=sip:10.10.10.10:5060"
I have no clue the CUCM why ignore the authenticated REGISTER request.
Have you seen this kind of problem before?
Do you have any idea?
Thanks in advance,
Laszlo
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. http://sdm.link/zohodev2dev
_______________________________________________
Sipp-users mailing list
Sipp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sipp-users
