[reSIProcate] Workaround for invalid SDP generated by Sonus_UAC

[Dmitry Semyonov]

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.