The ideal way to solve this is with simcap. Thats why it was done:

http://www.ietf.org/internet-drafts/draft-andreasen-mmusic-sdp-simcap-04.txt

You had also asked previously:

> 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. 
> 

This is the same problem, more or less. Note that the uas SHOULD send 
with codec 2 in this case, but can use the others in cases like silence 
suppression and rfc2833 dtmf encoding, which require on-the-fly changes.

-Jonathan R.

Shen, Eran wrote:

> 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
> 


-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[EMAIL PROTECTED]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip-implementors mailing list
[EMAIL PROTECTED]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors

Reply via email to