[reSIProcate] Cisco DTMF

[Matt Porter]

My goal really was to try to spur up and much conversation as possible
so we can hopefully get the DUM interface flexible enough to support
scenerios like ours.
im sure there are alot of us out there with our own private forks of the
DUM for reasons like this.
granted alot of these features are not standards, but defacto ones in
the sense that you have to admit cisco is a major player.
 
In my case, Im not suggesting directly adding the "sip-notify" dtmf
feature directly to the DUM, only having a DUM interface flexible enough
to support it without modifications to the core DUM stack.
 
Why not call the "onReadyToSend" method for responses?
Why not support implied subscriptions ( like the sip-notify dtmf ) in
the DUM?
 
Im sure there are many other scenerios and 3rd party extensions that
would benefit from this DUM flexibility
 
________________________________

From: Hong Yu [mailto:hyu at metreos.com] 
Sent: Sunday, April 16, 2006 12:03 PM
To: Matt Porter; resiprocate-devel at list.sipfoundry.org
Subject: RE: [reSIProcate] Cisco DTMF



I'm not sure what your setup is. When my client deals with Cisco
CallManager directly, I have to subscribe first for KPML event in order
to receive the notification from CallManager. I did have to modify DUM
to make subscribe/notify work though. The code base of DUM I have, which
is a couple of months old, didn't handle the incoming subscription
request of KPML event, if I recalled correctly.

 

Hong

 

________________________________

From: Matt Porter [mailto:mporter at calltower.com] 
Sent: Friday, April 14, 2006 2:37 PM
To: resiprocate-devel at list.sipfoundry.org
Subject: [reSIProcate] Cisco DTMF

 

In the past I have made some modifications to the DUM in order to
support dtmf using sip NOTIFY.  The changes were pretty straight forward
before, but now i am trying to sync up with the latest codebase, and
wanted to see if maybe someone out there had a better way to handle it.

 

just to quickly explain the way it works. When you receive an INVITE
from the gateway it will have a Call-Info header.

if your final 200 response to the invite contains that Call-Info then
NOTIFY will be used for DTMF instead of the rtp media stream.

 

So the stack has to be extended so you can receive unsoliticited NOTIFY
messages.

Im a little confused now where the best place to make this change is. it
used to be done in Dialog.cxx.. but the NOTIFY handling has changed
somewhat.

 

These were the 3 changes i had in the older codebase to support this (
probably a couple months old ).

 

void 
DialogUsage::send(SharedPtr<SipMessage> msg)
{
   //if (msg->isRequest())           <-----  !!!!  took this out,
because i need to add the "Call-Info" header !!!!
   {
      // give app an chance to adorn the message.
      onReadyToSend(*msg);
   }
   mDialog.send(msg);
}

 

class InviteSessionHandler
{

......existing code.............

 //!! Added this !!  (return 0, if you like the message)
 virtual int onUnsolicitedNotify(InviteSessionHandle,const SipMessage&
msg){ return -1; }

}

 

void 
Dialog::dispatch(const SipMessage& msg)

 

 

......existing code.............

 

  case NOTIFY:

 

   ......existing code.............

 

    //last chance to let the app decide if i likes this NOTIFY

  if( mDum.mInviteSessionHandler->onUnsolicitedNotify(
mInviteSession->getSessionHandle(), msg) != 0 )
  {
         SipMessage response;
         makeResponse(response, msg, 406);
        send(response);
  }

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060416/11d8abb7/attachment.htm>