[OpenSIPS-Users] Dialog Module and Bogus Event 8 in state 2

[Sven Schulz]

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" <bogdan at opensips.org> 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:18148656116 at testsipcore.phonetest.psu.edu>;tag=38988880-C16
>         To: 
> <sip:8148636939 at 10.1.2.52>;tag=d5edda48-9c10-424c-b200-8ec1eb8e532c-42505206
>         Call-ID: f39a000-d30152a9-59-3402010a at 10.1.2.52
>         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:18148656116 at 10.1.1.60: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
>>