Another query: What is the SIP recommended behavior for UA that can accept only one payload format at a time (can not change on the fly w/o re-INVITE)? I can think of some ideas:
1. Try always to be the second party that sends SDP, and choose 1st payload format. 2. If you are the 1st side that sends SDP open your receiving media on the 1st codec the remote side sent in his own SDP. 3. If the remote side SDP includes a=receiveonly or a=transmitonly (must be a subset of yours), your media will open the 1st from receiveonly for you to transmit and 1st from transmitonly for your receive. 4. re-INVITE with your one coder. 5. re-INVITE when you are getting bad payload format (a one you did not expected). Any comments? Thanks, Eran. Eran Shen Intel Corporation Telecommunications and Embedded Group P.O Box 58, Migdal Tefen, Israel Tel: +972-4-9105020 <mailto:[EMAIL PROTECTED]> -----Original Message----- From: Vikram Varma [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 3:55 PM To: 'Shen, Eran '; 'Sip-Implementors (E-mail) ' 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
