Thanks Bogden, The patch did work. No more bogus events from the same type of call. Im using 1.6.3 SVN 7291.
Sven On 1/18/11 9:33 AM, "Bogdan-Andrei Iancu" <[email protected]> wrote: > Hi Sven, > > The message generating the log is: > > NOTIFY sip:10.1.2.52:5060 SIP/2.0 > Via: SIP/2.0/UDP 10.1.1.60:5060;branch=z9hG4bKFD1B90 > From: > <sip:[email protected]>;tag=38988880-C16 > To: > <sip:[email protected]>;tag=d5edda48-9c10-424c-b200-8ec1eb8e532c-42505206 > Call-ID: [email protected] > CSeq: 101 NOTIFY > Max-Forwards: 70 > Date: Fri, 14 Jan 2011 13:43:36 GMT > User-Agent: Cisco-SIPGateway/IOS-12.x > Event: kpml > Subscription-State: active > Route: <sip:10.1.1.82;lr=on;did=4a2.b78cc16> > Contact: <sip:[email protected]:5060> > Content-Length: 0 > > > a in-dialog NOTIFY in the early stage of the dialog. Searching for event > kpml, found this Event Package for Key Press Stimulus > (http://tools.ietf.org/html/draft-ietf-sipping-kpml-07). > > > I made a small patch that should fix the message - could you please test > it to see if it works? > > Thanks and regards, > Bogdan > > > Sven Schulz wrote: >> Bogdan, I hope this capture gets formatted correctly when I paste it in. >> Apparently Cisco uses NOTIFY to negotiate DTMF-relay. Inside the initial >> INVITE is a "Allow-Events: kpml" which the receiving gateway interprets this >> as an out-of-band dtmf capability. Then immediately after the 183, you can >> see the NOTIFY coming from the gateway. What you don't see here in this >> capture is that once the call is setup and dialog occurs, DTMF tones are >> then sent as NOTIFY packets. >> >> Sven >> _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
