05-09-2008 05:16 AM - edited 03-17-2019 09:22 PM
Hi is there possibility to configure CCME to read TO filed in SIP INVITE message and according to that route call to internal DN.
05-09-2008 08:18 AM
Yes, it will route to internal DN according to called number.
Hope this helps, please rate post if it does!
05-09-2008 09:55 AM
I wish that this is simple as that :).
Let me explain issue in detail:
I conected CCME to SIP provider. SIP provider gave me 10 DID numbers and I need to register only one number to provider (I must do no reg to all extensions except one that provider declared as main number). Provider route every call to me ad SIP INVITE to main number and in TO field provider puts real internal DN.
So is there possibility in CCME to somehow read and route call internalz based on TO filed that is different than INVITE
05-09-2008 10:03 AM
Yes. Check which header fields are supported:
http://www.cisco.com/en/US/docs/ios/12_3/sip/configuration/guide/chapter2.html#wp1281325
Hope this helps, please rate post if it does!
05-09-2008 11:22 AM
Ok I got message something like this:
1w0d:SIP Msg:ccsipDisplayMsg:Received:
INVITE sip:9998880@100.100.100.100:5060 SIP/2.0
Record-Route:<9998880>9998880>
Via:SIP/2.0/UDP 100.100.100.100:5060;branch=5,SIP/2.0/UDP
100.100.100.200:5060;branch=z9hG4bK1D38
From:<1234567>;tag=3DD33DE4-10DF1234567>
To:<9998881>9998881>
Date:Mon, 08 Apr 2002 16:58:08 GMT
Call-ID:A2B205CC-4A4811D6-8010A410-F242231D@100.100.100.200
Supported:timer
So as you can see
INVITE sip:9998880@100.100.100.100
and
To:<9998881>9998881>
so 9998880 is master number and 9998881 is first one in serie.
Ofcourse I have IP Phone on CME with extension 9998881 but with no-reg.
By default this is not working.
05-09-2008 01:42 PM
Hi, I'm afraid that your ITSP is slightly violating RFC3261 in choosing this tecnique to deliver the called number. From the RFC, par 8.1.1.1
The initial Request-URI of the message SHOULD be set to the value of the URI in the To field.
Exceptions to this are then further discussed, but none cover setting request-uri different than To field.
05-09-2008 01:59 PM
Hi, I agree. But violating or not, other IP PBX vendors that support SIP can handle this.
So we (with Cisco CCME or IP2IPGW eq.) can't handle this until 12.5 IOS with SIP profiles support. Correct?
05-09-2008 02:34 PM
Hi, in the trace you sent the Contact header is absent. Again RFC:
The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog.
Then the date is off, but not a problem. Can you check which response is sent with "debug ccsip message" and "term mon" ?
05-09-2008 02:51 PM
That trace is not real. It was only to show that I get INVITE yyyyy@sip.something but TO is not yyyyy@sip.something but is is yyyyx@sip.somethig. So all protocol communication is correct. After ITSP sens this kind of message, CCMe always rings phone with main number registered and defined by ITSP, no matter whitch number I dialed from PSTN phone. But number that i dield is in TO field.
Other vendor SIP IP PBXs have something like SIP profiles and contexts so they can via regular expressions and config files modify SIP messages on the fly and have flexibility to operate this way. Only solution in this case is that I register all my internal DNs with ITSP. That concept is ok but I can not have more than one user/pass pair in sip-ua with CCME (there is no POTS peers because this is pure IP envinronment). So this concept also failes for Cisco and this ITSP interoperability :(
05-09-2008 03:32 PM
Hi, cisco has a lot more than regexp to handle SIP. You can reroute the call with a TCL/IVR script that accesses the header if you want. Check for example number2name.tcl at:
http://pbevila.fastmail.fm/public/
When the call comes in, script would fetch called number [this part is not in the script I wrote] and replace as dnis, then call the appropriate extension.
It should also be possible to configure dummy pots DP just for purpose of registration.
05-15-2009 08:13 AM
Any more progress on this? I just hit this road block with a UC520 deployment on a Broadvox SIP connection.
All invites are to the main number (registration only) while the From field is the differentiator for DID, but the UC520 is ignoring the From field and trying to route all calls to the main number.
05-15-2009 06:03 PM
I have the same issue with Broadvox. They said that if I have a static ip (which I do), then they can reconfigure the trunk from a "registration" trunk to a "static endpoint". I just got this answer today, so I probably won't see if it works until Monday or Tuesday.
I'll let you know if it works.
05-15-2009 06:11 PM
Yes, that will be the solution for this project as well...moving to a static IP.
Thanks for the reply.
05-18-2009 01:33 PM
This resolved my DID issue. But I do not hear ringback on outbound calls, nor do the callers hear the dtmf when pressed. Anyone with the same issue?
05-18-2009 05:26 PM
I don't hear DTMF from my office phone/CME (different SIP provider), but it still works just fine.
I haven't experienced the ringback issue yet, but will watch for it during this Broadvox install later this week.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide