13 Aug
2015
13 Aug
'15
9:29 p.m.
Hello all,
Always fun integrating with proprietary pbx's... is there a way that is
"generally accepted" as handling hold invites from devices such as Mitel
or Toshiba?
We're not proxying the media, so these devices are trying to send an
Invite to the endpoint when calls are placed on hold.
Fred Posner
The Palner Group, Inc.
http://www.palner.com (web)
+1-503-914-0999 (direct)
13 Aug
13 Aug
9:30 p.m.
I assume these are reinvites? If so, how would the strategy for handling them deviate from
handling of all other in-dialog requests?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
Sent from my BlackBerry.
9:34 p.m.
On 08/13/2015 02:30 PM, Alex Balashov wrote:
I assume these are reinvites? If so, how would the
strategy for
handling them deviate from handling of all other in-dialog requests?
-- Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
http://www.evaristesys.com/, http://www.csrpswitch.com/
Sadly, no. Straight up INVITE.
I was going to experiment with the is_audio_on_hold() function of textops...
http://www.kamailio.org/docs/modules/4.3.x/modules/textops.html#textops.f.i…
however uncertain if my lack of proxied media would be a factor.
--fred
9:42 p.m.
On 08/13/2015 02:34 PM, Fred Posner wrote:
Sadly, no. Straight up INVITE.
Wait, what? That doesn't make any sense. Can you provide a full
signalling capture?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
10:28 p.m.
On 08/13/2015 02:42 PM, Alex Balashov wrote:
On 08/13/2015 02:34 PM, Fred Posner wrote:
Here's an example exported from the pcap. This example has topology
hiding enabled with an address of 127.0.0.8.
--fred
Sadly, no. Straight up INVITE.
Wait, what? That doesn't make any sense. Can you provide a full
signalling capture?
10:30 p.m.
I see a dialog established followed by a reinvite. Which frame # do you
take to be the "on-hold invite"?
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
10:46 p.m.
On 08/13/2015 03:40 PM, Fred Posner wrote:
On 08/13/2015 03:30 PM, Alex Balashov wrote:
No, it's a reinvite. The distinguishing feature of an in-dialog request
(aka in-dialog invite aka reinvite) is the presence of a To-tag:
To: <sip:+1callerid-did@[PSTN-IPADDRESS]:5060>;tag=gK0e4a212a
The Route headers also give it away:
Route:
<sip:[PUBLIC-KAMAILIO];lr;r2=on;ftag=gK0e4a212a;vst=AAAAABkJAw0IDQ4PAQF2AXIWFwYXGQEWHQc4OjUwNjA-;did=7.a51>
Route:
<sip:127.0.0.8;line=sr-XLSMq0lrx0hrq6lrx0lgX0dzPLkgP9dgTvDWTH2vZH1Se5CmxIuWqyTHF621E-R1E-uaZhRyxCSC-IDEEKR5xhRiZKF5F2SiD2RRKtWDiHD48SKyI.Q1fIwh8sEzemYWeIC*>
These are built from the Record-Routes in the initial INVITE transaction:
Record-Route:
<sip:[PUBLIC-KAMAILIO];r2=on;lr;ftag=gK0e4a212a;vst=AAAAABkJAw0IDQ4PAQF2AXIWFwYXGQEWHQc4OjUwNjA-;did=7.a51>
Record-Route:
<sip:127.0.0.8;line=sr-XLSMq0lrx0hrq6lrx0lgX0dzPLkgP9dgTvDWTH2vZH1Se5CmxIuWqyTHF621E-R1E-uaZhRyxCSC-IDEEKR5xhRiZKF5F2SiD2RRKtWDiHD48SKyI.Q1fIwh8sEzemYWeIC*>
It's definitely a reinvite.
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
I see a dialog established followed by a
reinvite. Which frame # do you
take to be the "on-hold invite"?
I was taking frame 8 as a new invite. I'll see what I'm doing wrong.
10:48 p.m.
The more interesting question is why the reinvite is being rejected:
Status-Line: SIP/2.0 400 Bad Request
Message Header
Via: SIP/2.0/UDP
[PUBLIC-MITEL]:5060;received=[PUBLIC-MITEL];branch=z9hG4bK-d8754z-2648756d6bb46b65-1---d8754z-;rport=5060
From: <sip:pstn-did@[PUBLIC-MITEL]:5060>;tag=0_1970073968-102972850
To: <sip:+1callerid-did@[PSTN-IPADDRESS]:5060>;tag=gK0e4a212a
Call-ID: 1309573957_105226997@[PSTN-IPADDRESS]
CSeq: 747722615 INVITE
Error-Info: <sip:+1callerid-did@[PSTN-IPADDRESS]>;cause="[line
007] SIP syntax error"
Content-Length: 0
I don't see any bad syntax in that reinvite offhand, but it's entirely
possible that the UA in question doesn't like the 'topoh' droppings for
some reason. Can you disable topoh and see what happens?
-- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
303 Perimeter Center North, Suite 300
Atlanta, GA 30346
United States
Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
14 Aug
14 Aug
3:58 p.m.
On Thursday 13 August 2015 14:29:10 Fred Posner wrote:
Always fun integrating with proprietary pbx's...
is there a way that is
"generally accepted" as handling hold invites from devices such as Mitel
or Toshiba?
We're not proxying the media, so these devices are trying to send an
Invite to the endpoint when calls are placed on hold.
I feel your pain, I'm struggling with a similar problem. And in my case the
problem is Asstra/Mitel it they barf on a received param as quotedstring
(which is rfc3261 compliant) with a "400 Missing, Erroneous or Multiple
Contact header field(s)". Removing the quotes fixes this, but isn't rfc
compliant and thus failes on many other devices....
3390
days inactive
3391
days old
9 comments
3 participants
participants (3)
-
Alex Balashov -
Daniel Tryba -
Fred Posner