cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1220
Views
0
Helpful
14
Replies

DID on SIP trunk

jerko.susko
Level 1
Level 1

Hi is there possibility to configure CCME to read TO filed in SIP INVITE message and according to that route call to internal DN.

14 Replies 14

paolo bevilacqua
Hall of Fame
Hall of Fame

Yes, it will route to internal DN according to called number.

Hope this helps, please rate post if it does!

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

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!

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>

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-10DF

To:<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>

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.

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.

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?

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" ?

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 :(

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.

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.

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.

Yes, that will be the solution for this project as well...moving to a static IP.

Thanks for the reply.

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?

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: