views:

139

answers:

3

Hey,

I would like to create a SDP media field with its attributes, and there are a few things I don't understand. I've skimmed and read the relevant RFC and I understand most of what each field means, but what I don't understand is how do I derive from the Audio/Video Format of the JMF, which parameters of the format compose the rtpmap registry entries I need to use. I see many times the fields

m=audio 12548 RTP/AVP 0 8 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=silenceSupp:off - - - -
a=ptime:20
a=sendrecv

these are received from the pbx server I'm connecting to, what do they mean in the terms of the JMF audio format properties. (I do understand these are standard audio format commonly used in telecommunication)

UPDATE:

I was more wondering about the format parameter '0 8 101' at the end of

m=audio 12548 RTP/AVP 0 8 101

I know they are referenced from this list, but how do I determine according to the JMF media format which one to use?

Thanks in advance,

Adam Zehavi.

+1  A: 

I'm not sure if this is what you asked for, but:

  • PCMU/8000: 1-channel, 8000 Hz, m-Law encoded format
  • PCMA/8000: 1-channel, 8000 Hz, A-Law encoded format
  • telephone-event: DTMF digits, telephone tones
danadam
This is a part of what I was asking/wondering. Thank you!
TacB0sS
+2  A: 

You can use any of the codecs listed in the SDP. The agent that sent the SDP is stating that it supports all of the codecs listed.

In the SDP example you've provided you could start sending RTP encoded with either G711 ULAW (PCMU) or G711 ALAW (PCMA).

sipwiz
yes yes, I get this, understanding what I can send is very simple, what I don't understand is there are 10 different names for the same properties. if you look at the link I supplied, at index 0,3,4,5,7,8,9they all have the same properties, how do I know which to add on the first request?
TacB0sS
I think I understand now.. I'm confusing sending request and received response parameters... this is not how you send you request... am I right?
TacB0sS
Sorry I don't really understand the question. In the INVITE request SDP the caller specifies a list of codecs they support. The receiver can choose any one of those codecs for the RTP stream it sends. The receiver then sends an INVITE response with a different SDP that specifies the codecs its prepared to accept. When the caller gets that it can choose any one of those codecs for the RTP stream it's going to send. This means the sender and receiver RTP streams can actually be using different codecs although usually they will be the same.
sipwiz
I think I understand I'll post back after testing a bit
TacB0sS
A: 

Well after long while of searching and not really understanding, I can answer my question. In my eyes, the only use for SDP would have been for each side to state to the other his media capabilities, I did not realize it was in the form of negotiation, I didn't understand the need for such a deep negotiation about media, I thought Client 1 could supply X,Y,Z,W, client 2 would response I can only get X,W and then Client one would say ok I send you W format...

don't know why this made perfect sense to me, and I'm going to design my SDP wrapper of my application in this manner, and only to use JMF formats as a comparison instead of dealing with the gutter of the SDP, over and over, I would try to design a general template that would perform all these annoying text generating methods, using JMF format array, just like I think it should be, the only thing I'm surprised is that I didn't find anything like this already made...

Thanks for all your help, and if anyone ever wonder about this subject again, just start reading this RFC

TacB0sS