[Freeswitch-users] Audio PBX rejects video stream, kills call

Sam Russell sam.h.russell at gmail.com
Mon Aug 5 07:16:18 MSD 2013


Hi guys,

I've been using FreeSWITCH for a couple of weeks and built a PBX and B2BUA
out of it. I've seen some interesting things that happen when PBXs get m=
headers that they don't like (such as Asterisk balking when it gets
multiple video streams), and I've seen one recently while calling an old
school PBX.

Here's my build:

Me(Linphone) -> PBX (FreeSWITCH) -> B2BUA (FreeSWITCH) -> Destination

The B2BUA uses proxy_media mode and doesn't have a problem, but the PBX
uses passthrough codecs (so it's reading the SDP packet) and sees a
problem, throwing a 500 error back to my softphone

The outbound packet from the PBX to the B2BUA:

send 1428 bytes to udp/[210.7.45.66]:5060 at 02:46:48.407768:
   ------------------------------------------------------------------------
   INVITE sip:+61269337555 at 210.7.45.66 SIP/2.0
   Via: SIP/2.0/UDP 210.7.46.240;rport;branch=z9hG4bKZrKQvvHNSy64m
   Max-Forwards: 69
   From: "Sam Russell" <sip:+6442820079 at 210.7.46.240>;tag=e722ggarBe7je
   To: <sip:+61269337555 at 210.7.45.66>
   Call-ID: 1d80cd44-781c-1231-8db7-0050568a49fc
   CSeq: 47499340 INVITE
   Contact: <sip:gw+sbc at 210.7.46.240:5060;transport=udp;gw=sbc>
   User-Agent: FreeSWITCH-mod_sofia/1.3.13b+git~20130223T185558Z~28680c5e58
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Allow-Events: talk, hold, conference, presence, dialog, line-seize,
call-info, sla, include-session-description, presence.winfo,
message-summary, refer
   Content-Type: application/sdp
   Content-Disposition: session
   Content-Length: 453
   X-FS-Support: update_display,send_info
   Remote-Party-ID: "Sam Russell" <sip:+6442820079 at 210.7.46.240
>;party=calling;screen=yes;privacy=off

   v=0
   o=FreeSWITCH 1375638308 1375638309 IN IP4 210.7.46.240
   s=FreeSWITCH
   c=IN IP4 210.7.46.240
   t=0 0
   m=audio 32500 RTP/AVP 98 99 100 0 8 101 13
   a=rtpmap:98 SPEEX/32000
   a=fmtp:98 vbr=on
   a=rtpmap:99 SPEEX/16000
   a=fmtp:99 vbr=on
   a=rtpmap:100 SPEEX/8000
   a=fmtp:100 vbr=on
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-16
   a=ptime:20
   m=video 29910 RTP/AVP 102 103
   a=rtpmap:102 H263-1998/90000
   a=fmtp:102 CIF=1;QCIF=1
   a=rtpmap:103 VP8/90000

The offending packet that it returns:

   ------------------------------------------------------------------------
recv 1357 bytes from udp/[210.7.45.66]:5060 at 02:46:48.739816:
   ------------------------------------------------------------------------
   SIP/2.0 200 OK
   Via: SIP/2.0/UDP 210.7.46.240;rport=5060;branch=z9hG4bKZrKQvvHNSy64m
   From: "Sam Russell" <sip:+6442820079 at 210.7.46.240>;tag=e722ggarBe7je
   To: <sip:+61269337555 at 210.7.45.66>;tag=teBFaBg5DjBHm
   Call-ID: 1d80cd44-781c-1231-8db7-0050568a49fc
   CSeq: 47499340 INVITE
   Contact: <sip:+61269337555 at 210.7.45.66:5060;transport=udp>
   User-Agent: FreeSWITCH-mod_sofia/1.2.11+git~20130723T222215Z~55b6b8424f
   Accept: application/sdp
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Allow-Events: talk, hold, conference, presence, dialog, line-seize,
call-info, sla, include-session-description, presence.winfo,
message-summary, refer
   Content-Type: application/sdp
   Content-Disposition: session
   Content-Length: 242
   X-FS-Display-Name: Outbound Call
   X-FS-Display-Number: sip:+61269337555 at 210.7.45.66
   x-inin-crn: 1101488375;loc=%3cRegionDefaultLocation%3e
   X-FS-Support: update_display,send_info
   Remote-Party-ID: "Outbound Call" <sip:+61269337555 at 210.7.45.66
>;party=calling;privacy=off;screen=no

   v=0
   o=FreeSWITCH 914114385 914114386 IN IP4 210.7.45.66
   s=FreeSWITCH
   c=IN IP4 210.7.45.66
   t=0 0
   m=audio 17704 RTP/AVP 8 101
   a=rtpmap:8 PCMA/8000
   a=rtpmap:101 telephone-event/8000
   a=fmtp:101 0-15
   m=video 0 RTP/AVP 96
   a=rtpmap:96 /0


The PBX then balks and sends a 500 error to my softphone

send 704 bytes to udp/[210.7.45.66]:5060 at 02:46:48.740796:
   ------------------------------------------------------------------------
   BYE sip:+61269337555 at 210.7.45.66:5060;transport=udp SIP/2.0
   Via: SIP/2.0/UDP 210.7.46.240;rport;branch=z9hG4bK1a68ZjKvKgKac
   Max-Forwards: 70
   From: "Sam Russell" <sip:+6442820079 at 210.7.46.240>;tag=e722ggarBe7je
   To: <sip:+61269337555 at 210.7.45.66>;tag=teBFaBg5DjBHm
   Call-ID: 1d80cd44-781c-1231-8db7-0050568a49fc
   CSeq: 47499341 BYE
   Contact: <sip:gw+sbc at 210.7.46.240:5060;transport=udp;gw=sbc>
   User-Agent: FreeSWITCH-mod_sofia/1.3.13b+git~20130223T185558Z~28680c5e58
   Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE,
REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
   Supported: timer, precondition, path, replaces
   Reason: SIP;cause=488;text="Incomplete offer/answer"
   Content-Length: 0

   ------------------------------------------------------------------------


Then I see this in the logs straight after

2013-08-05 14:46:48.736200 [DEBUG] sofia.c:1431 nua_i_media_error: unknown
event 22: 988 Incomplete offer/answer




The only thing odd about the SDP packet that I get back is the attribute
after the m=video line. I think FreeSWITCH sees this, doesn't ignore the a=
line like it should, and then gets upset with not being able to match
anything before the "/0". RFC 4566 (5.13) says that

"If an attribute is received that is not understood, it MUST be ignored by
the receiver."

So FreeSWITCH should be ignoring any "a=" attributes after it gets a "m="
line with a 0 port, but should also ignore the attribute if it can't match
(but maybe leave a warning/notice in logs)?

Does this look right? Has anyone else seen this, and is there a workaround?

Cheers
Sam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20130805/a8dbbbe7/attachment-0001.html 


Join us at ClueCon 2013 Aug 6-8, 2013
More information about the FreeSWITCH-users mailing list