By offering: m=audio 3456 RTP/AVP 2 9 15
you are saying you can receive any of those codecs on port 3456. Maybe you could use a different port for each codec and offer: m=audio 3456 RTP/AVP 2 m=audio 3458 RTP/AVP 9 m=audio 3460 RTP/AVP 15 You should then get an answer: m=audio 5004 RTP/AVP 2 m=audio 5006 RTP/AVP 9 m=audio 0 RTP/AVP 15 Note "15" was disabled by setting the port number to 0. You cannot send SDP in the ACK because you sent it in the INVITE. If you need to change, you must re-INVITE. Another alternative would be send an OPTIONS request to get back the capabilities of the other end. Then you could narrow down the codecs you offer. But not all UAs support OPTIONS. cheers, (-:bob Robert F. Penfield Chief Software Architect Acme Packet, Inc. 130 New Boston Street Woburn, MA 01801 [EMAIL PROTECTED] ----- Original Message ----- From: "Vikram Varma" <[EMAIL PROTECTED]> To: "'Shen, Eran '" <[EMAIL PROTECTED]>; "'Sip-Implementors (E-mail) '" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 8:55 AM Subject: RE: [Sip-implementors] Problem with media channels in SIP. > I believe you have interpreted the standard correctly. If you advertise you > can receive codec x, y, and z, I dont believe there is a particular order in > which the sender is bound to send his data. I believe the bottom line is > that if you advertise a list of codecs, then you have to analyze the RTP > headers to figure out which is being sent - further, I believe that the > sender can also switch on the fly. > If you want to narrow down the codec, I think you have a few options: > Narrow down the list to a single codec by including a new SDP in the ACK > (I'm not sure if this is OK) > Renegotiate using a reInvite from the list you obtained. > Vikram > > > -----Original Message----- > From: Shen, Eran > To: Sip-Implementors (E-mail) > Sent: 11/27/2001 5:34 AM > Subject: [Sip-implementors] Problem with media channels in SIP. > > I have a problem, > > INVITE: M=audio 3456 RTP/AVP 2 9 15 > 200: m=audio 5004 RTP/AVP 2 9 > > Every side give the coders that it can receive (reverseChannels) > But how would the UAC will know what was picked by the UAS for > transmission > (forwardChannel). > > In other words: lets say I have a machine that can do payload types 2 9 > 15 > But it must know what algorithm to load before its start receiving. > > In one hand I want to advertise I can do all of the above, to increase > compatibility to other vendors. > > On the other hand I would like to know what the remote is going to send > me > without looking at the payload type field in the RTP packet header. > > How can I signal that in SIP/SDP? > > In H.323 you have TCS and than OLC & OLCA > Or in fastStart: > OLC & OLCA for forwardChannel > OLCA and then OLC for reverseChannel > > But in SIP the remote side does not pick from your list and tells you > what > will be transmitted, it just start transmitting. > > So if you compare it to H.323 its: > TCS from one side > TCS from the other side > > And start transition without saying what will I transmit. > This can cause many interop problems. > Do you know a solution for that problem? > Do I interpret the standard correctly? > > Thanks, > > Eran. > > Eran Shen > > Intel Corporation > Telecommunications and Embedded Group > P.O Box 58, Migdal Tefen, Israel > Tel: +972-4-9105020 > <mailto:[EMAIL PROTECTED]> > > > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
