Re: [martini] DID Number Mobility and MARTINI

["Elwell, John" <[e-mail]>]

Dean,

It is certainly the case that Alice should be able to move location and have things "just work" without having to contact the service desk. Let's assume Alice's device normally registers with the PBX at site A, and that the PBX registers with the SSP to receive calls to Alice's E.164 number. Alice moves to site B, but Alice's device (the same one or a different one) still registers with the PBX at site A. If there are issues with being able to register with a PBX on site A from a LAN on site B, that is outside the scope of MARTINI work.

Of course, calls from the SSP to Alice, on arrival at PBX-A, if the preferred device at that time is on site B, need to be routed to that device on site B. How this is achieved might also be an issue, put presumably would be based on a path established at registration time. I think this is also outside the scope of MARTINI.

What Dean proposes is that we support the nomadic user by moving the registrar for Alice's AOR from PBX-A to PBX-B. This would be a much bigger problem that just telling the SSP that Alice's E.164 number is now served by PBX-B instead of PBX-A. You also need to arrange for calls from UAs within the PBXs concerned to go to PBX-B instead of PBX-A for handling. Also all Alice's preferences known to the registrar at PBX-A need to be moved to PBX-B (e.g., conditions for calls to be redirected to voicemail). Also, what if Alice still has other devices that stay on site A? How does it help by moving the registrar to PBX-B.

John

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Dean Willis
> Sent: 09 February 2010 15:51
> To: MARTINI
> Subject: [martini] DID Number Mobility and MARTINI
> 
> 
> One of my understanding of goals for corporate VoIP systems was the  
> ability to move a user from one PBX to another PBX without having to  
> pay a service provider MACD (move, add, change, delete) fee.
> 
> In fact, it was my demonstrating this very capability to MCI's chief  
> engineering officer back in  1999 that got the first SIP 
> project there  
> funded.
> 
> Let's talk through a use case:
> 
> Assume Alice is working today in our building at #901 
> I-street, which  
> has a PBX. Her DID number is routed to that PBX. Over lunch, her  
> office gets moved down the street to the lab at #400 I-Street.
> 
> Three cases might apply:
> 
> 1) Alice moves her phone and plugs it in and it "just works", 
> because  
> the phone dynamically registers with the new PBX, which then  
> dynamically registers with the SSP proxy for that DID number,  
> effectively moving the binding from #901's PBX to #400's PBX.
> 
> 2) Alice moves her phone to #400, waits until after lunch, 
> then calls  
> the phone support people, who manually reprovision her onto the #400  
> PBX. This PBX then re-registers with SSP, and her number starts  
> working again.
> 
> 3) Alice moves her pone to #400, and waits until after lunch to talk  
> to the phone support people, who reprovision her on the PBXes 
> and then  
> call the SSP support people to move her DID number from 
> #901's "trunk"  
> to 400's "trunk". Sometime, tomorrow, her phone line starts working  
> AND we get a $50 bill for the "change fee" from the SSP.
> 
> 
> Our original design goal favored #1, we might have accepted 
> #2, and #3  
> was what we were most aggressively trying to avoid.
> 
> 
> Yet my understanding of the consensus of MARTINI is that #3 is the  
> desired outcome. This is the difference, if I understand it, between  
> draft-gin's "()" proposal for implicit registration and the "XXXX"  
> proposal for explicit registration I made on-list.
> 
> Why are we pushing ourselves ten years backwards in operational  
> advances?
> 
> And what happens when Alice has a WiFi phone and moves back 
> and forth  
> from #901 to #400 several times a day? Does she just go without a  
> phone, or do we pay a $50 change fee each time?
> 
> 
> 
> --
> Dean
> 
> 
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini
>