[SIPForum-techwg] Quetionabouthow registrationmode works-MWI....
David Hancock
D.Hancock at CableLabs.com
Wed Feb 11 19:28:07 EST 2009
What means "hybrid", in this context?
________________________________
From: Francois Audet [mailto:audet at nortel.com]
Sent: Wednesday, February 11, 2009 12:39 PM
To: David Hancock; Jack Burton @ Cablevision; techwg at sipforum.org
Subject: RE: [SIPForum-techwg] Quetionabouthow registrationmode
works-MWI....
Interesing hybrid...
________________________________
From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of David Hancock
Sent: Wednesday, February 11, 2009 11:23
To: Jack Burton @ Cablevision; techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Quetionabouthow registrationmode
works-MWI....
Francois - the answer to your questions yes, single register /
multiple subscribes is how this would work, at least for the
,PacketCable case.
David
________________________________
From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Jack Burton
Sent: Wednesday, February 11, 2009 11:40 AM
To: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Quetion abouthow registrationmode
works-MWI....
I do not know for certain - never traced it. I believe that
there is a SUBSCRIBE / NOTIFY for each mailbox. Mailboxes can be
individual (per user) or shared (one per enterprise or department, with
MWI seen on many phone devices). In other words, it works similar to
hosted voice mail on a hosted IP phone system (IP Centrex).
Registration is not involved, as far as I know, in the current
hosted MWI implementation.
-Jack
>>> "Francois Audet" <audet at nortel.com> 2/11/2009 11:05 >>>
And they have each user subscribing individually to MWI with SP,
but do NOT register individually???
________________________________
From: techwg-bounces at sipforum.org
[mailto:techwg-bounces at sipforum.org] On Behalf Of Jack Burton
Sent: Wednesday, February 11, 2009 09:53
To: techwg at sipforum.org
Subject: Re: [SIPForum-techwg] Quetion about how
registrationmode works-MWI....
Francois,
We currently have PBXs in our network that use SP-based
voicemail. Believe it or not.
SP Voicemail is important in low-end situations where a
customer does not wish to run their own system, and has the advantage of
being able to collect messages even when the connection to the customer
is down, or their PBX is down.
-Jack
>>> "Francois Audet" <audet at nortel.com> 2/11/2009 10:40
>>>
The more I think about this MWI thing, the more I think
it should be
out of scope.
I have a hard time believing that PBXs will use SP-based
voicemail
instead of PBX-based voicemail.
Even if they do, I'm extremelly sceptical it will be
based on individual
subscriptions.
> -----Original Message-----
> From: techwg-bounces at sipforum.org
> [mailto:techwg-bounces at sipforum.org] On Behalf Of
Bharrat, Shaun
> Sent: Wednesday, February 11, 2009 09:11
> To: techwg at sipforum.org
> Subject: Re: [SIPForum-techwg] Quetion about how
registration
> mode works -MWI....
>
> > I don't see how that would work. On the initial
subscribe, the
> > existing status needs to be reported. But the
existing
> status would be
> > for all the lines on the pbx. IIRC, the MWI format
doesn't
> allow for
> > reporting status for multiple AORs.
> > And if it did, it could lead to a very large NOTIFY
message.
> >
> > > Uh, if the Contact in the SUBSCRIBE was
> sip:customer626 at 1.2.3.4, it
> > > seems like the RURI of the NOTIFY is going to have
> > > customer626 at 1.2.3.4. Am I missing this?
> > >
> > >>
> > >> Somebody made a point about wanting the VM
accounts to use
> > explicit
> > >> registration. I think we should look into this.
> >
> > I agree based on my comment above.
>
> Draft v04 has text that clarifies that MWI is on a
per-line
> basis. Every line (with MWI) subscribes and gets
notified
> independently.
>
> (I have concerns about scalability but that was
dismissed as
> a non-issue
>
> since large PBXes would be more likely to do voicemail
> locally rather than in the SP)
>
> 14.2Message Waiting Indicator
>
> ....
>
> The subscription and notification is on a per-line
basis, not
> on a per SIP-PBX basis. Consequently, the SIP-PBX MUST
> separately subscribe each line requiring hosted
voicemail.
> The Request-URI and the To header of the subscription
MUST
> contain the URI of the hosted voicemail application.
The From
> header MUST contain the AOR of the specific line
requiring voicemail.
>
> If the SIP-PBX is using registration mode, the
subscriptions
> for Message Waiting Indicator SHOULD NOT be initiated
until
> the registration of the main number has been
successfully completed.
>
> Cheers,
> Shaun
>
> > -----Original Message-----
> > From: techwg-bounces at sipforum.org
> > [mailto:techwg-bounces at sipforum.org] On Behalf Of
Paul Kyzivat
> > Sent: Wednesday, February 11, 2009 9:20 AM
> > To: Cullen Jennings
> > Cc: techwg at sipforum.org
> > Subject: Re: [SIPForum-techwg] Quetion about how
registration mode
> > works
> >
> > I can't stop myself from commenting (inline)
> >
> > Thanks,
> > Paul
> >
> > Cullen Jennings wrote:
> > > On Feb 10, 2009, at 9:32 PM, Francois Audet wrote:
> > >
> > >> I think you got it right. See minor
clarifications below.
> > >>
> > >>
> > >> On Feb10 2009 18:35 , "Cullen JENNINGS"
<fluffy at cisco.com> wrote:
> > >>
> > >>> Francois - many thanks for long reply. I was
totally
> confused but
> > >> I'm
> > >>> glad about that because the way I thought it
worked
> sounded broken
> > >> in
> > >>> many ways. You explanation seems like a system
with way less
> > >> problems.
> > >>> So let me run down a second use case and see if
I can get
> > it right.
> > >>>
> > >>> Fluffy's hair salon is in a multi tenant
building that provides
> > >> public
> > >>> IP address over DHCP to all the tenants. They
get phone
> > servers from
> > >>> ATT. The specification only support phones
numbers
> > nothing else. FHS
> > >>> phones up ATT and asks for 50 phone numbers and
gets told
> > , you are
> > >>> customer626 and your password is secret and your
outbound
> > proxy is
> > >>> proxyWest.att.com, you domain is att.com and you
have
> > >> +1-408-555-1000
> > >>> to +1-408-555-1050 and your main number is the
1000.
> > >> There is no need to have a "main number". It
doesn't
> translate to
> > >> anything at the SIP level. It's possible that
such a
> concept will
> > >> exist, but it is immaterial.
> > > got it
> > >
> > >>
> > >>> FHS provisions this in their PBX, configures it
to use
> > SIP over UDP,
> > >>> and it boots and gets a DHCP address of 1.2.3.4.
> > >>>
> > >>> After it boots it sends a registration over UDP
like with
> > >>>
> > >>> RURI of sip:proxyWest.att.com
> > >>> To and From of sip:customer626.att.com Contact
of
> sip:1.2.3.4 No
> > >>> route.
> > >> I would think the Contact would be
customer626 at 1.2.3.4, but it
> > >> probably
> > > ok - that contact makes more sense
> > >> doesn't really matter. It could matter in cases
where you have
> > >> multiple virtual PBXs using the same IP address.
> > >>
> > >> I haven't spent too much time thinking about the
route
> > header here.
> > >> I guess
> > >> if we thought we needed it, we could also include
it. Perhaps it
> > >> would be cleaner. Comments from anybody?
> > >>
> > >>> (As a side note, I've seen other proposal where
the
> register would
> > >> be
> > >>> more like
> > >>>
> > >>> RURI of sip:att.com
> > >>> To and From of
sip:+1-408-555-1000 at att.com;user=phone
> > >>> Contact of sip:1.2.3.4:5060
> > >>> Route of sip:proxyWest.att.com;lr
> > >>> )
> > >> Yeah, I've seen this too, but I think in the
interest of
> > >> interoperability and not mere documenting of all
possible
> > ways to do
> > >> things, we should stick with the first one you
listed.
> > > Yep agree having one approach is better than two
> >
> > I agree that one approach is better than two, but I
find
> the first one
> > strange (to register to the proxy rather than to
your), and
> the second
> > one entirely reasonable, so I prefer the 2nd.
> >
> > >>> Later when ATT gets a call to 408-555-1012, it
the
> invite the PBX
> > >>> receives has
> > >>>
> > >>> RURI of sip:+1-408-555-1013 at att.com;user=phone
> > >>>
> > >>> and no route header.
> > >> Correct. Again, nothing prevents the route header
to be
> > there if we
> > >> think it would be better.
> > >
> > > Uh, no, I don't think a route header would be
better hear.
> > I think it
> > > would make a ton of existing equipment fail. SO if
we don't
> > need it,
> > > don't do it.
> >
> > In this context I don't much care whether the route
header
> is there or
> > not. Nor should the pbx, as long as the route header
identifies it.
> > But specifying no route header here seems ok.
> >
> > >>> When the the 1007 line of the PBX calls
408-555-7000 the
> > INVITE from
> > >>> PBX to ATT would be over UDP and look like
> > >>>
> > >>> RURI of sip:+1-408-555-7000 at att.com;user=phone
> > >>> >From of sip:+1-408-555-1007 at att.com;user=phone
> > >>> To of sip:+1-408-555-7000 at att.com;user=phone
> > >>> Route of sip:proxyWest.att.com;lr
> > >>>
> > >>>
> > >>> All the request from the PBX would do Digest
with a username
> > >>> "customer626", realm of "att.com" and password
of "secret". I'm
> > >> still
> > >>> confused about nonce on overlapped transactions.
> > >> Can you clarify what you think the problem is
here?
> > >>
> > >>> To do MWI, the PBX would send a single SUBSCRIBE
with
> > >>>
> > >>> RURI of sip:proxyWest.att.com
> > >>> To and From of sip:customer626.att.com Contact
of sip:1.2.3.4
> > >> Yes. Comment about Contact earlier is still
valid.
> >
> > I find this very peculiar, both using the RURI of
the
> proxy, and the
> > to/from of customer626. It offends my sense of how
MWI is
> supposed to
> > work in sip. It *requires* that a single server
provide VM
> service for
> > all the lines on the pbx. While that will be a
normal
> deployment, it
> > might not be the only one.
> >
> > >>> And later when 408-555-1013 had new voicemail
the PBX would get
> > >> NOTIFY
> > >>> with things like
> > >>>
> > >>> RURI of sip:1.2.3.4
> > >>> To and From of sip:customer626.att.com and in
inside the
> > event body
> > >>> we would have
> > >>> Message-Account:
sip:+1-408-555-1013 at att.com;user=phone
> > >> I believe the RURI would be
> sip:+1-408-555-1013 at att.com;user=phone.
> >
> > I don't see how that would work. On the initial
subscribe, the
> > existing status needs to be reported. But the
existing
> status would be
> > for all the lines on the pbx. IIRC, the MWI format
doesn't
> allow for
> > reporting status for multiple AORs.
> > And if it did, it could lead to a very large NOTIFY
message.
> >
> > > Uh, if the Contact in the SUBSCRIBE was
> sip:customer626 at 1.2.3.4, it
> > > seems like the RURI of the NOTIFY is going to have
> > > customer626 at 1.2.3.4. Am I missing this?
> > >
> > >>
> > >> Somebody made a point about wanting the VM
accounts to use
> > explicit
> > >> registration. I think we should look into this.
> >
> > I agree based on my comment above.
> >
> > >> The reason in my mind for using the
pseudo-registration
> > mechanism for
> > >> VM is that it makes it a lot easier if the SP
voicemail is
> > a "legacy
> > >> VM"
> > >> system
> > >> behind a SIP Gateway (one that basically works
with phone
> > numbers and
> > >> redirection numbers).
> > >
> > > ok - so I'm still a little lost on the voice mail
part -
> I agree we
> > > want to be able to slap a GW in front of an VM
system and
> > have it work
> > >
> > >>
> > >> But it is true that if a real bona fides native
SIP, perhaps
> > >> registration would help. But then we get into a
weird grey zone
> > >> where
> > "trunking"
> > >> is used
> > >> for basic calls (i.e., phone number based SIP
instead of
> > user-based
> > >> SIP), but for voicemail, it's native SIP.
> > >>
> > >> In the interest of simplicity, I wanted to use
> phone-number based
> > >> logic for both (since this is a Trunking spec,
not "real" SIP).
> > >>
> > >>> Is this closer to right? What do I have wrong?
Once again, many
> > >> thanks
> > >>> for the time on this one.
> > >> No probs. I think it helps to write it down. We
should
> be able to
> > >> make the spec clearer. Note of this is really
hard: it's
> > just a pain
> > >> if everybody does it a little bit differently.
> > >>
> > >> My suggestion (provided we get agreement) would
be to
> > write up some
> > >> examples in the spec, to make it clearer.
Spencer?
> > >
> > > Yep, and perhaps a pass though the doc to see
where it does
> > not line
> > > up with this.
> > >
> > >>
> > >
> > > _______________________________________________
> > > techwg mailing list
> > > Send mail to: techwg at sipforum.org
> > > Unsubscribe or edit options at:
> > > http://sipforum.org/mailman/listinfo/techwg
> > >
> > _______________________________________________
> > techwg mailing list
> > Send mail to: techwg at sipforum.org
> > Unsubscribe or edit options at:
> > http://sipforum.org/mailman/listinfo/techwg
> >
>
> _______________________________________________
> techwg mailing list
> Send mail to: techwg at sipforum.org
> Unsubscribe or edit options at:
> http://sipforum.org/mailman/listinfo/techwg
>
_______________________________________________
techwg mailing list
Send mail to: techwg at sipforum.org
Unsubscribe or edit options at:
http://sipforum.org/mailman/listinfo/techwg
________________________________
The information transmitted in this email and any of its
attachments is intended only for the person or entity to which it is
addressed and may contain Cablevision proprietary information, which is
privileged, confidential, or subject to copyright belonging to
Cablevision. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited and may be
unlawful. If you received this in error, please contact the sender
immediately and delete and destroy the communication and all of the
attachments you have received and all copies thereof.
________________________________
________________________________
The information transmitted in this email and any of its
attachments is intended only for the person or entity to which it is
addressed and may contain Cablevision proprietary information, which is
privileged, confidential, or subject to copyright belonging to
Cablevision. Any review, retransmission, dissemination or other use of,
or taking of any action in reliance upon, this information by persons or
entities other than the intended recipient is prohibited and may be
unlawful. If you received this in error, please contact the sender
immediately and delete and destroy the communication and all of the
attachments you have received and all copies thereof.
________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://sipforum.org/pipermail/techwg/attachments/20090211/4ab6e843/attachment-0001.html
More information about the techwg
mailing list