Problem found Re: [asterisk-users] Headaches with Video over SIP

Peter Howard peter.howard at ursys.com.au
Tue Nov 14 13:50:42 MST 2006


On Tue, 2006-11-14 at 02:10 -0800, Steve Langstaff wrote:
> > -----Original Message-----
> > From: asterisk-users-bounces at lists.digium.com 
> > [mailto:asterisk-users-bounces at lists.digium.com] On Behalf Of 
> > Peter Howard
> > Sent: 14 November 2006 00:38
> > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > Subject: Problem found Re: [asterisk-users] Headaches with 
> > Video over SIP
> 
> > Found the problem.  Some other people on the list might be 
> > interested in the problem.
> > 
> > Looking at the initial INVITE call from station 1 to asterisk 
> > and from asterisk to station 2, you see the following discrepancy:
> > 
> > >From Polycom to asterisk:
> > a=rtpmap:109 H264/90000
> > a=rtpmap:96 H263-1998/90000
> > 
> > >From asterisk to other Polycom:
> > a=rtpmap:103 h263-1998/90000
> > a=rtpmap:99 H264/90000
> > 
> > The latter numbers match the numbers in rtp.c, which clearly 
> > don't agree with the Polycom's opinion on life.  However the 
> > other Polycom seems to accept asterisk's version, while the 
> > first Polycom is still working on it's version.
> > 
> > I modified the initialisation of static_RTP_PT in rtp.c to 
> > match the Polycom values and, hey presto!  I have video 
> > working between the two stations.
> > 
> > However, this doesn't look like a "proper" solution, if there 
> > are multiple opinions out there of what h263p and h264 (at 
> > least) should be mapped to.  There's also the array 
> > current_RTP_PT in rtp.c  What is that used for?  I would have 
> > thought that either:
> > 1) Asterisk should tell _both_ ends what mapping to use,
> > 2) Asterisk should update it's own mapping based on what it's 
> > told (though this would have to be on a call-by-call basis)
> 
> #2 is true (at least for audio, so I guess for video as well).
> 

Or should be.

> Codec identifiers >= 96 refer to dynamic payload types.
> 

Thanks, that's worth knowing.

> They have to be negotiated on each SDP offer/answer exchange.
> 
> So for the Polycom->Asterisk traffic, Asterisk should parse the SDP and
> say to itself "Hey, the caller wants me to send it H264 marked with
> payload type 109, and/or H263-1998 marked with payload type 96." and
> adapt it's outgoing payload type marking accordingly.
> 

"should parse the SDP".  It's not at 1.4.0-beta3 (or, seemingly, earlier
versions).  Should I submit a bug report for this?



-- 
Peter Howard
URSYS
13 Burwood Rd,
Burwood, NSW 2134

Ph: 02 8745 2816    Fax: 02 8745 2828



More information about the asterisk-users mailing list