Hi Raphael and Emil, The issue was actually with FlowRoute, and they have since fixed the issue. However, they pointed out that, per RFC 3264, Section 6.1, "In the case of RTP, if a particular codec was referenced with a specific payload type number in the offer, that same payload type number SHOULD be used for that codec in the answer".
But I think maybe I've diverted attention away from Emil's original issue... On Sun, Jun 12, 2011 at 2:39 AM, Raphael Coeffic <[email protected]> wrote: > Hi Emil, Matthew, > > I'm quite sure how to realize such a "remote bugfix", as it could overlap > with locally define codecs... > By the way, I've seen this behavior with Jitsi (aka. SIP communicator). > However, my snom 360 behaves correctly. > Neither of the other UAs I have ever used do expose such a missbehavior. > > Matthew: were you using Jitsi (possibly the osx versiob ;-))? If yes, we > should definitely file a bug report. > > Cheers > Raphael. > > > On 11.06.11 17:53, Emil Kroymann wrote: > > Hi Matthew, > > I think in this case it is the peer behaving incorrectly. The peer > should send under the payload types offered by SEMS and SEMS vice-versa > under the payload types given in the answer. > > Still it seems to be desirable for interoperability, if SEMS would > match the payload types given by the peer. In the case where SEMS is > generating the SDP offer, this is not possible, however. > > Regards, > Emil > > Am Sat, 11 Jun 2011 11:02:10 -0400 > schrieb Matthew Williams <[email protected]> <[email protected]>: > > > Hi, > > I think I'm finding a very similar issue with payload types for > telephone-events. If this is unrelated, please accept my apologies. > > A peer is sending an INVITE with a payload type of '101' for > telephone-events. In SEMS' reply (200 OK), payload type '96' is > indicated for telephone-events. When the peer sends an event with > type 101, SEMS rejects it as unknown type. I was actually expecting > SEMS to reply with the same payload type (101), but from what you're > saying, it seems the sdp itself is acceptable, but the fact that SEMS > is rejecting payload type 101 is not? Or is it the peer that should > be sending as type 96, since this is what was in the SDP reply? > > I am working with latest master > (856a7428eaea24a426688b277b2d504b4cb1f798). > > Regards, > Matthew Williams > > > > > On Sat, Jun 11, 2011 at 7:05 AM, Emil Kroymann<[email protected]> > <[email protected]>wrote: > > > Hi, > > I think I found a problem with the SDP offer-answer implementation > recently merged into master while implementing wideband > functionality. The problem is with the assignement of dynamic > payload types. SEMS seems to keep only one mapping of dynamic > payload types to codec implementation, which is global to all of > SEMS. However, it should keep two separate mappings - one for > sending and one for receiving - for each RTP stream. This problem > shows in the following setup: > > I use twinkle to setup a call to SEMS, which plays an announcement > using the speex wideband codec. Twinkle sends the following SDP > in the INVITE: > > v=0. > o=twinkle 1229564934 1632772146 IN IP4 192.168.1.121. > s=-. > c=IN IP4 XX.XX.XX.XX. > t=0 0. > m=audio 13006 RTP/AVP 98 97 8 0 102 3 101. > a=rtpmap:98 speex/16000. > a=rtpmap:97 speex/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:0 PCMU/8000. > a=rtpmap:102 G726-16/8000. > a=rtpmap:3 GSM/8000. > a=rtpmap:101 telephone-event/8000. > a=fmtp:101 0-15. > a=ptime:20. > a=nortpproxy:yes. > > This means, that twinkle expects the speex wideband codec under > payload type 98 and the speex narrowband codec under payload type > 97. > > SEMS answers with the following SDP in the 200 OK: > > v=0. o=sems 1 1 IN IP4 XX.XX.XX.XX. > s=sems. > c=IN IP4 89.246.236.49. > t=0 0. > m=audio 10000 RTP/AVP 97 96 8 0 101. > a=rtpmap:97 speex/16000. > a=rtpmap:96 speex/8000. > a=rtpmap:8 PCMA/8000. > a=rtpmap:0 PCMU/8000. > a=rtpmap:101 telephone-event/8000. > > This means, that SEMS expects the speex wideband codec under payload > type 97 and the speex narrowband codec under payload type 96. > > Unfortunately, SEMS sends speex wideband encoded RTP packets with > payload type 97. This leads to twinkle decoding the audio with the > narrowband decoder and to poor audio quality. > > As mentioned above, to fix the problem, SEMS has to keep a seperate > payload type mapping for sending and it has to set the payload type > on outgoing packets according to this mapping. > > Since we need this functionality at ISACO quite urgently, I would be > willing to implement a fix for this. > > What do you think? > > Regards, > Emil > > -- > Emil Kroymann > VoIP Services Engineer > > Email: [email protected] > Tel: +49-30-203899885 > Mobile: +49-176-38389303 > > ISACO GmbH > Kurfürstenstraße 79 > 10787 Berlin > Germany > > Amtsgericht Charlottenburg, HRB 112464B > Geschäftsführer: Daniel Frommherz > > > _______________________________________________ > Sems mailing > [email protected]http://lists.iptel.org/mailman/listinfo/sems > > > _______________________________________________ > Sems mailing > [email protected]http://lists.iptel.org/mailman/listinfo/sems > > > > _______________________________________________ > Sems mailing list > [email protected] > http://lists.iptel.org/mailman/listinfo/sems > >
_______________________________________________ Sems mailing list [email protected] http://lists.iptel.org/mailman/listinfo/sems
