Problems with Inbound SIP trunk from a MetaSwitch

[Anonymous]

Setting up a SIP trunk from a MetaSwitch that includes 2 additional DID numbers.  The main number on the SIP trunk works fine, but the two additional DID will not connect to additional voice accounts.  From a "debug voice verbose" and a "debug sip stack messages invite" it appears that the invite is not being accepted:

SIP Trunk Config:

voice trunk T07 type sip

  description "Velocity"

  no reject-external

  sip-server primary adtran.vnetvoice.com

  registrar primary adtran.vnetvoice.com

  max-number-calls 3

  register 8146510925

  codec-list g711_first both

  authentication username "8146510925" password "........."

Invite:

15:12:21.828 SIP. MSG INVITE REQ RX anonymous 8146510926

INVITE sip:8146510925@64.8.57.21:5060;transport=UDP SIP/2.0

From: "Anonymous"<sip:anonymous@adtran.vnetvoice.com>;tag=66.211.254.180+1+5b7515c4+57993a83

To: <sip:8146510926@adtran.vnetvoice.com>

Call-ID: 0gQAAC8WAAACBAAALxYAAOX74rLtTeE4DuQWYnlXURZJ6H4S/S1VyMy+i8osgpUz@66.211.254.180

CSeq: 684079421 INVITE

Via: SIP/2.0/UDP 66.211.254.180:5060;branch=z9hG4bK+6ac65ac59a93c456a2d9932d944224911+sip+1+ab5c368c

Expires: 180

Call-Info: <sip:66.211.254.180:5060>;method="NOTIFY;Event=telephone-event;Duration=2000"

Supported: resource-priority

Supported: siprec

Supported: 100rel

Organization: Metaswitch Networks

Max-Forwards: 67

Alert-Info: <http://www.notused.com>#info=alert-internal

Accept: application/sdp, application/dtmf-relay

Contact: <sip:f2d1491729f1bf23fb7d2caa5df7a57f@66.211.254.180:5060>

Allow-Events: message-summary,refer,dialog,line-seize,presence,call-info,as-feature-event,calling-name

Content-Type: application/sdp

Content-Length: 199

v=0

o=- 48035111654102 48035111654102 IN IP4 66.211.254.180

s=-

c=IN IP4 66.211.254.180

t=0 0

m=audio 49986 RTP/AVP 0 18 101

a=rtpmap:101 telephone-event/8000

a=fmtp:18 annexb=no

a=ptime:20

15:12:21.835 SIP. MSG INVITE RSP TX anonymous 8146510926

SIP/2.0 100 Trying

From: "Anonymous"<sip:anonymous@adtran.vnetvoice.com>;tag=66.211.254.180+1+5b7515c4+57993a83

To: <sip:8146510926@adtran.vnetvoice.com>

Call-ID: 0gQAAC8WAAACBAAALxYAAOX74rLtTeE4DuQWYnlXURZJ6H4S/S1VyMy+i8osgpUz@66.211.254.180

CSeq: 684079421 INVITE

Via: SIP/2.0/UDP 66.211.254.180:5060;branch=z9hG4bK+6ac65ac59a93c456a2d9932d944224911+sip+1+ab5c368c

Contact: <sip:8146510925@64.8.57.21:5060;transport=UDP>

Supported: 100rel,replaces

Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

User-Agent: ADTRAN_NetVanta_7100/R11.4.3.E

Content-Length: 0

Voice Verbose:

15:09:07.075 PM.208 Ca:0 Sending Keep-alive: INFO

15:09:07.078 PM.208 Ca:0 call-leg transaction -> Request Sent

15:09:07.197 PM.208 Ca:0 SipPM_Connected      rcvd SIP call-leg response: 200 OK

15:09:07.197 PM.208 Ca:0 call-leg transaction -> Final Response Rcvd

15:09:07.197 PM.208 Ca:0 SipPM_Connected      Received keep-alive response: 200

15:09:07.198 PM.208 Ca:0 call-leg transaction -> Terminated

15:09:12.252 TM.T07 01 SipTM_Idle           rcvd SIP call-leg request: INVITE

15:09:12.253 TM.T07 01 SipTM_Idle           call-leg -> Offering

15:09:12.253 TM.T07 01 SipTM_Idle           State change      >> SipTM_Idle->SipTM_Trying

15:09:12.253 TM.T07 01 SipTM_Trying         SDP offer is not loopback request

15:09:12.254 TM.T07 01 SipTM_Trying         Processing From for Caller-ID.

15:09:12.254 TM.T07 01 SipTM_Trying         Caller ID is private due to 'anonymous' detected in header

15:09:12.254 TM.T07 01 SipTM_Trying         Caller ID Name   = "Anonymous"

15:09:12.254 TM.T07 01 SipTM_Trying         Caller ID Number = "anonymous"

15:09:12.255 TM.T07 01 SipTM_Trying         Caller ID is private

15:09:12.255 TM.T07 01 SipTM_Trying         info: unable to set redirect number(s) from INVITE

15:09:12.255 TM.T07 01 SipTM_Trying         sent: TA->InboundCall

15:09:12.256 TM.T07 01 Looking up source address for destination 66.211.254.180

15:09:12.256 TM.T07 01 call-leg (0x50ccd70) -> src: 64.8.57.21 : 5060  dst: 66.211.254.180 : 5060

15:09:12.258 TM.T07 01 SipTM_Trying         sent: 100 Trying

15:09:12.259 TA.T07 01 TAIdle               rcvd: inboundCall from TM

15:09:12.259 TA.T07 01 State change      >> TAIdle->TAInboundCall (TAS_Calling)

15:09:12.259 TA.T07 01 Failed - DID translation: no match for 8146510925, using 8146510925

15:09:12.259 TA.T07 01 TAIdle               sent: call to SB

15:09:12.260 TM.T07 01 SipTM_Trying         tachg -> TAInboundCall

15:09:12.260 TM.T07 01 SipTM_Trying         State change      >> SipTM_Trying->SipTM_Pending

15:09:12.260 SB.CALL 44974 Idle                 Called the call routine with 8146510925

15:09:12.261 SB.CALL 44974 Idle                 No LOCAL station matched dialed number (8146510925)

15:09:12.261 SB.CALL 44974 Idle                 No TRUNK accepted dialed number (8146510925)

15:09:12.261 SB.CALL 44974 Idle                 Translating alias: 8146510925 to 208

15:09:12.262 SB.CCM isMappable:

15:09:12.262 SB.CCM  :  Call Struct 0x496d810 :   Call-ID = 44974

15:09:12.262 SB.CCM  :  Org Acct = T07    Dst Acct = 208

15:09:12.262 SB.CCM  :  Org Port ID = SipTrunk 0/0.384   Dst Port ID = unknown 0/0

15:09:12.263 SB.CCM  :  SDP Transaction = CallID: 44974

15:09:12.263 SB.CCM  :  SDP Offer = 0x06152910, (66.211.254.180:49792)

15:09:12.263 SB.CCM isMappable: Call Connection Type is RTP_TO_RTP

15:09:12.263 SB.CCM handleRtpToRtp: Modifying SDP Offer

15:09:12.264 SB.CCM translateOffer: offer codec list: PCMU G729

15:09:12.265 SB.CCM translateOffer: revised offer codec list: PCMU G729

15:09:12.265 SB.CCM translateOffer: codec list after answerer: PCMU G729

15:09:12.266 SB.CCM translateOffer: DTMF signaling: answerer has no restrictions configured, passing offer(NTE 101) through

15:09:12.267 SB.CCM translateOffer: success

15:09:12.267 MEDIA.MANAGER Allocating media port.

15:09:12.268 MEDIA.MANAGER getSubstitutePort: No matching callIdMap entry found for call 44974

15:09:12.268 MEDIA.MANAGER Call ID map : Added new entry : call ID 44974 : session -44637792333386INIP466.211.254.180 : version 197

226058 : index 2064

15:09:12.268 MEDIA.MANAGER New media entry : type(0), callID(44974), sessionID(-44637792333386INIP466.211.254.180), original IP(66.

211.254.180) ports(49792-49793), substitute IP(::) ports(12064-12065), RtpChannel(NULL), connection(0x6158010), sdpOverride(0), me(

0x611a110). No RtpChannel

So basically what happens is that any of the inbound SIP calls on this trunk go to the voice account that the main number is tied to.

What am I missing?

[Anonymous]

James, that line likely doesn't have anything to do with this call scenario. According to the debug, the number that's being dialed is set as an alias for extension 208, so the INVITE is being accepted. Can you please reply with the configuration of the 7100 as well as the full output of "debug voice verbose" and "debug sip stack message" running at the same time for an inbound call to that number? Thanks

Jay

[Anonymous]

Jay,

Here are the config and debugs you requested.  As can be seen from the config, here are the DID mappings:

8146510925 ---> x208

8146510926 ---> x216

8146510927 ---> x128

When I dial each of the incoming numbers, they all are sent to x 208

[Anonymous]

James, I need to see "voice verbose" and "sip stack message" running at the same time, so I couldn't see the routing decisions the 7100 is actually making, but a sip identity is one of the lowest match criteria in terms of routing order. Please try adding the numbers to the users as DIDs and test again. If it doesn't work, please reply with updated debug and be sure to include both debugs running at the same time. Thanks

[Anonymous]

Jay,

The two debugs were captured at the same time, from different telnet sessions, and started within 5 seconds of each other.  I will change the config and let you know what happens.

[Anonymous]

The 8146510927 on x128 was changed to a DID:

voice user 128

  connect sip

  cos "normal_users"

  first-name "Adam"

  last-name "McClelland"

  password "*******"

  description "Adam McClelland"

  group-ring-call-waiting

  did "8146510927"

  coverage  vm 128

  coverage night vm 128

  coverage night vm 128

  coverage lunch vm 128

  coverage lunch vm 128

  coverage weekend vm 128

  coverage weekend vm 128

  sip-authentication password "*******"

  codec-list g711_first both

  email amcclelland@net-cloud.com

  no voicemail new-user

  voicemail auth-mode password

  voicemail cos normal_voicemail

  voicemail notify email attach-message pcm

  voicemail password "*******"

  voicemail notify schedule Sunday 12:00 am

    notify email primary

I have attached the debugs, but the results is the same...all calls to the 3 DID's all get routed to 208.  You will have to sift through the debugs as this is an active phone system and other calls were happening when I was doing my testing.

[Anonymous]

James, please capture the 2 debugs running in the same telnet session. You can issue them one after another and they'll both show up at the same time. Thanks

[Anonymous]

Jay,

Sorry about that.  Here is the debug.

[Anonymous · Accepted solution]

James, it appears that your provider is inserting the alternate DID into the "TO" field of the INVITE rather than the initial request, which is more common. Try adding "dial-string source to" to the trunk. Thanks

[Anonymous]

Jay,

That did the trick.  Thanks for the help.

[cbbteceri]

Any ideas as to now why our system (james and I work together) is also after a few (7-10 minutes) not allowing incoming callers to hear us anymore?

It's not dropping the call, just all the sudden callers can't hear us (although we can hear them).  Kind of like kids at home when we hear them but they seem to stop listening. . .  

James is on the road today, so I'm helping troubleshoot and our president/owner just asked me to start monitoring it and get it resolved asap..

[Anonymous]

Christopher, sudden audio loss like you're describing is going to require some more detailed troubleshooting than we can do via a forums ticket. I would suggest opening up a phone support ticket. Thanks

Jay