| He should ask his SBC vendor to go to SIPit :)
btw everyone - in case you didn't see the announcement in other venues, registration for SIPit21 is open. It's going to be in Beijing in November this time. See www.sipit.net for more details.
RjS
On Aug 28, 2007, at 8:37 AM, Aziz Mzili wrote: Scott, I came across this case at a Cable operator facility. He SBC is mangling SDP packets and that’s the way it’s putting it. I tested with some other implementation and they just consider the packet as malformed. Regards Aziz Enforcing the RFC specified order makes our parsing more efficient. However, if this really is a common bug (I’ve never come across it before) – then we could consider making a special case for it. Scott Scott - Why do we care? Unless I'm missing something, this is a place where we can apply Postel's Maxim to benefit. If we write an encoder, it should always put the t line in the right place. But when we're parsing - what would break if we allowed t to float through the message? On Aug 25, 2007, at 9:23 AM, Scott Godin wrote: Resiprocate is parsing correctly. Note the highlighted lines below – t is always before a in a session description. Scott In one of our products using resiprocate, we send an sdp similar to the following: v=0
o=- 416386389 0 IN IP4 56.160.21.109
s=192.168.1.109
c=IN IP4 72.175.237.109
a=cq0: 978969970219150701
a=cq2: 978969972231897453
t=0 0
m=audio 3478 RTP/AVP 120 18 0 101
a=control:trackid=1
a=fmtp:101 0-15
a=rtpmap:120 IP-MR-V25/8000
a=rtpmap:18 g729/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
m=video 3478 RTP/AVP 96
a=control:trackid=1
a=fmtp:96 CIF=1 QCIF=1/MAXBR=3200 profile-level-id=4DE01F
a=recvonly
a=rtpmap:96 H264/900 Resiprocate in SdpContents.cxx ( SdpContents::Session::parse(ParseBuffer& pb) ) parses 't', 'z','k', and 'a', then 'm' . But rfc 4566 says the following in section 5 : Some lines in each description are REQUIRED and some are OPTIONAL,
but all MUST appear in exactly the order given here (the fixed order
greatly enhances error detection and allows for a simple parser).
OPTIONAL items are marked with a "*".
Session description
v= (protocol version)
o= (originator and session identifier)
s= (session name)
i=* (session information)
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions
Time description
t= (time the session is active)
r=* (zero or more repeat times)
Media description, if present
m= (media name and transport address)
i=* (media title)
c=* (connection information -- optional if included at
session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)
You notice that 'a' is before 't'. and in our case the media section is not parsed. _______________________________________________ resiprocate-users mailing list
|