< Previous by Date Date Index Next by Date >
  Thread Index Next in Thread >

[reSIProcate] Workaround for invalid SDP generated by Sonus_UAC


Hi All,

I recently discovered that some Sonus equipment (identified by Sonus_UAC in SDP) produces invalid SDP contents which reSIProcate is not capable of dealing with:

v=0
o=Sonus_UAC 19813 20746 IN IP4 192.168.0.1
s=SIP Media Capabilities
t=0 0
achieve this.
m=image 0 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:4000
a=T38FaxMaxDatagram:1008
a=sendrecv
m=audio 6042 RTP/AVP 0
a=rtpmap:0 PCMU/8000
c=IN IP4 192.168.0.2
a=sendrecv
a=maxptime:20

The SDP is complete mess[1], but the main issue is 'a=' line *before* 'c=' in the second media description. SdpContents parser simply ignores everything (including 'c=') after the first 'a='.

I most likely will be able to workaround this Sonus bug by playing with original offer SDP, but I'd also like to warn everyone on this list about the issue, and provide possible workaround idea for reSIProcate parser (untested).


[1] http://www.submityoursip.com/wiki/Sonus_NBS


Index: resip/stack/SdpContents.cxx
===================================================================
--- resip/stack/SdpContents.cxx (revision 8413)
+++ resip/stack/SdpContents.cxx (working copy)
@@ -1327,6 +1327,9 @@
       skipEol(pb);
    }

+  do { // workaround for broken SDP implementations (e.g. Sonus_UAC) that can 
put a= before c=
+   Pointer pos = pb.position();
+
    while (!pb.eof() && *pb.position() == 'c')
    {
       addConnection(Connection());
@@ -1392,6 +1395,8 @@
    }

    mAttributeHelper.parse(pb);
+
+  } while(!pb.eof() && pos != pb.position())
 }

 EncodeStream&


--
...Bye..Dmitry.