Re: [reSIProcate] Does this a SDP parse compatible problem with RFC ?
Karlsson wrote:
> Hi all, I have countering a problem with SDP parse, it's seems a
> compatible bug with RFC.
> When I received a INVITE with SDP as this:
>
> v=0
> o=- 55 0 IN IP4 192.168.11.205
> s=-
> t=0 0
> m=audio 21758 RTP/AVP 0 101
> c=IN IP4 192.168.11.13
> a=rtpmap:0 PCMU/8000
> a=rtpmap:101 telephone-event/0
> a=ptime:20
> a=sendrecv
> m=video 41140 RTP/AVP 125
> c=IN IP4 192.168.11.13
> a=rtpmap:125 H264/90000
> a=fmtp:125 profile-level-id=42e015
>
>
> This SDP have two c= line, and the t= line is before c= line, when I try
> to got the connection IP by this code:
> *sdp.session().connection().getAddress()*
> it's return empty value.
I think this is correct. The session section of this SDP has no c= line.
It sounds like you are expecting resip to inspect all the media sections
and move the connection information into the session section if it is
all identical across all the media sections. Resip does not do this.
Instead you should be iterating sdp.session().media() and looking at
getConnections() or getMediumConnections().
> I have search the mail list and found this:
> http://list.resiprocate.org/archive/resiprocate-devel-old/msg02253.html
>
> I think thread Soctt has said "Here is a note from RFC2327. t= line
> before c= line is not valid."
This is an entirely different issue. t= line before c= line is invalid
in the session section but you have an m= line starting a media
section in between.
> With the RFC 4566 and RFC 2327. In both
> is written
[snip]
>
> According to this, (especially the 5 section of RFC), the value of c= in
> session description should
> be overwritten with the value from media section. If not, the SIP stack is
> not compatible with RFC.
I don't think the RFC says that. It says that c= in the session section
provides a default for media sections with no c= of their own, but
doesn't place requirements on SDP parsers to rewrite identical c=
information in every media section into a session-level c=.
Hope that helps,
Max.
--
Max Bowsher <maxb@xxxxxxxxxxxxx>
http://www.mxtelecom.com