calls to a new DDI are rejected 2

[AlfonsoSF]

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

 

[budbyrd]

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'

 

[AlfonsoSF]

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

 

[NYSTECH]

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.

 

[AlfonsoSF]

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

For the other 3 DDI (credentials) it works fine

 

[Okkie26]

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

 

[AlfonsoSF]

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 !!!

 

[budbyrd]

Star for posting the resolution!

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

 

[critchey]

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.