Trying to implement a hosted PBX solution using a Genband C15 softswitch and Polycom VVX400 phones. At the customer premise, we are planning to use a NetVanta 3140 as the SIP and data router, and a NetVanta 1531P as the PoE switch.
I have everything configured and working on our test bench except for SIP Forking/Shared Line Appearance. Here is my setup:
1. I have (3) Polycom VVX400 phones setup, each with their own unique primary DN assigned. All calls to and from these DN's work just fine.
2. I have a shared secondary DN assigned to all three phones. The binding for this line in the softswitch is set to 3, and all three phones have successfully registered this line and I can place calls from this line.
3. Problem is inbound calls. When I call this shared DN from another number, the assigned secondary DN rings on all three phones as I would expect, but when I go to pickup the call on one of the phones, the other two phones continue to ring. I can only silence or reject the call on those phones.
I have pasted in a copy my NV3140 config. I am hoping that someone has come across a similar issue and has found a workaround.
!
!
! ADTRAN, Inc. OS version R11.10.0.E
! Boot ROM version R11.5.0
! Platform: NetVanta 3140, part number 4700341F2
! Serial number CFG1438909
!
!
hostname "NV3140"
enable password md5 encrypted b3c68d161f1275d1dbdb066a621be135
!
!
clock timezone -6-Central-Time
!
ip subnet-zero
ip classless
ip routing
ipv6 unicast-routing
!
!
domain-proxy
domain-proxy failover
!
ip local policy route-map ProbeMap
!
no auto-config
!
event-history on
no logging forwarding
no logging email
!
no service password-encryption
!
username "********" password "*******"
!
!
ip firewall
ip firewall fast-nat-failover
ip firewall fast-allow-failover
no ip firewall alg msn
no ip firewall alg mszone
no ip firewall alg h323
!
!
!
!
!
!
!
!
!
no dot11ap access-point-control
!
!
!
probe PRIMARY_INTERNET icmp-echo
destination 8.8.8.8
period 3
tolerance consecutive fail 5 pass 5
no shutdown
!
track PRIMARY_TRACK
test if probe PRIMARY_INTERNET
no shutdown
!
!
!
!
ip dhcp excluded-address 192.168.2.1 192.168.2.10
ip dhcp excluded-address 192.168.1.1 192.168.1.10
!
ip dhcp pool "DATA"
network 192.168.1.0 255.255.255.0
dns-server 192.168.1.1
default-router 192.168.1.1
!
ip dhcp pool "VOICE"
network 192.168.2.0 255.255.255.0
dns-server 192.168.2.1
default-router 192.168.2.1
ntp-server 192.168.2.1
option 66 ip ********
option 160 ascii tftp://********
!
!
!
!
!
!
!
!
!
!
!
qos map VoIP 10
match dscp 46
priority 2000 strict-rate-limiting
!
!
!
!
interface gigabit-eth 0/1
encapsulation 802.1q
bandwidth 20000
traffic-shape rate 20000000
no shutdown
!
interface gigabit-eth 0/1.200
vlan-id 200
ip address dhcp track PRIMARY_TRACK
ip access-policy Public
no shutdown
interface gigabit-eth 0/1.3003
vlan-id 3003
ip address ********
ip access-policy VoIP
media-gateway ip primary
no shutdown
!
interface gigabit-eth 0/2
encapsulation 802.1q
no shutdown
!
interface gigabit-eth 0/2.1
vlan-id 1 native
ip address 192.168.1.1 255.255.255.0
ip access-policy DATA-LAN
no shutdown
interface gigabit-eth 0/2.2
vlan-id 2
ip address 192.168.2.1 255.255.255.0
ip access-policy VOICE-LAN
media-gateway ip primary
no shutdown
!
interface gigabit-eth 0/3
no ip address
shutdown
!
!
!
interface cellular 0/1
resource pool-member CELLULAR 1
no shutdown
!
interface demand 1 encapsulation hdlc
idle-timeout 600
resource pool CELLULAR
match-interesting ip list PermitAny out
match-interesting ip reverse list PermitAny in
connect-sequence 1 dial-string #777 forced-cellular
connect-sequence attempts 0
connect-sequence interface-recovery
connect-mode originate
description Cellular Demand Interface
ip address cellular
ip access-policy PublicCellular
no shutdown
!
!
route-map ProbeMap permit 10
match ip address ProbeTest
set interface gigabit-ethernet 0/1.200
!
!
!
!
ip access-list extended AdminAccess
permit tcp any any eq ssh
permit tcp any any eq https
!
ip access-list extended PermitAny
permit ip any any
!
ip access-list extended ProbeTest
permit icmp any host 8.8.8.8
!
ip access-list extended VoIP
permit udp 10.0.0.0 0.255.255.255 any eq 5060
!
!
!
!
ip policy-class DATA-LAN
allow list self self
nat source list PermitAny interface gigabit-ethernet 0/1.200 overload policy P
allow list self self
nat source list PermitAny interface gigabit-ethernet 0/1.200 overload policy Public
nat source list PermitAny interface demand 1 overload policy PublicCellular
!
ip policy-class Public
allow list AdminAccess self
!
ip policy-class PublicCellular
allow list AdminAccess self
!
ip policy-class VOICE-LAN
allow list self self
nat source list PermitAny interface gigabit-ethernet 0/1.3003 overload
!
ip policy-class VoIP
allow list VoIP
!
!
!
ip route 0.0.0.0 0.0.0.0 demand 1 10
ip route ********
ip route ********
!
no tftp server
no tftp server overwrite
http server
http secure-server
no snmp agent
no ip ftp server
no ip scp server
ip sntp server
!
!
!
!
!
!
!
!
sip
sip udp 5060
no sip tcp
!
!
!
voice feature-mode network
voice forward-mode network
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
sip proxy
sip proxy transparent
!
sip proxy domain "sip.ptcnet.net"
sip proxy duplicates-allowed
sip proxy grammar request-uri host domain
sip proxy grammar to host domain
sip proxy grammar from host domain
sip proxy grammar proxy-id contact-user
!
sip proxy sip-server primary ********
sip proxy sip-server secondary ********
sip proxy sip-server rollover service-unavailable-or-timeout
!
!
!
sip proxy failover accept-registrations
sip proxy failover match-digits 4
!
!
!
!
!
!
!
!
!
!
!
line con 0
no login
!
line telnet 0 4
login local-userlist
no shutdown
line ssh 0 4
login local-userlist
no shutdown
!
sntp server pool.ntp.org
!
!
!
!
end
If you dial the shared secondary number from outside and hang up (abandon the call) before answering any of the phones, do they all stop ringing immediately?
If you pick up one of the ringing phones after answering it on another, what do you get? Dead air? Bridged into call? Dial tone?
This sounds like an issue with the Genband. They should be sending a CANCEL and seeing a response of 487 Request Terminated on the remaining shared call appearances when the first one is answered. SIP debugs may help here.
If I call the shared line from an outside line (and do not answer any of the phones) the Polycom phones continue to ring for a period of time even after I hang up the phone from where I placed the call.
If I answer the call on one of the Polycom phones and then pick up one of the other phones that are ringing, the phone just continues to ring. I cannot pickup the ringing line. The only way I can stop the ringing is to hit "Silence" or "Reject" on the phone display.
I have attached some debugs that I captured and sent into support. I was told by the support agent I spoke with that he was not sure the NetVanta supported sip forking in a sip proxy environment and that engineering would have to take a look at it.
I did attach a printout of my sip proxy database and of some sip debugs if you would care to take a look. My three Polycom phones are x1234, x1235, and x8999. They all have a shared line of 1230, which is the line I'm having issues with.
The method you're trying to implement of handling shared call appearances in this scenario is different than I've seen and likely to give trouble. You have identical line appearances on three phones going through the Adtran device. The Genband will treat this as one endpoint and things won't work as you intended.
The usual way to do this is for each phone with a shared call appearance to register through the proxy with a unique username. The Genband will then handle the logic of which phone(s) to ring and when to stop. This is far more flexible as you can have sequential as well as simultaneous calling. Each shared call appearance would register uniquely, for example sca4023471230-1, sca4023471230-2 and sca4023471230-3 in your case. Each registration gets proxied separately. The Genband is programmed to ring them as as simultaneous hunt group. When any one answers, a CANCEL is sent to the others.
The problem with your setup that a SIP CANCEL is substantially different from a SIP BYE. The CANCEL is sent only on calls that aren't answered. Because the call *is* answered, when the CANCEL arrives the Adtran doesn't know how to handle it and rejects it with a 481 call leg does not exist and a 503 server error. Thus it never reaches the other phones. When you try to pick up, because the call is already answered, the media never gets negotiated and the phone keeps ringing. You can see the misbehavior of CANCEL handling in your log starting at timestamp11:17:45.319 .
Another possibility would be to treat the line appearances locally as a ring group by having the phones register to the Adtran directly with unique usernames instead of being proxied. Then treat the secondary DID as the pilot of the ring group. I haven't tried this. In any case you will need each shared line appearance to have a unique username.
Registering them as unique usernanes to the Genband and having the Genband treat them as a simul-ring hunt group is cleaner and more scalable in my opinion.
I follow what you are saying, but I'm not sure that the Genband C15 will allow me to do that. I can create three separate SIP lines w/ unique usernames as you've stated above, but the only way to assign those lines to my phones would be to make those lines appear as a MADN (Multi Appearance Directory Number). Using a MADN solves the ringing issue, however, once the line is in use by one phone, it is then restricted to that phone only. No other calls can be placed to or from a MADN line while an active call is taking place.
My hunt groups on the C15 also do not allow a simultaneous ring. I can only do a sequential, circular, or rotary ring pattern.
I'd address the issue with Genband. It's not an Adtran problem. Voice switch manufacturers have different names for similar features, but any reasonable switch should be able to give you the functionality you desire. Explain what you're trying to do and they should tell you their name for that feature and how to make it work.
I have a ticket open with support on this. This must be something that they want to address. They registered a few phones from their lab directly to my softswitch and must have verified an issue as I got a response saying that they are looking to resolve the issue in the next extended maintenance release, R11.10.6 which is scheduled for December.