RE: INFO

Inline...

> -----Original Message-----
> From: Eric Burger [mailto:eburgerbea.com]
> Sent: Friday, September 07, 2007 5:00 PM
> 
> Consider a PSTN call.  The call goes from the gateway
to softswitch /
> Proxy.  Proxy routes to VM App Server.  INFO has to
pass through
> softswitch / Proxy.  In KPML-land, VM App Server
*directly* subscribes
> to UAC key press state, bypassing the softswitch.  KPML
and INFO have
> the same number of messages for a SINGLE digit; KPML
wins hands-down for
> multiple digits or reports.

Not exactly - for a single digit, KPML would generate a
Subscribe/200/Notify/200 before the single DTMF was even
pressed - before
the actual Notify with the digits in it.  And of course
there is now also a
subscribe dialog involved.  Assuming a one-shot single digit
type, then,
we're talking 6 SIP messages for KPML vs. 2 for Info.  


> More importantly, let's take a Call Management (CM)
application that
> calls a VM application when they cannot find the
subscriber.  INFO has
> to pass through the softswitch / Proxy to the CM
application.  Cool - it
> is a proxy, so it knows to relay.  But OOPS!  The CM
application has to
> proxy the INFOs to the VM application.  Yes - you could
be a good
> programmer and remember to do that EVERYWHERE you place
an outbound
> call, but it is really easy to get wrong.  

I'm not sure I understand the scenario.  The VM learned
about this call how?
By being in the signaling path, no?  So why wouldn't the CM
forward INFO
along the path? (I mean it is in the same dialog, after all)
 Now I don't
doubt it could screw that up, and eat the info thinking it
was for itself,
but lots of things can get screwed up - my guess is KPML
will not be
impervious to screw ups.


> In KPML-land, the VM
> application server not only *directly* subscribes to
the UAC key press
> state, but it will NOT get the key presses (like the
ubiquitous long-#)
> that are for the CM application.  Likewise, the CM
application, which is
> ONLY looking for long-#, won't get all of the VM key
presses.  That
> scenario is where KPML really kicks-butt.

The VM will probably NOT *directly* subscribe to the UAC. 
It will need to
go through the UAC's outbound proxy.  And if the VM is
outside the UAC's
enterprise or service provider domain, my guess is the VM
will need to go
through some other boxes too.  A stand-alone UAC has
virtually no way to
verify the identity of a subscribing VM, so I hope they
don't just accept
direct subscriptions.

Also, this only works if the UAC supports multiple KPML
subscribes, right?
Which were only optional in the spec, no?

 
> By the way, I am deliberately using the provocative
"softswitch" term
> 

Well, I'm not sure how the "softswitch" term makes
a difference - I would
think a "softswitch" would need to be in the path
for all signaling, and
will not be bypassed even by KPML.  But then
"softswitch" is an ambiguous
term.  

-hadriel




_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Hi, 

>>Consider a PSTN call.  The call goes from the
gateway to softswitch / 
>>Proxy.  Proxy routes to VM App Server.  INFO has to
pass through 
>>softswitch / Proxy. 
>>In KPML-land, VM App Server *directly* subscribes to
UAC key press
state, bypassing the softswitch.

[Christer] As I've said before, there are environments where
some
proxies must (for whatever reason) be passed through. I
guess an
outbound proxy is a good example.

>>KPML and INFO have the same number of messages for a
SINGLE digit;
KPML wins 
>>hands-down for multiple digits or reports.
> 
>Not exactly - for a single digit, KPML would generate a

>Subscribe/200/Notify/200 before the single DTMF was even

>pressed - before the actual Notify with the digits in
it.  
>And of course there is now also a subscribe dialog
involved.  
>Assuming a one-shot single digit type, then, we're
talking 6 
>SIP messages for KPML vs. 2 for Info.  

[Christer] And, in cases where you need to send DTMFs (or
whatever
information) in both directions you actually need 2
subscription dialogs
- one in each direction, and maintaining dialog state also
consumes
resources. And, in some cases you may not even know whether
you will
ever have to use the dialog.


>>More importantly, let's take a Call Management (CM)
application that 
>>calls a VM application when they cannot find the
subscriber.  INFO has

>>to pass through the softswitch / Proxy to the CM
application.  Cool - 
>>it is a proxy, so it knows to relay.  But OOPS!  The
CM application 
>>has to proxy the INFOs to the VM application.  Yes -
you could be a 
>>good programmer and remember to do that EVERYWHERE
you place an 
>>outbound call, but it is really easy to get wrong.
> 
>I'm not sure I understand the scenario.  The VM learned
about 
>this call how?
>By being in the signaling path, no?  So why wouldn't the
CM 
>forward INFO along the path? (I mean it is in the same 
>dialog, after all)  Now I don't doubt it could screw
that up, 
>and eat the info thinking it was for itself, but lots of

>things can get screwed up - my guess is KPML will not be

>impervious to screw ups.

[Christer] I also have problems understanding the scenario.
INFO is
routed to wherever the INVITE that initiated the dialog was
routed...

Regards,

Christer


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip