[cisco-voip] SRST and Shared Lines

[Erick Bergquist]

Here is another quick idea (have not thought about it that much),

Change the DID number to go to a translation pattern, hunt pilot, etc
on Call Manager so the DID extension assigned to the phone.
Have that route the calls to the phones.

Now, when the phones fall back to SRST mode they register to the
router with whatever DN they have now, and you can use alias under
call-manager-fallback for the DID # and map them to different phone
DNs in fallback. May work a bit better, but depends on what you want
to do.

Something like below, if the DID were 1000 and the Phone DNs were 1111
and 1112.

call-manager-fallback
  no huntstop
  alias 1  1000  to 1111
  alias 2 1000 to 1112
  pickup 1000

The alias keyword has forward  and preference options on it to, so it
is flexible a little bit.

There are a few ways to handle this, but none is a perfect as others
have mentioned.
Also, if one of the DNs for the alias aren't in fallback (1111  and
1112) the 1000 DN alias won't be active.

On Jan 26, 2008 12:07 AM, Jonathan Charles <jonvoip at gmail.com> wrote:
> Just to go into too much detail...
>
> Your problem is that when the ephones register they create ephone-dn's
> for each line that the phone has and the default is a single line
> ephone-dn...
>
> So, you have two options:
>
> One, do what you have and live with it.
>
> Two, you CCME as your SRST box...
>
> So, here's how to configure it... first off set up SRST as you
> normally would (point the SRST reference to the ip source address in
> telephony-services), the phones will still try to register.
>
> Now, manually create ephone-dns for each line appearance, make sure
> you add Huntstop Channel and No Huntstop on each line (up to the last
> one) and give them preference numbers...
>
> Now, manually create each ephone with button assignments to overlay
> all of the ephone-dns for that line appearance...
>
> So, you have 10 instances of extension 4421. You create 10 ephone-dns
> with the preference command and on the ephone, add the following
> button command:
>
> button 1o1,2,3,4,5,6,7,8,9,10
>
> Then the call will ring all 10 phones... and any remaining phones that
> are idle after a few have picked up calls.
>
> Here is the sucky part, this is an administrative nightmare... if a
> phone dies, its MAC will need to be changed in CCME... and you will
> also need to do this for every phone you want to go into fallback.
>
> The upside is that if you are licensed for SRST, you already have a
> license for CCME...
>
>
>
> Jonathan
>
> On Jan 25, 2008 7:27 AM, STEVEN CASPER <SCASPER at mtb.com> wrote:
> >
> >
>
> > I have run into an interesting situation with SRST and just want to confirm
> > that it is working as designed and this is not a bug.
> >
> >  Under normal conditions I have a site that uses a shared PRI/DID line
> > across all telephones in a department as the primary line. During SRST
> > testing we have discovered that once a call is received on one phone this
> > line is inactive on all other phones. No call can be placed from the line
> > and an inbound call to it goes to the call-forward busy target. If I use the
> > dual line option a second call will ring in but only to the phone that is
> > active with the first call.
> >
> > It looks to me that shared lines are not supported using SRST?
> >
> >
> >
> >  Thanks!,
> >
> > Steve Casper
> > Voice Technologies
> > M&T Bank
> > (410) 347-6026
> >
> > ************************************
> >  This email may contain privileged and/or confidential information that is
> > intended solely for the use of the addressee. If you are not the intended
> > recipient or entity, you are strictly prohibited from disclosing, copying,
> > distributing or using any of the information contained in the transmission.
> > If you received this communication in error, please contact the sender
> > immediately and destroy the material in its entirety, whether electronic or
> > hard copy. This communication may contain nonpublic personal information
> > about consumers subject to the restrictions of the Gramm-Leach-Bliley Act
> > and the Sarbanes-Oxley Act. You may not directly or indirectly reuse or
> > disclose such information for any purpose other than to provide the services
> > for which you are receiving the information.
> >  There are risks associated with the use of electronic transmission. The
> > sender of this information does not control the method of transmittal or
> > service providers and assumes no duty or obligation for the security,
> > receipt, or third party interception of this transmission.
> >  ************************************
> >
>
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >
> >
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>