Hi, Be the scenario: sipxtapi Endpoint sends INVITE Cseq: 2195 INVITE Message Header Message Body Session Description Protocol Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): sipX 5 5 IN IP4 192.168.15.100 Session Name (s): call
Time Description, active time (t): 0 0 Media Description, name and address (m): audio 16384 RTP/AVP 3 8 0 96 Media Attribute (a): rtpmap:3 gsm/8000/1 *Media Attribute (a): rtpmap:8 pcma/8000/1* Media Attribute (a): rtpmap:0 pcmu/8000/1 Media Attribute (a): rtpmap:96 telephone-event/8000/1 Media Attribute (a): ptime:20 ... ... it receives early media from remote: *** **** Status-Line: SIP/2.0 183 Session Progress Message Header Message Body Session Description Protocol Session Description Protocol Version (v): 0 ***** **** Media Attribute (a): direction: passive *Media Attribute (a): rtpmap:0 PCMU/8000* Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:96 0-15 Media Attribute (a): sendrecv Media Attribute (a): ptime:20 Media Attribute (a): nortpproxy:yes ... .... both starts RTP early media using *PCMU* (remote and local - sync encoding) sipx <----rtp PCMU -->remote and finally sipxtapi receives: Status-Line: SIP/2.0 200 OK *CSeq: 2195 INVITE* Message Body Session Description Protocol Session Name (s): SIP Media Capabilities Time Description, active time (t): 0 0 Media Description, name and address (m): audio 48962 RTP/AVP 0 96 Media Attribute (a): direction: passive Media Attribute (a): rtpmap:0 *PCMU/8000* Media Attribute (a): rtpmap:96 telephone-event/8000 Media Attribute (a): fmtp:96 0-15 Media Attribute (a): sendrecv Media Attribute (a): ptime:20 Media Attribute (a): nortpproxy:yes After that, remote EP sends RTP *PCMA* (as offered during initial invite by sipxtapi) to sipxtapi and sipxtapi sends PCMU to remote sipxtapi---->PCMU-->remote sipxtapi<---PCMA-<--remote (Asynchronous transcoding situation) Strangely remote EP keeps the same stream id despite changing the codec used on it - maybe a broken implementation there. It could be useful to detect a sudden payload type change and resetting the decoder in the sipxtapi....althought it should use PCMA after 200 ok message: Status-Line: SIP/2.0 200 OK *CSeq: 2195 INVITE* Session Description Protocol Session Name (s): SIP Media Capabilities Time Description, active time (t): 0 0 Media Description, name and address (m): audio 48962 RTP/AVP 0 96 Media Attribute (a): direction: passive Media Attribute (a): rtpmap:0 PCMU/8000 ... At this point sipxtapi should comute to PCMA *decoder *but as far as I got no audio i think it is failing in doing that..I will check that... Regards, Paulo On Mon, Feb 23, 2009 at 1:10 PM, Alexander Chemeris < alexander.cheme...@sipez.com> wrote: > Hi Paulo, > > On Mon, Feb 23, 2009 at 6:50 PM, Paulo Vicentini > <vicentini.pa...@gmail.com> wrote: > > I am wondering if sipxtapi supports Asynchronous transcoding , for > example, > > one endpoint is talking G.711 to another endpoint talking GSM or two > > different encodings. > > Yes, sipXmediaLib is setup to decode all codecs, announced > in SDP, so if both G.711 and GSM were announced, it will > be able to decode them. Then, for encoding it uses a codec > with the highest priority from the common set of codecs of > both parties. If GSM is the highest priority, it will be selected > as encoder's codec. > > Well, at least it is supposed to work so. If you find a bug - > please report here. > > > -- > Regards, > Alexander Chemeris. > > SIPez LLC. > SIP VoIP, IM and Presence Consulting > http://www.SIPez.com > tel: +1 (617) 273-4000 >
_______________________________________________ sipxtapi-dev mailing list sipxtapi-dev@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipxtapi-dev/
