SIP trunks and Mid call handling on EHDU 1

[Billz66]

I have a hosted ( Virtual MCD running 5.0 SP1) and sip trunks from a Service provider that doesnt support KPML.
I also have a hosted MBG with sip trunk licenses.

For mid call dialling ( handoff transfer etc) on EHDU in PRG. Do I have to have a sip trunk provider thats upports kpml.
I am a bit confused with the documenatation as it sort of suggests that a MBG ac do some sort of translation.

Has anyone setup KPML with a sip trunk ?

 

[Mitel100]

If you have a SIP trunk provider that support KPML, then MBG is not required. MBG is only required if the provider does not support it.

__________________________

There is no 'I' in 'Team'
__________________________

 

[Billz66]

Ok thats what I have , I have a sip trunk provider that does not support kpml, they only support rfc2833 .

At the moment mid call features are not working via the sip trunks .
I am using the same programming ( cos System options etc) as I have on a system with ISDN trunks and mid call works on that.

What I want to know is , do i have to configure the mcd or MBG to allow the mid call features to work.
eg does the mcd and mbg require kpml username passwords or is the conversion transparent.

 

[DrDeee]

MCD - in your sip peer on mcd you tell it to use kpml
MBG will allow your mcd to suscribe to kpml by default.

 

[Billz66]

Can you be more specific?
On the sip peer for Key press events I have set this
Allow inc subscriptions for local monitoring yes
allow out subscriptions for remote digit monitoring yes
force out subscriptions for remote digit monitoring yes
request outbound proxy to handle out subscriptions yes
KPML Transport udp
KPML Port 5060

Do I have to change anything on the MBG ?

At the moment pressing any digits mid call on a PRG EHDU results in the DTMF being heard but nothing else.

 

[DrDeee]

We set
Allow incoming to NO
Allow outgoing to YES
Force to NO
Request Outbound proxy to YES
and UDP/5060

By default nothing is required on MBG

 

[Billz66]

Thanks drDeee thats got it working .2 stars for you

 

[Mitelpassion]

out of curiosity, do you have MBG configured as an outbound proxy?

 

[Billz66]

Yes We had to use MBG as Sip trunk Proxy to enable the mid call dialling to function.

 

[Billz66]

Ok , has anyone upgraded their MBG to version 7.1 and still have KPML working?
I upgraded ours to 7.1 and now the mid call dialling has stopped working.

If I never did anything I'd never done before , I'd never do anything.....

 

[DrDeee]

Just so happens I recently upgraded pbx and mbg to latest...
All EHDU functions still working including mid-call features.

 

[Billz66]

Bugger :-(

If I never did anything I'd never done before , I'd never do anything.....

 

[Billz66]

Any chance you can show the MBG Configuration/settings/Sip options and Sip trunk Settings
I have

SIP connector Enabled
PRACK support Enabled
Local streaming True
Send options keepalives Only behind NAT
Options interval 20
Gap register True
Set-side registration expiry time 240
ICP-side registration expiry time 900
Legacy SIP trunk connector support Disabled
Challenge methods (*)
register
subscribe
invite
Allowed URI names


And the Sip trunk Settings

I have

Name: Sip trunk
Remote trunk endpoint address: Sip server IP address
Remote trunk endpoint port: 5060
Options keepalives: Use Master
Options interval: 60
Remote RTP framesize (ms):20ms
Idle timeout (s): 3600
Re-invite filtering: Off
RTP address override:
Local streaming:
PRACK support: Use Master
Log verbosity: Use Master
Authentication username:
Authentication password:
Confirm authentication password:
Routing rule * MCD MCD


Everything else is functioning fine , just the KPML has stopped working and its driving me nuts trying to work out what has stopped it !

If I never did anything I'd never done before , I'd never do anything.....

 

[DrDeee]

Everthing looks ok in those config settings.

Keep in mind this is a subscription by the MCD. And requires the carrier to send DTMF by RFC2833.
Troubleshooting
1. make a call with key press.
2. grab a copy of tug.log from the MBG
3. you should see the subscription request and the key presses in the log
4. OR you can wireshark the MBG and analyze the packets.
tcpdump -i ethX -nnXSs 0 -w filename.pcap
where X in ethX is 0 or 1 depending on LAN or WAN to capture from.

 

[Billz66]

Ok , I set the mbg to do a packet trace and then grabbed it and the tuglogs.

I made an incoming call to a PRG , answered the call , handed it off to a mobile , answered it .
Then on the mobile I dialled all digits 1-9 *0#.

In the packet trace I can see RFC2833 RTP event Event ID DTMF 1(1) for all digits dialled.

In the tuglog for the same digit entry ( 1) I got this

2012-03-31 19:43:24.776101000 14 SS0.86: Rx Codec: RTP_CODEC_DTMF ,
PT: 101 ,
M: 1,
SeqNum: 3487,
TS: 1073175499,
SSRC: 1257205771,
rtpLen: 4 DTMF: Event: 1,
Duration: 280, Volume: 7, E: 0

So it looks like the digtits are getting to the MBG ?


If I never did anything I'd never done before , I'd never do anything.....

 

[DrDeee]

Do you also see the MCD subscribe to KPML?
"SipUA::Subscribe request: from=sip:ap@192.168.1.200"
(Should be right after the invite.)

Then during call you should see RX and TX of DTMF
Tx Codec: RTP_CODEC_DTMF , PT: 101 , M: 0, SeqNum: 162, TS: 25400, SSRC: 479491032, rtpLen: 4 DTMF: Event: 1,
(This is the one you have posted)


Followed by Notify to MCD
SipUA: TX >>> NOTIFY request requri=sip:ap@192.168.1.2000


The MBG is getting the DTMF correctly from the carrier.
Is the MCD requesting Subscription?

 

[vlevalois]

I'm having the same issue where I hear DTMF digits on the far end but no action taken by MCD.

I've enabled KPML as described as well. I don't even see the DTMF events in the tug logs:

2012-06-05 13:41:57.914750000 8 (23.30) SipUA: RX <<< PRACK (200) response from=sip:xxxxxxxxxx@xx.xx.xx.xx to=sip:xxxxxxxxxx@xx.xx.xx.xx:5060 callid=720bd342847f7bb4b190f90fd1260fd8-3343385@xx.xx.xx.xx cseq=503, peer addr=xx.xx.xx.xx:5060
2012-06-05 13:41:57.915162000 8
2012-06-05 13:41:57.915162000 8 (23.30) SipUA: RX <<< INVITE (200) response from=sip:xxxxxxxxxx@xx.xx.xx.xx to=sip:xxxxxxxxxx@xx.xx.xx.xx:5060 callid=720bd342847f7bb4b190f90fd1260fd8-3343385@xx.xx.xx.xx cseq=501, peer addr=xx.xx.xx.xx:5060
2012-06-05 13:41:57.915242000 8 DLG 168 DialogState: Early --> Confirmed_AwaitingACK
2012-06-05 13:41:57.915435000 17 DLG 167 DialogState: Early --> Confirmed_AwaitingACK
2012-06-05 13:41:57.915517000 17
2012-06-05 13:41:57.915517000 17 (23.30) SipUA: TX >>> INVITE (200) response from=sip:xxxxxxxxxx@xx.xx.xx.xx;isup-oli=0 to=sip:xxxxxxxxxx@xx.xx.xx.xx callid=720bd342847f7bb4b190f90fd1260fd8-3343385@xx.xx.xx.xx cseq=501, tx to=xx.xx.xx.xx:5060
2012-06-05 13:41:58.116355000 17
2012-06-05 13:41:58.116355000 17 (23.50) SipUA: RX <<< ACK request requri=sip:xxxxxxxxxx@xx.xx.xx.xx:5060;transport=UDP from=sip:xxxxxxxxxx@xx.xx.xx.xx;isup-oli=0 to=sip:xxxxxxxxxx@xx.xx.xx.xx callid=720bd342847f7bb4b190f90fd1260fd8-3343385@xx.xx.xx.xx cseq=501, peer addr=xx.xx.xx.xx:5060
2012-06-05 13:41:58.116406000 17 DLG 167 DialogState: Confirmed_AwaitingACK --> Confirmed
2012-06-05 13:41:58.116414000 17 DLG 167 SessionState: AnswerSent --> Completed
2012-06-05 13:41:58.116524000 8 DLG 168 DialogState: Confirmed_AwaitingACK --> Confirmed
2012-06-05 13:41:58.116533000 8 DLG 168 SessionState: AnswerReceived --> Completed
2012-06-05 13:41:58.116564000 8
2012-06-05 13:41:58.116564000 8 (23.50) SipUA: TX >>> ACK request requri=sip:xxxxxxxxxx@xx.xx.xx.xx:5060;transport=udp from=sip:xxxxxxxxxx@xx.xx.xx.xx to=sip:xxxxxxxxxx@xx.xx.xx.xx:5060 callid=720bd342847f7bb4b190f90fd1260fd8-3343385@xx.xx.xx.xx cseq=501, tx to=xx.xx.xx.xx:5060
2012-06-05 13:42:08.296018000 10
2012-06-05 13:42:08.296018000 10 (33.68) SipUA: RX <<< BYE request requri=sip:xxxxxxxxxx;tgrp=SIPProvider1;trunk-context=xxxxxxxxxx@xx.xx.xx.xx:5060;transport=UDP from=sip:xxxxxxxxxx@xx.xx.xx.xx to=sip:xxxxxxxxxx@xx.xx.xx.xx callid=2916893072-328711957 cseq=29664, peer addr=xx.xx.xx.xx:5060
2012-06-05 13:42:08.296141000 10
2012-06-05 13:42:08.296141000 10 (33.68) SipUA: TX >>> BYE (200) response from=sip:xxxxxxxxxx@xx.xx.xx.xx to=sip:xxxxxxxxxx@xx.xx.xx.xx callid=2916893072-328711957 cseq=29664, tx to=xx.xx.xx.xx:5060
2012-06-05 13:42:08.296260000 10 DLG 170 DialogState: Confirmed --> Terminated_ByeResponsePending
2012-06-05 13:42:08.296444000 10 DLG 170 DialogState: Terminated_ByeResponsePending --> Terminated