I've made the changes, and did the call (that unfortunately still fails). I cannot enter the last two debug commands you've given (deb dspfarm ...). In the attachments the updated config, 'sh ver' and calltrace.
The reason for the failure is there is no DID mapping setup after you removed the voice-class - can you please add the below:
dial-peer voice 3008 voip
incoming called-number 31107630000
no session target
default call fallback
voice translation-rule 1
rule 1 /^31107630000$/ /201/
rule 2 /^.*/ /201/
The right debugs are:
deb ccsip mess
deb voip ccapi inout
deb ephone mtp
deb sccp events
deb sccp message
I've updated the config (see included file: UC520_20091027_shrun.docx, UC520_20091027_shver.docx) and done some testing. The UC does react strange though.
- I've registered a phone with extension 201 (cisco 7970) that receives the call for 31107630000. The phone has a "CFwdAll" to extension 500 (the voicemail on CUE).
- I call with my mobile phone to the 31107630000 number (hoping to end up in the voicemail of course). Unfortunately, this does not happen.
- When you examine the callflow (see included file: UC520_20091027_debugforwarding, using the deb commands you suggested) you will see that the call is indeed forwarded. Also transcoding takes place.
- The most interesting part however is the external trace on our own platform:
- packet 6 shows the 180 RINGING coming from the UC520 (184.108.40.206).
- This 180 RINGING contains Require:100rel and RSeq fields, asking for a reliable response (according to RFC3262:4 UAC behaviour)
- The 180 RINGING traverses our SIP proxy/loadbalancer and gets answered by the PSTN gateway (a cisco router, .245).
- The router has to respond with a PRACK (RFC3262:3 UAS behaviour: "The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel."), which it does.
- The PRACK is sent to email@example.com (the 'internal voicemail number on the UC520), based on the contents of contact-field in the initial 180 RINGING.
- Our SIP platform receives the PRACK and replies with 404, because the number firstname.lastname@example.org does not make any sense..
- After that the session is cancelled in all directions.
My conclusion is that the UC520 asks for a provisional response but uses an 'internal' SIP uri on the external SIP trunk. This behaviour is incorrect (bug?).
Not sure if I would call this a bug - here are your options:
1. Disable PRACK request
voice service voip
2. Force Contact header to always be a specific number (need UC500 software pack 7.0.x or higher) - below is an example
voice class sip-profiles 1
response ANY sip-header Contact modify "<sip:(.*)@" "sip:14085551000@"
voice service voip
More info on SIP profiles is at:
Try the above and see if it works for you.