RE: [reSIProcate] Cisco DTMF

["Matt Porter" <mporter@xxxxxxxxxxxxx>]

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@xxxxxxxxxxx]
Sent: Sunday, April 16, 2006 12:03 PM
To: Matt Porter; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx]
Sent: Friday, April 14, 2006 2:37 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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);
  }