RE: Problem found Re: [asterisk-users] Headaches with Video over SIP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Howard Sent: 14 November 2006 20:51 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: Problem found Re: [asterisk-users] Headaches with Video over SIP 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? *If* Asterisk is claiming compliance with RFC 2327, *and* if you read the RFC the same way that I do, *and* you are actually seeing what you have reported then I guess you *could* submit a bug report, but I'm not going to say that you *should* submit a report (is that disclaimered enough?). As an aside, it appears that this issue might already be the subject of bugs 6568 and 7461. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: Problem found Re: [asterisk-users] Headaches with Video over SIP
On Wed, 2006-11-15 at 01:47 -0800, Steve Langstaff wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Howard Sent: 14 November 2006 20:51 To: Asterisk Users Mailing List - Non-Commercial Discussion Subject: RE: Problem found Re: [asterisk-users] Headaches with Video over SIP 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? *If* Asterisk is claiming compliance with RFC 2327, *and* if you read the RFC the same way that I do, *and* you are actually seeing what you have reported then I guess you *could* submit a bug report, but I'm not going to say that you *should* submit a report (is that disclaimered enough?). As an aside, it appears that this issue might already be the subject of bugs 6568 and 7461. It looks exactly like bug 6568 (I'd missed the remapping in the OK back to the first phone). I think I'll try to reopen it. -- Peter Howard URSYS 13 Burwood Rd, Burwood, NSW 2134 Ph: 02 8745 2816Fax: 02 8745 2828 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: Problem found Re: [asterisk-users] Headaches with Video over SIP
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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/9 a=rtpmap:96 H263-1998/9 From asterisk to other Polycom: a=rtpmap:103 h263-1998/9 a=rtpmap:99 H264/9 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). Codec identifiers = 96 refer to dynamic payload types. 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. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
RE: Problem found Re: [asterisk-users] Headaches with Video over SIP
On Tue, 2006-11-14 at 02:10 -0800, Steve Langstaff wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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/9 a=rtpmap:96 H263-1998/9 From asterisk to other Polycom: a=rtpmap:103 h263-1998/9 a=rtpmap:99 H264/9 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 2816Fax: 02 8745 2828 ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
