Cisco-7960 & GXE-5028 Interoperability

2010-02-22T13:06:00.000-06:00

A lot of people complain about interoperability problem between the Cisco 7940/7960 VOIP phone and the Granstream GXE-5024/5028 SIP PBX. Looks like Cisco is unable (for some magical reason) to register on GXE. I have used Cisco phones for years and recently bought the GXE-5028 with a bunch of GXP-2000 phones. So now we are able to build a “testing lab:”

GXE-5028 (firmware 1.0.1.54) is a SIP server with IP addr 192.168.2.1
Cisco7960 (firmware P0S3-08-11-00) is a SIP client/terminal (ext #118) IP addr 192.168.2.54
GXE-2000 (firmware 1.2.2.26) is an another SIP client/terminal (ext #118 also) IP addr 192.168.2.109

Wireshark (www.wireshark.org) is being used for traffic capturing/analyzing.
All devices utilizing UDP SIP.

Let's see how Cisco is trying to communicate with GXE and where the misunderstanding begins over there.

The first packet a decent SIP client has to send to a SIP server is a REGISTER request. Cisco is a decent device for sure, and sends a UDP packet from random UDP port to predefined 5060 port on GXE, here is the packet (with some important spots highlighted):

Frame 1 (540 bytes on wire, 540 bytes  captured)
Ethernet II, Src: Cisco_18:72:09  (00:1b:0c:18:72:09), Dst: Grandstr_17:e6:b7 (00:0b:82:17:e6:b7)
Internet Protocol, Src: 192.168.2.54  (192.168.2.54), Dst: 192.168.2.1 (192.168.2.1)
User Datagram Protocol, Src Port: 50485 (50485), Dst Port:  sip (5060)
Session Initiation Protocol
   Request-Line: REGISTER sip:192.168.2.1 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
   Message Header
        Via: SIP/2.0/UDP  192.168.2.54:5060;branch=z9hG4bK20f9ce38
           Transport: UDP
           Sent-by Address: 192.168.2.54
           Sent-by port: 5060
           Branch: z9hG4bK20f9ce38
        From: <sip:118@192.168.2.1>;tag=001b0c187209166042a5fba9-1c16536a
           SIP from address: sip:118@192.168.2.1
           SIP tag: 001b0c187209166042a5fba9-1c16536a
        To: <sip:118@192.168.2.1>
           SIP to address: sip:118@192.168.2.1
        Call-ID: 001b0c18-72090017-63975e06-76da979f@192.168.2.54
        Max-Forwards: 70
        CSeq: 1202 REGISTER
           Sequence Number: 1202
           Method: REGISTER
        User-Agent: Cisco-CP7960G/8.0
        Contact:  <sip:118@192.168.2.54:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001b0c187209>";+u.sip!model.ccm.cisco.com="7"
           Contact Binding:  <sip:118@192.168.2.54:5060;transport=udp>;+sip.instance="<urn:uuid:00000000-0000-0000-0000-001b0c187209>";+u.sip!model.ccm.cisco.com="7"
               URI: <sip:118@192.168.2.54:5060;transport=udp>
                   SIP contact address: sip:118@192.168.2.54:5060
        Content-Length: 0
        Expires: 120

GXE received this request successfully, and sends a response:

Frame 2 (522 bytes on wire, 522 bytes  captured)
Ethernet II, Src: Grandstr_17:e6:b7  (00:0b:82:17:e6:b7), Dst: Cisco_18:72:09 (00:1b:0c:18:72:09)
Internet Protocol, Src: 192.168.2.1  (192.168.2.1), Dst: 192.168.2.54 (192.168.2.54)
User Datagram Protocol, Src Port:  sip (5060), Dst Port: 50485 (50485)
Session Initiation Protocol
   Status-Line: SIP/2.0 100 Trying
       Status-Code: 100 
        [Resent Packet: False]
   Message Header
        Via: SIP/2.0/UDP 192.168.2.54:5060;branch=z9hG4bK20f9ce38;rport=50485
           Transport: UDP
           Sent-by Address: 192.168.2.54
           Sent-by port: 5060
           Branch: z9hG4bK20f9ce38
           RPort: 50485
        From: <sip:118@192.168.2.1>;tag=001b0c187209166042a5fba9-1c16536a
           SIP from address: sip:118@192.168.2.1
           SIP tag: 001b0c187209166042a5fba9-1c16536a
        To: <sip:118@192.168.2.1>
           SIP to address: sip:118@192.168.2.1
        Call-ID: 001b0c18-72090017-63975e06-76da979f@192.168.2.54
        CSeq: 1202 REGISTER
           Sequence Number: 1202
           Method: REGISTER
        Contact: <sip:192.168.2.1:5060>
           Contact Binding: <sip:192.168.2.1:5060>
               URI: <sip:192.168.2.1:5060>
                   SIP contact address: sip:192.168.2.1:5060
        Supported: replaces, timer
        User-Agent: Grandstream GXE5028 1.0.1.54
        Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, PUBLISH, INFO,  REFER, UPDATE
        Content-Length: 0

Attention! Here is very interesting and important point, look at the Red highlighted spot: GXE sends the response to the UDP port where the request was sent from. Nothing's wrong at first glance, n'est-ce pas? But Cisco thinks different and looks puzzled:

Frame 3 (70 bytes on wire, 70 bytes captured)
Ethernet II, Src: Cisco_18:72:09  (00:1b:0c:18:72:09), Dst: Grandstr_17:e6:b7 (00:0b:82:17:e6:b7)
Internet Protocol, Src: 192.168.2.54  (192.168.2.54), Dst: 192.168.2.1 (192.168.2.1)
Internet Control Message Protocol
   Type: 3 (Destination unreachable)
   Code: 3 (Port unreachable)
   Checksum: 0x1e3f  [correct]
   Internet Protocol, Src:  192.168.2.1 (192.168.2.1), Dst: 192.168.2.54 (192.168.2.54)
   User Datagram Protocol,  Src Port:  sip (5060), Dst Port: 50485 (50485)

“Hey guys, I don't know what you want to say, but nobody's listening to you on the 50485 port anymore”, - Cisco says to GXE. Hereby, the registration attempt is falling down L. After a short timeout Cisco starts it from the beginning (look at the Frame 1), however only with the same level of success.

Well, what then? Who is wrong? Why does Cisco not continue to listen to the UDP port the REGISTER request was sent from? Which port does Cisco listen to really? For the complete answer we have to read the RFC 3261 “SIP: Session Initiation Protocol.”

Lets look into the paragraph “18.2 Servers”. The subparagraph 18.2.2 is the most interesting for us:

18.2.2  Sending Responses

  The server transport uses the  value of the top Via header field in
  order to determine where to  send a response. It MUST follow the
  following process:

     o  If the  "sent-protocol" is a reliable transport protocol such as
        TCP or SCTP, or TLS over  those, the response MUST be sent using
        the existing connection to  the source of the original request
        that created the transaction,  if that connection is still open.
        This requires the server  transport to maintain an association
        between server transactions  and transport connections.  If that
        connection is no longer open,  the server SHOULD open a
        connection to the IP address  in the "received" parameter, if
        present, using the port in  the "sent-by" value, or the default
        port for that transport, if  no port is specified.  If that
        connection attempt fails, the  server SHOULD use the procedures
        in [4] for servers in order  to determine the IP address and
        port to open the connection  and send the response to.

     o  Otherwise, if the Via  header field value contains a "maddr"
        parameter, the response MUST  be forwarded to the address listed
        there, using the port  indicated in "sent-by", or port 5060 if
        none is present.  If the  address is a multicast address, the
        response SHOULD be sent using  the TTL indicated in the "ttl"
        parameter, or with a TTL of 1  if that parameter is not present.

     o  Otherwise (for unreliable unicast  transports), if the top Via
        has a "received" parameter, the  response MUST be sent to the
        address in the "received"  parameter, using the port indicated
        in the "sent-by" value, or using  port 5060 if none is specified
        explicitly.  If this fails, for  example, elicits an ICMP "port
        unreachable" response, the procedures  of Section 5 of [4]
        SHOULD be used to determine where to send  the response.

“Section 5 of [4]” references us to Section 5 in RFC 3263 “Session Initiation Protocol (SIP): Locating SIP Servers”:

5 Server  Usage

  RFC 3261 [1] defines procedures for sending responses  from a server
  back to the client.  Typically, for unicast UDP  requests, the
  response is sent back to the source IP address where  the request came
  from, using the port contained in the Via  header.  For reliable
  transport protocols, the response is sent over the  connection the
  request arrived on.  However, it is important to  provide failover
  support when the client element fails between sending  the request and
  receiving the response.

  A server, according to RFC 3261 [1], will send a response on the
  connection it arrived on (in the case of reliable  transport
  protocols), and for unreliable transport protocols, to the source
  address of the request, and  the port in the Via header field.  The
  procedures here are invoked when a server attempts to  send to that
  location and that response fails (the specific  conditions are
  detailed in RFC 3261). "Fails" is defined  as any closure of the
  transport connection the request came in on before  the response can
  be sent, or communication of a fatal error from the  transport layer.

  In these cases, the server examines the value of the  sent-by
  construction in the topmost Via header.  If it  contains a numeric IP
  address, the server attempts to send the response to  that address,
  using the transport protocol from the Via header, and  the port from
  sent-by, if present, else the default for that  transport protocol.
  The transport protocol in the Via header can indicate  "TLS", which
  refers to TLS over TCP.  When this value is  present, the server MUST
  use TLS over TCP to send the response.

Is it not clear?
Now, lets look at the Cisco REGISTER request (“Frame 1”) yellow highlighted spots:

Via: SIP/2.0/UDP  192.168.2.54:5060;branch=z9hG4bK20f9ce38
           Transport: UDP
           Sent-by Address: 192.168.2.54
           Sent-by port: 5060

Here is an answer: Cisco is waiting for the SIP server response listening UDP port 5060, and telling the server about it in quite clear form, in accordance with RFC. For some unknown reason, GXE ignores the “Via header field” and sends their responses to the source port of the request packet (in our case it is port 50485). But how does the Grandstream GXP-2000 phone work? How can the GXP-2000 encourage the dumb GXE to send packets to the proper UDP port where they are expected?

Well, GXP-2000 uses a very simple trick – it sends all packets using not a random, but a fixed port:

HTTP Grandstream Device Configuration -> ACCOUNT N -> local SIP port: (default 5060)

Here is a REGISTER request from GXP-2000:

Frame 12 (625 bytes on wire, 625 bytes  captured)
Ethernet II, Src: Grandstr_23:1c:db  (00:0b:82:23:1c:db), Dst: Grandstr_17:e6:b7 (00:0b:82:17:e6:b7)
Internet Protocol, Src: 192.168.2.109  (192.168.2.109), Dst: 192.168.2.1 (192.168.2.1)
User Datagram Protocol, Src Port: sip (5060), Dst Port:  sip (5060)
Session Initiation Protocol
   Request-Line: REGISTER  sip:192.168.2.1:5060 SIP/2.0
        Method: REGISTER
        [Resent Packet: False]
   Message Header
        Via: SIP/2.0/UDP 192.168.2.109:5060;branch=z9hG4bKbffce08672adb95f
           Transport: UDP
           Sent-by Address: 192.168.2.109
           Sent-by port: 5060
           Branch: z9hG4bKbffce08672adb95f
        From: <sip:118@192.168.2.1:5060>;tag=9a7e40fa42dc8850
           SIP from address: sip:118@192.168.2.1:5060
           SIP tag: 9a7e40fa42dc8850
        To: <sip:118@192.168.2.1:5060>
           SIP to address: sip:118@192.168.2.1:5060
        Contact: <sip:118@192.168.2.109:5060;transport=udp>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000b82231cdb>"
           Contact Binding:  <sip:118@192.168.2.109:5060;transport=udp>;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000b82231cdb>"
               URI: <sip:118@192.168.2.109:5060;transport=udp>
                   SIP contact address: sip:118@192.168.2.109:5060
        Supported: path
        Call-ID: fc22530b910b52fd@192.168.2.109
        CSeq: 10001 REGISTER
           Sequence Number: 10001
           Method: REGISTER
        Expires: 3600
        User-Agent: Grandstream GXP2000 1.2.2.26
        Max-Forwards: 70
        Allow:  INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE,UPDATE,PRACK,MESSAGE
        Content-Length: 0

And here is the GXE response:

Frame 13 (495 bytes on wire, 495 bytes  captured)
Ethernet II, Src: Grandstr_17:e6:b7  (00:0b:82:17:e6:b7), Dst: Grandstr_23:1c:db (00:0b:82:23:1c:db)
Internet Protocol, Src: 192.168.2.1  (192.168.2.1), Dst: 192.168.2.109 (192.168.2.109)
User Datagram Protocol, Src Port:  sip (5060), Dst Port: sip (5060)
Session Initiation Protocol
   Status-Line: SIP/2.0 100  Trying
        Status-Code: 100
        [Resent Packet: False]
   Message Header
        Via: SIP/2.0/UDP 192.168.2.109:5060;branch=z9hG4bKbffce08672adb95f
           Transport: UDP
           Sent-by Address: 192.168.2.109
           Sent-by port: 5060
           Branch: z9hG4bKbffce08672adb95f
        From: <sip:118@192.168.2.1:5060>;tag=9a7e40fa42dc8850
           SIP from address: sip:118@192.168.2.1:5060
           SIP tag: 9a7e40fa42dc8850
        To: <sip:118@192.168.2.1:5060>
           SIP to address: sip:118@192.168.2.1:5060
        Call-ID: fc22530b910b52fd@192.168.2.109
        CSeq: 10001 REGISTER
           Sequence Number: 10001
           Method: REGISTER
        Contact: <sip:192.168.2.1:5060>
           Contact Binding: <sip:192.168.2.1:5060>
               URI: <sip:192.168.2.1:5060>
                   SIP contact address: sip:192.168.2.1:5060
        Supported: replaces, timer
        User-Agent: Grandstream GXE5028 1.0.1.54
        Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, PUBLISH, INFO,  REFER, UPDATE
        Content-Length: 0

Everything works fine, GXP and GXE are so much happier with each other.

Well, but how can we force Cisco 7960 to send SIP packets not from a randomly chosen port, but from a fixed port, and continue to listen for a response on it? There are not so many configuration parameters for Cisco (at least I do not know of many), and there is nothing that looks like Grandstream’s “local SIP port.”

Of course, there is another option: fix the bugged GXE firmware, or force Grandstream to do it… But we need results right this instance.

Fortunately, the workaround exist and has been found eventually:

From C7960/7040 keypad:
Cisco settings -> SIP configuration -> NAT Enabled = YES

OR, in sipdefault.cnf (if you use configuration over TFTP):
nat_enable: Yes

It is not necessary to define the “NAT address” parameter - it can be left empty.

PS. The "Black Mark" goes to Granstream for grossly disregards of standards.

Marginal notes

Cisco-7960 & GXE-5028 Interoperability