Professional Geekism

Whilst I’ve been messing about with registering a Grandstream GXP2000 to our CME 4.2 server’s SIP service, I’ve found quite an annoying problem.

The phone registers fine and can make external calls via the SIP trunk absolutely fine. The phone will also accept transfers of internal calls (ephones), but if I attempt to transfer an external call form an ephone, to the Granstream – the external call is cut-off. I’ve isolated the ‘debug ccsip messages’ output which describes what is happening, but I’m by no means an expert in debugging SIP output.

Aug 14 09:16:49.807: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
REFER sip:07xxxxxxxxx@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
Max-Forwards: 70
Contact:
User-Agent: Cisco-SIPGateway/IOS-12.x
Timestamp: 1187083009
Refer-To: sip:2007@cme-router?Replaces=E72682C6-497D11DC-90D890FC-79F613F8%40cme-router
%3Bto-tag%3Ddb0457357be0d469%3Bfrom-tag%3D2CD77068-25C3
Referred-By:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP cme-router:5060;branch=z9hG4bK3432633;received=cme-router
From: ;tag=2CD733C8-216A
To: "Tom" ;tag=as221e2abe
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 102 REFER
User-Agent: Asterisk PBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Contact:
Content-Length: 0


Aug 14 09:16:49.811: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
NOTIFY sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Contact:
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
User-Agent: Asterisk PBX
Max-Forwards: 70
Event: refer;id=102
Subscription-state: terminated;reason=noresource
Content-Type: message/sipfrag;version=2.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Length: 49


SIP/2.0 481 Call leg/transaction does not exist


Aug 14 09:16:49.815: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK49b17aad;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Date: Tue, 14 Aug 2007 09:16:49 GMT
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 104 NOTIFY
Content-Length: 0


Aug 14 09:16:49.843: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
Received:
BYE sip:0116@cme-router:5060 SIP/2.0
Via: SIP/2.0/UDP asterisk-sip-gateway:5060;branch=z9hG4bK136ae0fa;rport
From: "Tom" ;tag=as221e2abe
To: ;tag=2CD733C8-216A
Call-ID: 24524ebd58e984e930f461ff5d490bd9@asterisk-sip-gateway
CSeq: 105 BYE
User-Agent: Asterisk PBX
Max-Forwards: 70
Content-Length: 0


My voice service voip config is as below:

voice service voip
allow-connections sip to sip
no supplementary-service sip moved-temporarily
sip
registrar server expires max 240 min 60
no call service stop


And the Grandstream phone config is:

voice register dn 1
number 2007
allow watch
refer target dial-peer
mwi
!
voice register pool 1
id mac 000B.820D.0536
number 1 dn 1
template 1
dtmf-relay rtp-nte
voice-class codec 1
description Grandstream


Where ‘cme-router’ is the router on which CME 4.2 is installed and running, and ‘asterisk-sip-gateway’ is our SIP gateway (which the CME 4.2 SIP-UA connects to) that handles more advanced call routing features.

If anyone has any ideas – I’d appreciate the help! It’s not a massive problem, but I’m keen to see this one through.

When you’re testing translation rules on a CME setup, you need to be very careful. An example of the test command:

test translation-rule 1 01234555321


Don’t assume that just because there is no output from the test, that nothing has been matched. If there are no matches across any of your rules, you will see:

01234555321 Didn't match with any of rules


If there’s no output, then you have a partial match. If you issue ‘debug voice translation’, and watch carefully, you will see output such as this:

Router(cfg-translation-rule)#do test voice translation-rule 1 0123
Router(cfg-translation-rule)#
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=1
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=2
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=3
//-1/xxxxxxxxxxxx/RXRULE/regxrule_match: more digits needed; number=0123 rule precedence=4
//-1/xxxxxxxxxxxx/RXRULE/regxrule_rule_match: partial match found, partial_match 4


There is a problem with this: if your translation rules are mistakenly waiting for any number (as mine was this morning; I’d left a .* on the beginning of the expression!), then your calling will exhibit some odd behaviour.

For instance, when dialling extensions from one ephone to another (simply across CME) your call will be subject to the ‘timeout interdigit’ value (as set in telephony-service). Why? Well, if your translation rules pick up a partial match they wait for a predefined length of time to see if you dial any other digits. The time waited is predefined by the interdigit timeout!

Even if the number matches the correct dial-peer (eg. 20001, 20002) and eventually dials correctly, you will still be subjected to the interdigit timeout, despite the lack of any ‘T’ in your destination-patterns. This is purely because the translation rules are waiting on your dial pattern.

Just thought I’d mention it. Really confused me this morning – many thanks to Tele for helping out!