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)
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.
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.is...
however uncertain if my lack of proxied media would be a factor.
--fred
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?
On 08/13/2015 02:42 PM, Alex Balashov wrote:
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?
Here's an example exported from the pcap. This example has topology hiding enabled with an address of 127.0.0.8.
--fred
I see a dialog established followed by a reinvite. Which frame # do you take to be the "on-hold invite"?
On 08/13/2015 03:40 PM, Fred Posner wrote:
On 08/13/2015 03:30 PM, Alex Balashov wrote:
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.
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
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
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....
-
Alex Balashov -
Daniel Tryba -
Fred Posner