Unable to do transit calls in SIP Trunk

[mohd]

Hi Folks,My office installed Netwanta 7100 with Polycom IP 335 phones.

My Desk phone is IP 335. Extension no is 348. My desk phone  set call forward to my Hand phone no(9828xxxx). When i call in my office another extension number(347) to my extension no its call forward to

my mobile number. it was ringing. But I call outside number to my Desk number its not call forwarding. it seemed  sip trunk does not allow this kind of transit calls, and will terminate it with a busy tone.

My Service provider confirmed  enabled call forward features in their system. Please advise

Below is the debug logs:

12:06:29.935 SB.CCM  :  Call Struct 0x434a410 :   Call-ID = 414

12:06:29.935 SB.CCM  :  Org Acct = T03    Dst Acct = 348

12:06:29.935 SB.CCM  :  Org Port ID = 0/0.128   Dst Port ID = 0/0.0

12:06:29.935 SB.CCM  :  Org TID =    Dst TID = SipPhoneManager

12:06:29.935 SB.CCM  :  RTP Channel = 0/1.1

12:06:29.936 SB.CCM release: Call Connection Type is RTP_TO_RTP

12:06:29.936 SB.CCM release: Releasing RTP Channel 0/1.1

12:06:29.936 SB.CALL 414 CallIdlePending      ClearResponse sent from T03 to 348

12:06:29.936 SB.CALL 415 Idle                 Called the call routine with 99828xxxx

12:06:29 SB.TGMgr Testing Trunk Access List SVI

12:06:29 SB.TGMgr Testing Trunk Access List TENANT1

12:06:29 SB.TGMgr Testing Trunk Access List TENANT2

12:06:29 SB.TGMgr Testing Trunk Access List TENANT3

12:06:29 SB.TGMgr Trunk lists configured in TrunkGroup SIP_GROUPED_TRUNK deny SABR Routing

12:06:29.937 SB.CALL 415 Idle                 No LOCAL station matched dialed number (99828xxxx)

12:06:29.938 SB.CALL 415 Idle                 No TRUNK accepted dialed number (99828xxxx)

12:06:29.938 SB.CALL 415 Idle                 No routable destination found on call from (9776xxxx) to (99828xxxx)

12:06:29.938 SB.CALL 415 State change      >> Idle->CallIdlePending

12:06:29 SB.CallStructObserver 415 Created

12:06:29 SB.CallStructObserver 414 Finalized

12:06:29 SB.CallStructObserver 415 Finalized

[Anonymous]

mohd,

Thanks for posting this in the Support Community.  From the debug it appears your SABR rules on the SIP trunk are preventing the call from going out:

12:06:29 SB.TGMgr Trunk lists configured in TrunkGroup SIP_GROUPED_TRUNK deny SABR Routing

I know you mentioned this works for internal calls that get sent out with the call forward on the phone. Can you upload your configuration and the output from a debug voice verbose and debug sip stack messages to our FTP server with the instructions below so I can see what may be causing this?  If possible please put the debug and the configuration file inside a .zip.

Open Internet Explorer web browser on their PC
Type the following URL:  ftp://ftp.adtran.com

Press the Alt key, click View, and then click Open FTP Site in Windows Explorer

Double-click the "Incoming" folder
Drag and drop files from PC into the Internet Explorer window

Reply to this post with the exact filename used so we can retrieve the files

Thanks,

Matt

Message was edited by: matt - corrected debug message and description

[mohd]

Thanks Matt.  I’ve uploaded a copy of SIP stack and voice debug.  They are named  (unable to do transit calls in SIP Trunk.rar)  Any help you can provide is appreciated.  Thanks.

Note: When i capture the debugs that time tried internal and external call.

[Anonymous · Accepted solution]

mohd,

Thank you for supplying the requested files.  In your configuration the voice grouped-trunk has SABR applied, which restricts calls out the trunk to ANI or trunks specified in permit lists:

!

voice grouped-trunk SIP_GROUPED_TRUNK

  permit list SVI

  permit list TENANT1

  permit list TENANT2

  permit list TENANT3

  !deny all other trunks

  !deny all other ani

!

When an external call comes in, it is identified as being sourced from trunk the call came in on (T03 in this instance). When the call is routed back out from the call forward it will use T03 as its source instead of the ANI of the number it tried to call (348).  Since the source is T03 it does not match the permit lists you have defined and ends up getting rejected:

11:04:27 SB.TGMgr Testing Trunk Access List TENANT1

11:04:27 SB.TGMgr Testing Trunk Access List TENANT2

11:04:27 SB.TGMgr Testing Trunk Access List TENANT3

11:04:27 SB.TGMgr Trunk lists configured in TrunkGroup SIP_GROUPED_TRUNK deny SABR Routing

11:04:27.250 SB.CALL 70 Idle                 No LOCAL station matched dialed number (9828xxxx)

11:04:27.250 SB.CALL 70 Idle                 No TRUNK accepted dialed number (9828xxxx)

11:04:27.250 SB.CALL 70 Idle                 No routable destination found on call from (9776xxxx) to (9828xxxx)

Try adding this to the configuration to see if it resolves the issue:

!

voice trunk-list ALLOWED-TRUNKS

  trunk T03

!

!

voice grouped-trunk SIP_GROUPED_TRUNK

  permit list ALLOWED-TRUNKS

!

If calls coming in from the other trunks would match this call flow, they also would need to be added to the trunk-list.

Thanks,

Matt

[mohd]

Hi Matt,

Thanks for your reply. I follow above instruction still not works.Please advise.

I’ve uploaded a copy of SIP stack and voice debug.  They are named Unable to do transit calls in sip trunks(debug logs).

Thanks again.

[Anonymous]

In the new debug the call is allowed out from the recent configuration changes.  However, after the INVITE is sent out the SIP trunk the SIP provider is responding with a SIP/2.0 403 Forbidden error. I would suggest you supply them with the debug or recreate the issue while they are monitoring so they can explain why they are sending the 403 error.

Thanks,

Matt

[mohd]

Hi Matt,

Thanks for your advise.I send them the Debug logs. Below is the reply for my service provider.Please advise

9776xxxx call to 653157xxxx. And get 200 OK and the call route to one extension from Adtran.

9:12:44.705 SIP.STACK MSG         INVITE sip:5338@172.25.x.x:5060;transport=UDP;srtp=off SIP/2.0

09:12:44.706 SIP.STACK MSG         Via: SIP/2.0/UDP 202.79.x.x:5082;branch=z9hG4bKpmr5271088h03ngi60n0.1

09:12:44.706 SIP.STACK MSG         From: "9776xxxx" <sip:9776xxxx@c4-mgc.nexwave.com.sg>;tag=1N4ET51EWY30000E1D01005u01YP96I1SBNXMP

09:12:44.706 SIP.STACK MSG         To: <sip:653157xxxx@202.79.x.x>

09:12:44.706 SIP.STACK MSG         Call-ID: 9a2a15000317-519c1bcf-615c5355-330606e8-1e705e9@127.0.0.1-UASession-KugDT*IFwB

09:12:44.706 SIP.STACK MSG         CSeq: 1 INVITE

09:12:44.707 SIP.STACK MSG Max-Forwards: 68

09:12:44.707 SIP.STACK MSG         Supported: replaces,timer

09:12:44.707 SIP.STACK MSG         Allow: INVITE,ACK,CANCEL,BYE,INFO,REFER,PRACK,NOTIFY

09:12:44.707 SIP.STACK MSG         Contact: <sip:9776xxxx@202.79.x.x:5082;internal=4907684-1;transport=udp>

09:12:44.707 SIP.STACK MSG         Content-Length: 283

09:12:44.708 SIP.STACK MSG         Content-Type: application/sdp

09:12:44.708 SIP.STACK MSG         User-Agent: TELES.MGC

09:12:44.708 SIP.STACK MSG         Allow-Events: talk,hold,refer

09:12:44.708 SIP.STACK MSG         Accept: application/sdp

09:12:44.709 SIP.STACK MSG         X-IP-Info: 202.79.217.251

The call was route to extension 348 that forward to mobile.

09:12:59.087 SIP.STACK MSG         INVITE sip:348@10.10.20.33:5060 SIP/2.0

09:12:59.087 SIP.STACK MSG         From: "9776xxxx" <sip:9776xxxx@10.10.20.1:5060;transport=UDP>;tag=5e25de0-a0a0a01-13c4-205a0-7ff08109-205a0

09:12:59.088 SIP.STACK MSG         To: "User 1" <sip:348@10.10.20.1:5060>

09:12:59.088 SIP.STACK MSG         Call-ID: 5ebf250-a0a0a01-13c4-205a0-d5ce555-205a0@10.10.20.1

09:12:59.088 SIP.STACK MSG         CSeq: 1 INVITE

09:12:59.088 SIP.STACK MSG         Via: SIP/2.0/UDP 10.10.20.1:5060;branch=z9hG4bK-205a0-7e5fafd-784d70ba

09:12:59.088 SIP.STACK MSG Max-Forwards: 70

09:12:59.089 SIP.STACK MSG         Supported: 100rel,replaces

09:12:59.089 SIP.STACK MSG Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

09:12:59.089 SIP.STACK MSG         User-Agent: ADTRAN_NetVanta_7100/R10.7.0.E

09:12:59.089 SIP.STACK MSG         Contact: <sip:10.10.20.1:5060;transport=UDP>

09:12:59.090 SIP.STACK MSG         Content-Length: 0

Then the call forward to the mobile 9828xxxx.  It was routed as the domain name instead of our system IP address, so it was fail to send message to us.

It should send Invite message by using IP address.

Please check in the Adtran why it sends with domain name.

09:12:59.119 SIP.STACK MSG         INVITE sip:9828xxxx@domain.com:5082 SIP/2.0

09:12:59.119 SIP.STACK MSG         From: "9776xxxx" <sip:9776xxxx@domain.com:5082;transport=UDP>;tag=5e20c80-a0a0a01-13c4-205a0-240fb708-205a0

09:12:59.119 SIP.STACK MSG         To: <sip:9828xxxx@domain.com:5082>

09:12:59.119 SIP.STACK MSG         Call-ID: 5ebf468-a0a0a01-13c4-205a0-4040b2f0-205a0@domain.com

09:12:59.120 SIP.STACK MSG         CSeq: 1 INVITE

09:12:59.120 SIP.STACK MSG         Via: SIP/2.0/UDP 172.25.27.62:5060;branch=z9hG4bK-205a0-7e5fb1d-3765c127

09:12:59.120 SIP.STACK MSG         Alert-Info: <http://127.0.0.1/Bellcore-dr2>

09:12:59.120 SIP.STACK MSG         Max-Forwards: 70

09:12:59.121 SIP.STACK MSG         Supported: 100rel,replaces

09:12:59.121 SIP.STACK MSG         Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, PRACK, REFER, REGISTER

09:12:59.121 SIP.STACK MSG         User-Agent: ADTRAN_NetVanta_7100/R10.7.0.E

09:12:59.121 SIP.STACK MSG         Contact: <sip:9776xxxx@172.25.27.62:5060;transport=UDP>

09:12:59.121 SIP.STACK MSG         Content-Type: application/sdp

09:12:59.122 SIP.STACK MSG         Content-Length: 206

Message was edited by: matt - removed public IPs, hostnames, and phone numbers

[Anonymous]

Try adding grammar to host sip-server in the configuration of the SIP trunk to the provider:

!

voice trunk T03 type sip

  grammar to host sip-server

!

If that does not resolve the issue I will need to see an updated debug and configuration file.

Thanks,
Matt

[mohd]

Hi Matt,

After add the grammar to host sip-server my office all the numbers external call cant go through. I’ve uploaded a copy of SIP stack and voice debug.  They are named  (transit call debug logs) . Config file name (config transit calls .cfg)  Any help you can provide is appreciated.  Thanks.

[Anonymous]

The new debug still shows the provider sending a SIP/2.0 403 Forbidden error.  In an earlier debug you supplied "Unable to do transit calls in sip trunks(debug logs)" there is a call that goes through normally when sent to the domain instead of the IP.  If you search for "5ec0310-a0a0a01-13c4-205bc-14b4ac3d-205bc" in that log you should be able to find it.  I would recommend you contact the SIP provider and ask them why that call worked if the domain is the issue, as well as supply them the last debug again and ask for a reason why the 403 error is sent. Another question to ask them is if they have a problem with hold SDP being sent in the INVITE.

Thanks,

Matt

[taych]

Hi Matt,

I am Mohd's colleague. We are still waiting a reply from our service provider based on your last advice.

By the way, may i know the difference between the "internal calls that get sent out with the call forward on the phone" and the "transit call" as mentioned?

There is certainly a difference between them as both outbound calls resulted the former call type to pass through uneventfully while the transit call didn't.

This key difference may help our SIP service provider to troubleshoot more effectively. Pls advise.

[Anonymous]

taych,

The difference is the internal calls are identified with an ANI of the extension the call is placed from vs external calls, which are sourced from the trunk they come in on (T03 in this scenario).  SABR is used in this setup and was originally preventing the call from being routed back out the T03 SIP trunk to the provider.  After mohd added T03 to the trunk-list the call was allowed out but the SIP provider is rejecting the INVITE.  They will need to supply an explanation on why based on the information contained within the INVITE from our debug.

Thanks,

Matt

[Anonymous]

I went ahead and flagged the "Correct Answer" on this post to make it more visible and help other members of the community find solutions more easily.  If you have any further questions or still need assistance, we would be more than happy to continue working with you on this - just let us know in a reply.

Thanks,

Matt