reSIProcate

Mailing Lists

Source Code

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

Re: [reSIProcate-users] SDP parsing order

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

 

From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx]
Sent: Monday, August 27, 2007 10:29 AM
To: Scott Godin
Cc: 'Aziz Mzili'; resiprocate-users@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate-users] SDP parsing order

 

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?

 

RjS

 

 

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

 

From: resiprocate-users-bounces@xxxxxxxxxxxxxxxxxxxx [mailto:resiprocate-users-bounces@xxxxxxxxxxxxxxxxxxxx] On Behalf Of Aziz Mzili
Sent: August 24, 2007 11:12 AM
To: resiprocate-users@xxxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate-users] SDP parsing order

 

 

Hi All,

 

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.

 

any comments ???

 

thank you

 

Aziz

 

 

 

 

 

_______________________________________________

resiprocate-users mailing list