SIP Client failing to register

[Rushmead]

Hi,

I've got a drachtio server running as part of my Jambonz setup, it's all on a private network with no public IP addresses. I've got a problem with the SIP Client I'm using (Cisco 7970) that it seems to send the SIP REGISTER requests from a higher port but expects to receive the response on the 5060 control port. Here are the logs from my drachtio server:

2024-09-06 15:48:38.115571 recv 710 bytes from udp/[10.10.3.7]:50933 at 15:48:38.115490:
REGISTER sip:phones.mydomain.com SIP/2.0
Via: SIP/2.0/UDP 10.10.3.7:5060;branch=z9hG4bK148fe9fb
From: <sip:[email protected]>;tag=0024c442d6430060d0bf52e4-991474dd
To: <sip:[email protected]>
Call-ID: [email protected]
Max-Forwards: 70
Date: Thu, 13 Nov 2008 23:36:38 GMT
CSeq: 201 REGISTER
User-Agent: Cisco-CP7970G/8.4.0
Contact: <sip:[email protected]:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0024c442d643>";+u.sip!model.ccm.cisco.com="30006"
Supported: (null),X-cisco-xsi-7.0.1
Content-Length: 0
Reason: SIP;cause=200;text="cisco-alarm:20 Name=SEP0024C442D643 Load=SIP70.8-4-2S Last=phone-keypad"
Expires: 3600
 
2024-09-06 15:48:38.115645 send 439 bytes to udp/[10.10.3.7]:50933 at 15:48:38.115604:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.10.3.7:5060;branch=z9hG4bK148fe9fb;rport=50933
From: <sip:[email protected]>;tag=0024c442d6430060d0bf52e4-991474dd
To: <sip:[email protected]>;tag=9H2Zy1S4jNXFN
Call-ID: [email protected]
CSeq: 201 REGISTER
WWW-Authenticate: Digest realm="phones.mydomain.com", algorithm=MD5, qop="auth", nonce="172563771463800"
Content-Length: 0

The phone never receives the Unauthorized response and so continually tries to register without the digest authentication.

Now from my understanding of the RFC's, ideally the SIP client would include the rport=5060 parameter on the Via header but this is an old phone that isn't going to get any updates anytime soon! My understanding is that the server should only fill the rport in if the request Via header contains the rport parameter but has no value?

Any thoughts and solutions are much appreciated! Any extra information from me please let me know!

[CrazyTux]

Is there any ALG involved?

[nvwx]

Hello, port 50933 is the client-side of the UDP conversation. It is communicating with drachtio, which is listening on UDP 5060 as the server-side of the conversation. This brief discussion may help illustrate that behavior - https://www.geeksforgeeks.org/udp-server-client-implementation-c/

To confirm whether the phone receives the 401 message or not would require a packet capture of the switchport the phone is plugged into. Alternatively, you can capture from the PC port on the phone: https://community.cisco.com/t5/collaboration-knowledge-base/collecting-a-packet-capture-from-a-cisco-ip-phone/ta-p/3119480

The phone should respond to a 401 message with the digest credentials configured in the phone's XML configuration. Can you confirm you have configured those credentials?

[Rushmead]

@CrazyTux

Is there any ALG involved?

The ALG on my router is disabled, so as far as I know, no.

@nvwx

To confirm whether the phone receives the 401 message or not would require a packet capture of the switchport the phone is plugged into. Alternatively, you can capture from the PC port on the phone: community.cisco.com/t5/collaboration-knowledge-base/collecting-a-packet-capture-from-a-cisco-ip-phone/ta-p/3119480

I've done a packet capture and can see the 401 packet is making it back to the network interface hence why I believe the phone is expecting the response on the 5060 port (there are also other people who have mentioned this behaviour when using similar models of phone).

Here's a picture of the wireshark capture of the PC port, this is the REGISTER request packet, you can see the UDP send port is different from what is mentioned in the actual SIP data

The phone should respond to a 401 message with the digest credentials configured in the phone's XML configuration. Can you confirm you have configured those credentials?

Yes the phone is configured with the digest credentials - I have previously seen this configuration of the phone correctly send the digest credentials.

[CrazyTux]

Are you able to listen on server side to non standard 5060 to see if maybe an ALG is in play based on destination port?

What router are you using?

Alternatively does the phone have "use random source port"?

[CrazyTux]

Also try connecting laptop to phone port and sending manual REGISTER with sipsak and see if you are able to get back a 401.

[Rushmead]

Also try connecting laptop to phone port and sending manual REGISTER with sipsak and see if you are able to get back a 401.

Just done this and yes can confirm am receiving the 401, I definitely don't think there is a network issue here now.

Alternatively does the phone have "use random source port"?

The problem with these phones is that they don't have much documentation, as far as I can tell there is no "use random source port" option in the configuration.

[CrazyTux]

Next step would be to enable debug syslog on the Cisco itself to see what it's doing with the 401 if it is indeed receiving it.

[davehorton]

It seems like you have a broken Cisco client. What is happening here is that drachtio detects that the message has been sent from 10.10.3.7:50933 but that the client says (via the Via) that it sent from 10.10.3.7:5060. Given that 10.10.3.7 is an RFC 1918 address drachtio then concludes that what we have here is a SIP client behind a nat device. Therefore, it sends the response back to the actual sending address, which is 10.10.3.7:50933.

This, in my opinion, is correct behavior on behalf of drachtio. However, given that you say this is entirely a private network with no public network traffic (and presumably somehow your Cisco device is not behind a nat....though I wonder if that is really true), you may have a workaround. Try starting drachtio server with this command line argument to entirely disable the nat detection feature:

--disable-nat-detection

That may possibly help you out. Failing that....work with functional sip clients.

[Rushmead]

It seems like you have a broken Cisco client. What is happening here is that drachtio detects that the message has been sent from 10.10.3.7:50933 but that the client says (via the Via) that it sent from 10.10.3.7:5060. Given that 10.10.3.7 is an RFC 1918 address drachtio then concludes that what we have here is a SIP client behind a nat device. Therefore, it sends the response back to the actual sending address, which is 10.10.3.7:50933.

This, in my opinion, is correct behavior on behalf of drachtio. However, given that you say this is entirely a private network with no public network traffic (and presumably somehow your Cisco device is not behind a nat....though I wonder if that is really true), you may have a workaround. Try starting drachtio server with this command line argument to entirely disable the nat detection feature:

--disable-nat-detection

That may possibly help you out. Failing that....work with functional sip clients.

Thanks for the response, I appreciate that this SIP Client is not doing expected behaviour so there isn't much that can be done! I've tried starting drachtio with the --disable-nat-detection argument but it doesn't seem to have made any difference, it's still sending the response to the port it received the packet from.

Based on your explanation I'd agree that it sounds like drachtio is doing correct the behaviour and this is just a problem with the SIP client (using other SIP clients and soft phones on the same network work fine!). I'll continue to try and muddle through to a solution but i suspect that I'll have to bail on this model of phone.

[Rushmead]

Just to give a small update, I managed to get it working after creating a build of drachtio with the following line changed

drachtio-server/src/controller.cpp

Line 1319 in 2b51d5b

NTATAG_SERVER_RPORT(2), //force rport even when client does not provide

Setting this to 1 instead means that it will follow the rPort if there is one and won't if there isn't. I'm sure there's a valid reason for it to be set to 2 inside Drachtio so I won't expect a change from you.

Few little tweaks within Jambonz to make it understand the weirdness and we're there, thanks for your help!