×
INTELLIGENT WORK FORUMS
FOR COMPUTER PROFESSIONALS

Log In

Come Join Us!

Are you a
Computer / IT professional?
Join Tek-Tips Forums!
  • Talk With Other Members
  • Be Notified Of Responses
    To Your Posts
  • Keyword Search
  • One-Click Access To Your
    Favorite Forums
  • Automated Signatures
    On Your Posts
  • Best Of All, It's Free!

*Tek-Tips's functionality depends on members receiving e-mail. By joining you are opting in to receive e-mail.

Posting Guidelines

Promoting, selling, recruiting, coursework and thesis posting is forbidden.

Students Click Here

calls to a new DDI are rejected
2

calls to a new DDI are rejected

calls to a new DDI are rejected

(OP)
Hello:

In this scenario:

IPO v2 R7 I have a SIP trunk with 3 DDI.

In this configuration I have only one SIP URI . At the register field I have the first credential for register.

In the crredentials tab I have the first with username, auth name, password, time, and register.
For each DDI I have a credential with the DDI number as name, the auth name is the same as the first for rregister, the contactname is the ddinumber@sipproxy, the same password as the principal and NO register.
At incoming routes one for each DDI in "incoming number"
And it works.

Now I order an aditional DDI to the service provider. I add a new credential as the others changinng the number (ddi) in username and contact. Also a incoming route for it.

When I call to this DDI, I get the locution "the number does not exist". The carrier says that they receive a "reject" from our IP addr (the IPO).

In the monitor I get :

83573475mS SIP Tx: UDP 192.168.0.189:5060 -> 94.23.83.yyy:5060
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 94.23.83.yyy:5060;branch=z9hG4bK4eba1b06;rport
From: <sip:6339xxxx@94.23.xx.xxx>;tag=as0c08c342
To: <sip:93120yyyy@88.26.193.yy:14865>;tag=d6021df507ecbd95
Call-ID: 03ce05c109d9553776dd244b5aa537ad@94.23.83.yyy:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Length: 0

83573476mS Sip: 101.3376.1 -1 SIPTrunk Endpoint(f52c1cac) Present Call, no match (93120xxxx) from URI in To header or (93120xxxx) from request URI (are the same number)
83573477mS SIP Call Tx: 101
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 94.23.83.177:5060;branch=z9hG4bK4eba1b06;rport
From: <sip:6339xxxx@94.23.xx.xxx>;tag=as0c08c342
To: <sip:93120yyyy@88.26.193.yy:14865>;tag=d6021df507ecbd95
Call-ID: 03ce05c109d9553776dd244b5aa537ad@94.23.83.177:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Length: 0

83573478mS SIP Tx: UDP 192.168.0.189:5060 -> 94.23.83.yyy:5060
SIP/2.0 404 Not Found
Via: SIP/2.0/UDP 94.23.83.yyy:5060;branch=z9hG4bK4eba1b06;rport
From: <sip:6339xxxx@94.23.xx.xxx>;tag=as0c08c342
To: <sip:93120yyyy@88.26.193.yy:14865>;tag=d6021df507ecbd95
Call-ID: 03ce05c109d9553776dd244b5aa537ad@94.23.83.yyy:5060
CSeq: 102 INVITE
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, INFO, UPDATE
Supported: timer
Content-Length: 0

83573509mS SIP Rx: UDP 94.23.83.yyy:5060 -> 192.168.0.189:5060
ACK sip:93120xxxx@88.26.193.xx:14865 SIP/2.0
Via: SIP/2.0/UDP 94.23.83.yyy:5060;branch=z9hG4bK4eba1b06;rport
Max-Forwards: 70
From: <sip:63393xxxx@94.23.83.yyy>;tag=as0c08c342
To: <sip:93120yyyy@88.26.193.xx:14865>;tag=d6021df507ecbd95
Contact: <sip:63393xxxx@94.23.83.yyy:5060>
Call-ID: 03ce05c109d9553776dd244b5aa537ad@94.23.83.yyy:5060
CSeq: 102 ACK
Content-Length: 0

83573511mS SIP Call Rx: 101
ACK sip:93120yyyy@88.26.193.yy:14865 SIP/2.0
Via: SIP/2.0/UDP 94.23.83.yyy:5060;branch=z9hG4bK4eba1b06;rport
Max-Forwards: 70
FFrom: <sip:6339xxxx@94.23.xx.xxx>;tag=as0c08c342
To: <sip:93120yyyy@88.26.193.yy:14865>;tag=d6021df507ecbd95
Contact: <sip:63393xxxx@94.23.83.xx:5060>
Call-ID: 03ce05c109d9553776dd244b5aa537ad@94.23.83.yyy:5060
CSeq: 102 ACK
Content-Length: 0

83574424mS CMCallEvt: 101.3374.1 -1 SIPTrunk Endpoint: StateChange: END=X CMCSIdle->CMCSDelete
83574425mS CMCallEvt: 101.3374.1 -1 BaseEP: DELETE CMEndpoint f4f9abd0 TOTAL NOW=2 CALL_LIST=0
83574468mS CMCallEvt: 101.3375.1 -1 SIPTrunk Endpoint: StateChange: END=X CMCSIdle->CMCSDelete
83574469mS CMCallEvt: 101.3375.1 -1 BaseEP: DELETE CMEndpoint f5006c98 TOTAL NOW=1 CALL_LIST=0
83574511mS CMCallEvt: 101.3376.1 -1 SIPTrunk Endpoint: StateChange: END=X CMCSIdle->CMCSDelete
83574512mS CMCallEvt: 101.3376.1 -1 BaseEP: DELETE CMEndpoint f52c2e10 TOTAL NOW=0 CALL_LIST=0

**********

Is there any reason for that ?

Thanks in advanced

RE: calls to a new DDI are rejected

Do you have an incoming call route for the number? Or a generic ICR?

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

RE: calls to a new DDI are rejected

(OP)
An incoming route for this number . The destination is a digital extension, (not IP).
I also tested with a generic route. But no success

RE: calls to a new DDI are rejected

Under the call details tab on SIP trunk do you have an line entry an Auto for local Uri and auto for Contact?
if not try it.

RE: calls to a new DDI are rejected

(OP)
I have "internal data " ( sorry I translate from spanish) in both fields.

For the other 3 DDI (credentials) it works fine

RE: calls to a new DDI are rejected

Did you select the correct incomming call ID in the ICR? (default is 0, but could be different on your trunk)

RE: calls to a new DDI are rejected

(OP)
fially I solved the problem adding an URI for this DDI with no register,
It's not logical because others don't need.
Now it works but i don't understand why.

Thanks !!!

RE: calls to a new DDI are rejected

Star for posting the resolution!

Dermis and feline can be divorced by manifold methods.*
*(Disclaimer for all advise given)--'Version Dependent'

RE: calls to a new DDI are rejected

If you are using "use internal data" for incoming calls it routes based on the SIP tab for users/groups. You likely have the other 3 numbers entered in the SIP tab but not this new number. This really is not a good way to route calls and should be avoided. If you are want to use internal data for outgoing calls create a second SIP URI set to auto for incoming calls. Then it will use the incoming call route to route the call.

The truth is just an excuse for lack of imagination.

Red Flag This Post

Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework.

Red Flag Submitted

Thank you for helping keep Tek-Tips Forums free from inappropriate posts.
The Tek-Tips staff will check this out and take appropriate action.

Reply To This Thread

Posting in the Tek-Tips forums is a member-only feature.

Click Here to join Tek-Tips and talk with other members! Already a Member? Login

Close Box

Join Tek-Tips® Today!

Join your peers on the Internet's largest technical computer professional community.
It's easy to join and it's free.

Here's Why Members Love Tek-Tips Forums:

Register now while it's still free!

Already a member? Close this window and log in.

Join Us             Close