MMS , codec selection
Laurent Schweizer
Hello,
When I send a MGCP request with a SDP that have multiple codec possibility like PCMA, PCMU, G729 to MMS he send me back a SDP with the full list of compatible codec like PCMA, PCMU
This is working with most of the phone (maybe they are using the codec indication in the RTP stream) but some phones doesn’t like it . They are waiting back a SDP with only one compatible codec . ( they propose all available codec and they expect that the other endpoint select the compatible codec).
I that possible to configure MMS to work like this , so that he send only one codec in SDP answer ?
I see in some documentations that if the final endpoint send back a list of multiple codec, then the endpoint that as started the negotiation must choose the codec and send again a SDP with the selected codec, ( I never see it ).
Regards
Laurent
4.30.2 Codec Negotiation in SIP Sessions
Codec Negotiation is an integrated part of the basic SDP Offer/Answer method.Codec Negotiation is always performed at SIP session establishment.
ControlServers can re-negotiate codecs during an ongoing SIP session using thesame SDP Offer/Answer method.A peer Control Server must accept one codec in a SDP Offer performed atcall set-up. However, it may reject a new codec during codec re-negotiation.The basic SDP based codec negotiation procedure works as follows:
The originating Control Server sends its list of supported codec typesand modes, listed in order of preference in the initial SDP Offer (in SIPINVITE message).
The terminating Control Server may either:
Select a single codec for the SIP session and returns thatselected codec in the SDP Answer to the originating ControlServer.
Determine a list of acceptable codecs for the SIP session andreturns that list of codecs in the SDP Answer. In this case thecodec selection is left to the originating Control Server.
The originating Control Server has to act depend on the receivedinformation in the SDP Answer, so either:
A single codec is received in the SDP Answer. In this case thisis the codec to be used for the SIP session.
A list of acceptable codecs is received in the SDP Answer. Thenthe originating Control Server has to select a single codec for the SIP Session. This selected codec is then sent in another SDP Offer. The terminating Control Server acknowledges theselected codec by returning it in the SDP Answer to theoriginating Control Server. I.e. a second SDP Offer/Answer exchange is used to lock the codec.
And log of actual MMS
CRCX 806011567 mobicents/aap/$@xxxxxxx:2427 MGCP 1.0
C: 7c
M: sendonly
v=0.
o=90767740839 5014 150 IN IP4 yyyyyyyyy.
s=Mapping.
c=IN IP4 yyyyyyy.
t=0 0.
m=audio 13566 RTP/AVP 8 0 18 101.
a=rtpmap:8 PCMA/8000.
a=rtpmap:0 PCMU/8000.
a=rtpmap:18 G729/8000.
a=fmtp:18 annexb=no.
a=rtpmap:101 telephone-event/8000.
a=fmtp:101 0-16.
a=nortpproxy:yes.
200 806011567 Success
I:bafd6463e196e0
Z:mobicents/aap/5@xxxxxxxxx:2427
v=0
o=- 1323963580963 1 IN IP4 xxxxxxxxx
s=Mobicents Media Server
c=IN IP4 xxxxxxxxxx
t=0 0
m=audio 65374 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
Thomas Quintana
Thomas Quintana
Laurent Schweizer
Hi Thomas,
thanks for the fast answer.
Regards
Laurent
De : Thomas Quintana [mailto:quintan...@gmail.com]
Envoyé : jeudi 15 décembre 2011 16:59
À : mobicent...@googlegroups.com
Objet : Re: [mobicents-public] MMS , codec selection
Oleg Kulikov
Oleg
Laurent Schweizer
I have a case where the phone send a SDP with the codec order “ 0 8 101 “ so PCMU , PCMA
This SDP is sent to MMS and he send back the same order “ 0 8 101 “.
If we check RTP stream, then the phone is sending PCMU stream but MMS is sending PCMA stream.
For sure MMS is not wrong but in this case the phone must re-invite with a SDP that has only one codec to be sure that both use the same codec and usually they don’t do it.
So maybe MMS can only send back one codec so we are assured that both use the same or at least if both SDP have same codec on top of the list (in this case PCMU) then use this codec to send the stream, no ?
Attached the wireshark file (only SIP and RTP ).
Regards
Laurent
De : Oleg Kulikov [mailto:oleg.k...@gmail.com]
Envoyé : jeudi 15 décembre 2011 17:31
Oleg Kulikov
Laurent Schweizer
Hi Oleg,
Regarding this bug, I have done more check with the last version (svn).
So codec order in SDP seems ok , just MMS don’t use the first selected codec to send RTP
In this example:
2012/01/26 17:33:48.384080 192.168.1.10:2727 -> 192.168.1.10:2427
CRCX 151667806 mobicents/ivr/$@192.168.1.10:2427 MGCP 1.0
C: be
M: sendrecv
v=0.
o=- 20032 20032 IN IP4 192.168.1.20.
s=SDP data.
c=IN IP4 192.168.1.20.
t=0 0.
m=audio 14110 RTP/AVP 0 8.
a=rtpmap:0 PCMU/8000.
a=rtpmap:8 PCMA/8000.
a=ptime:20.
a=sendrecv.
a=nortpproxy:yes.
U 2012/01/26 17:33:48.421503 192.168.1.10:2427 -> 192.168.1.10:2727
200 151667806 Success
I:4d22546048882
Z:mobicents/ivr/1...@192.168.1.10:2427
v=0
o=- 1327595628402 1 IN IP4 192.168.1.10
s=Mobicents Media Server
c=IN IP4 192.168.1.10
t=0 0
m=audio 65530 RTP/AVP 0 8
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
PCMU is negotiated but MMS send PCMA stream,
Maybe did you have any idea what is the problem ? or can you tell me where I must search ?
Regards
Laurent
De : Oleg Kulikov [mailto:oleg.k...@gmail.com]
Envoyé : jeudi 15 décembre 2011 18:17
Oleg Kulikov
RTPFormats audio = sdpComparator.getAudio();
You can remove unnecessary formats from RTPFormats collection (or may be change order of formats inside collection).
Regards,
Oleg
Laurent Schweizer
Hi Oleg
The problem seems not with the sdpComparator
If you check the log bellow, the result from the SDPComparator is correct -> RTPFormat sdpComparator.getAudio():RTPFormats{0 AudioFormat[PCMU,8000,8,mono],8 AudioFormat[PCMA,8000,8,mono]}
so the selected codec is PCMU and it’s the first choice of the calling party.
The problem is that the codec used to send the stream is PCMA. ( Second part of log)
Any idea ?
17:21:23,194 INFO [MGCP] tx=714605132 Started, message= CRCX mobicents/ivr/$@10.10.10.2:2427, call agent = /10.10.10.2:2727
FormatsRTPFormats{0 AudioFormat[PCMU,8000,8,mono],8 AudioFormat[PCMA,8000,8,mono]}
this.audioFormats:Formats{AudioFormat[pcma,8000,8,mono],AudioFormat[pcmu,8000,8,mono],AudioFormat[telephone-event,8000,mono]}
RTPFormat sdpComparator.getAudio():RTPFormats{0 AudioFormat[PCMU,8000,8,mono],8 AudioFormat[PCMA,8000,8,mono]}
17:21:23,238 INFO [MGCP] tx=714605132 was executed normaly
17:21:23,366 INFO [MGCP] tx=714605133 Started, message= RQNT mobicents/ivr/1...@10.10.10.2:2427, call agent = /10.10.10.2:2727
33.431012 10.10.10.16 -> 10.10.10.2 SIP/SDP Request: INVITE sip:*1...@10.10.10.2:5060;transport=tcp, with session description
33.431039 10.10.10.2 -> 10.10.10.16 TCP sip > 43684 [ACK] Seq=1089 Ack=2712 Win=501 Len=0 TSV=1701639006 TSER=2130353816
33.434296 10.10.10.2 -> 10.10.10.16 SIP Status: 100 Trying
33.474197 10.10.10.16 -> 10.10.10.2 TCP 43684 > sip [ACK] Seq=2712 Ack=1476 Win=501 Len=0 TSV=2130353860 TSER=1701639009
33.525584 10.10.10.2 -> 10.10.10.16 SIP/SDP Status: 200 OK, with session description
33.525827 10.10.10.16 -> 10.10.10.2 TCP 43684 > sip [ACK] Seq=2712 Ack=2175 Win=501 Len=0 TSV=2130353911 TSER=1701639100
33.540491 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=0, Time=160
33.561532 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=1, Time=320
33.581109 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=2, Time=480
33.600638 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=3, Time=640
33.621157 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=4, Time=800
33.625454 95.128.80.8 -> 10.10.10.2 SIP Request: ACK sip:peopl...@10.10.10.2:5060
33.640648 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=5, Time=960
33.661142 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=6, Time=1120
33.677133 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=750, Time=135200, Mark
33.680551 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=7, Time=1280
33.697130 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=751, Time=135360
33.700963 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=8, Time=1440
33.708462 95.128.80.8 -> 10.10.10.2 SIP Request: NOTIFY sip:10.10.10.2:48777;transport=tcp
33.711312 10.10.10.2 -> 95.128.80.8 SIP Status: 200 OK
33.711497 95.128.80.8 -> 10.10.10.2 TCP sip > 48777 [ACK] Seq=4004 Ack=3070 Win=501 Len=0 TSV=2130354097 TSER=1701639286
33.713762 10.10.10.2 -> 95.128.80.8 SIP Request: NOTIFY sip:90778...@62.12.226.231:22353;transport=tcp;line=h4r3sfjp
33.714055 95.128.80.8 -> 10.10.10.2 TCP sip > 48777 [ACK] Seq=4004 Ack=4085 Win=501 Len=0 TSV=2130354099 TSER=1701639288
33.717075 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=752, Time=135520
33.720258 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=9, Time=1600
33.737072 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=753, Time=135680
33.741074 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=10, Time=1760
33.757125 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=754, Time=135840
33.760830 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=11, Time=1920
33.777114 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=755, Time=136000
33.780428 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=12, Time=2080
33.797114 10.10.10.6 -> 10.10.10.2 RTP PT=ITU-T G.711 PCMU, SSRC=0x643C9869, Seq=756, Time=136160
33.801167 10.10.10.2 -> 10.10.10.6 RTP PT=ITU-T G.711 PCMA, SSRC=0x2F6BAC90, Seq=13, Time=2240
De : Oleg Kulikov [mailto:oleg.k...@gmail.com]
Envoyé : vendredi 27 janvier 2012 05:32
Oleg Kulikov
It means that order was changed during negotiation of format between mixers's output and rtp channel input. This is inside connection object physicaly. I assume it happens because during format negotiation (and codec selection) it scrolls through available codecs and takes first suitable by comparing input/output format pairs avaibale. So if PCMA is first in the list of codecs it takes PCMA. This is generic logic and it is implemented inside generic components classes (AbstrcatSource/AbstractSink).
So to fix the problem would be better to change this logic when format will be selected first and then try to find codec which matches to format pairs.
Oleg
Laurent Schweizer
Hi Oleg,
I have done a change in file :
spi/src/main/java/org/mobicents/media/server/spi/format/Formats.java
I have changed to short first on the “other.list” and then on the “list”
/**
* Find the intersection between this collection and other
*
* @param other the other collection
* @param intersection the resulting collection.
*/
public void intersection(Formats other, Formats intersection) {
intersection.list.clear();
for (Format f1 : other.list) {
for (Format f2 : list) {
if (f1.matches(f2)) intersection.list.add(f2);
}
}
}
And now I get the correct order in the function setFormats() of file component/src/main/java/org/mobicents/media/server/impl/AbstractSource.java
public void setFormats(Formats formats) throws FormatNotSupportedException {
System.out.println("source other format:" + formats.toString());
System.out.println("source internal format:" + supportedFormats.toString());
supportedFormats.intersection(formats, this.formats);
System.out.println("source result format:" + this.formats.toString());
if (dsp != null) {
dsp.setFormats(this.formats);
}
}
RESULT:
source other format:Formats{AudioFormat[PCMU,8000,8,mono],AudioFormat[PCMA,8000,8,mono]}
source internal format:Formats{AudioFormat[LINEAR,8000,16,mono],AudioFormat[pcma,8000,8,mono],AudioFormat[pcmu,8000,8,mono]}
source result format:Formats{AudioFormat[pcmu,8000,8,mono],AudioFormat[pcma,8000,8,mono]}
but I have still the same problem ! Any idea where they is another place where format are merged ?
for info I have also changed the test :
spi/src/test/java/org/mobicents/media/server/spi/format/FormatsTest.java
/**
* Test of intersection method, of class Formats.
*/
@Test
public void testIntersection() {
Formats f1 = new Formats();
Formats f2 = new Formats();
Formats f3 = new Formats();
AudioFormat pcma = FormatFactory.createAudioFormat("pcma", 8000, 8, 1);
AudioFormat linear = FormatFactory.createAudioFormat("linear", 8000, 16, 1);
f1.add(pcma);
f1.add(linear);
f2.add(linear);
f2.add(pcma);
f1.intersection(f2, f3);
assertEquals(2, f3.size());
assertTrue("linear expected", linear.matches(f3.get(0)));
}
De : Oleg Kulikov [mailto:oleg.k...@gmail.com]
Envoyé : lundi 30 janvier 2012 17:42
Oleg Kulikov
Let me explain in details what I had in mind. Take a look at the AbstractSource (..Sink):
/**
* Rebuilds the list of supported formats.
*/
protected void rebuildFormats() {
//rebuild list of supported formats
if (dsp == null) {
this.initFormats();
return;
}
//add formats wich are results of transcoding
Formats fmts = this.getNativeFormats();
supportedFormats.clean();
int fcount = fmts.size();
for (int i = 0; i < fcount; i++) {
supportedFormats.add(fmts.get(i));
for (Codec c : dsp.getCodecs()) {
if (c.getSupportedInputFormat().matches(fmts.get(i))) {
supportedFormats.add(c.getSupportedOutputFormat());
}
}
}
formats.clean();
formats.addAll(supportedFormats);
dsp.setFormats(formats);
}
Here is a logic for selecting codec required for transmission between source and consumer. How it works? From one hand we have formats natively supported by source and formats supported by consumer from other hand. If intersection between native formats of the source and formats supported by consumer is not empty set then, obvious, no need in any kind of transcoding and formats from intersection set can be used for transmission. Dsp instance will be equal to NULL in this case. And, if intersection is empty set then we can try to put codec in the middle and thus make this intersection not empty. Looking at the code above, we can see that the logic searches for the first codec with input format represented in the native format set of the source and output format represented in the consumer's format set. So the result depends from the order of codecs in the list (not from format order).
Example for your case:
native format for source: Linear PCM
order of codecs: pcma, pcmu
consumer formats (and order in the list) PCMU, PCMA and we assume that PCMU is preffered
Loop Iteration #1:
- pcma codec selected
- checking intersection between codec's input format and source native formats - result Linear PCM, not empty so making output format check
- checking intersection between codec's output format and consumer's format - result PCMA since PCMA is also in the list of supported formats so the second check is successful as well
- breaking loop
Finally we have selected PCMA even if PCMU format was preffered. To fix this problem I am offering to change loop order: select consumer format first and then check codec list (just change order of inner and outer loops). It must solve the problem
Regards,
Oleg