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?
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
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
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
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
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.
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.
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
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
Jay,
That did the trick. Thanks for the help.
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..
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