| Author |
|
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 08 2008 at 3:32pm | IP Logged
|
|
|
Hi again :)
We have run into some interesting audio distortion with latest engine. Now, the main cause seems to be coming from a PSTN carrier, which we are also taking up with them. However, we feel it also good to bring this matter up here.
We have uploaded an RTP stream coming from a PSTN gateway to the FTP area (hope you don't mind). This is using G729 CODEC (though, with PCMU codec, there is some distortion, but sounds a little different of course).
The reason why we bring this up (considering we are ery confident it is coming from PSTN side), is that there is a noticeable difference in the sound between different Lanscape builds. Using the pcap file as reference...
5.12.4.8: This build shows little distortion while playing the received G729 RTP packets. Except, at around 55 seconds into stream, there is an audible beeping/popping or something.
5.12.7.21: This build seems to greatly amplify the distortion, so that distortion previously not heard in old build, is now heard (after each spoken word, there is a noticeable beeping/popping). Sounds like some sort of broken silence detection coming from carrier side we are guessing. Though, it could be possible Lanscape engine is creating some of the distortion? Though, seems unlikely; it more likely seems the recent Lanscape build is imply amplifying whatever is there more so now than it used to.
It would be wonderful if you could take a look at this and confirm that it is not Lanscape generating any of this distortion. Also, maybe there is a way that new Lanscape engine could not amplify the distortion so much (we are going after PSTN carrier in regards to this matter, but also would be good to prevent this internally)?
We use SIPp tool to broadcast this packet dump to three User Agents:
Grandstream - Audio was audibly distorted only at end of capture stream, around 55 seconds.
Old Lanscape Client - Same as Grandstream
New Lanscape Client - In addition to the end (55 seconds) distortion, there is more distortion heard through out the call.
We hope that is detailed enough information. We are glad to provide any other details.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 11 2008 at 10:57am | IP Logged
|
|
|
Juice:
We briefly looked at the Ethereal log you uploaded.
We can see that the PSTN gateway provider is using a Cisco IOS VOIP Gateway. We can see this from the RTCP packets that were in your Ethereal capture.
The first thing we noticed right away that is very odd is the fact that G729 RTP payloads coming from the PSTN are not all a consistent number of bytes (20Ms frame sizes).
We assume the SIP for the call negotiated G729 20Ms frame sizes.
For a call that uses G729 @ 20Ms per frame, the RTP G729 payloads should always be 40 bytes per UDP frame. The media engine can handle incoming G729 RTP frame sizes of 20Ms, 40Ms, 60Ms, … any multiple of 20Ms as set by the ptime parameter in the SIP SDP. Another way of looking at this is, each RTP packet should contain 20 bytes of G729 data for 20Ms payloads.
Here is the break down of the packet sizes:
8 Bytes UDP header + 12 Bytes RTP header + 20 Bytes G729 data = 40 Bytes.
From your RTP Ethereal capture data, we see:
Code:
Frame #, Number of RTP bytes
--------------------------------------------
46 2
.
.
.
150 2
151 2
.
.
.
179 2
180 2
181 2
182 2
183 2
184 2
185 2
186 20 (OK)
187 2
188 2
189 2
190 2
191 2
192 2
193 2
194 2
195 2
196 2
.
.
.
etc…
|
|
|
It does not look like the interleaved RTCP protocol data is causing an issue.
If the media engine does not receive 20Ms worth of G729 data per RTP packet, that will generate audio that is noisy and sounds like crap.
If you can get to the bottom of why the RTP number of bytes is not a consistent 20 bytes of data, you should have your solution. We will want you to pass this info along to us so that we may improve the media engine as needed.
One thing you might want to do right away is to take your VOIP media engine app and allow it to intercept all raw RTP payloads coming from the PSTN. You do this by registering a callback handler for each phone line. See the developer’s reference for the EnableRawRtpPacketAccess() API proc.
In your RTP callback handler, monitor the RTP packets being received by the media engine. Monitor the size in bytes (SampleBufferLengthInBytes, it should always be 20 bytes) and the “payload type” (pRtpHeader->PayloadType) to make sure it is always a value of 18 (i.e. G729).
If any of the above tests fail, then you will most likely have identified the cause of the distortion. One thing to do is simply filter out the offending RTP packets and see what results you get. Sounds like you may have to talk to Cisco and/or the PSTN provider to see why their gateway product does this.
Please answer this question:
We assume the distortion is only experienced when receiving RTP data from the PSTN – Correct?
Please report your finding when you can.
Thanks,
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 11:15am | IP Logged
|
|
|
Hi,
Thanks for the information, we will add some checks in the RTP callback. And provide more information as we find it.
In regards to your question, yes we only hear/experience this distortion when making calls through one particular PSTN carrier.
The main reason for raising this issue here, is the previous Lanscape engine seems more tolerant and does not amplify this noise (with the previous build, there is a bit of audible distortion, but not nearly as much as with recent build). We were figuring it was some sort of malformed RTP packet. Since the audio distortion seems to be the biggest when audio silence is detected, it is likely as we first assumed: some kind of broken silence detection sending malformed data. We should be able to, as you suggest, simply try dropping the packets.
We will use the information you posted and report back the final verdict, or any questions we may have.
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 11:18am | IP Logged
|
|
|
>> You
We assume the distortion is only experienced when receiving RTP data from the PSTN – Correct?
<< Us
Actually, to expand on the question. We see the distortion just from the PSTN carrier (other SIP to SIP calls are perfect). But, since the distortion is decoded into audio, we transmit this distortion out (amplified with latest build) to the other side (whether that is SIP or back out to PSTN). Also note, we use the cross the lines method (not latest conference bridging) to mix the audio between in and out legs.
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 1:56pm | IP Logged
|
|
|
Ok, so we found one odd thing. Using the advise above, we added some code to check for Buffer Size != 20 bytes when payload type is 18 (G729). (For reference we already have/had some code for RTP detection in regards to 101 Payload type, and that is working).
So, the block of code that checks for Payload 18 gets hit (as verified with debugger), but the block of code checking for != 20 never gets hit (as verified by debugger, value is always 18).
That may sound good, but the problem seems to be still here. The beeping noise after a person stops talking (sometimes while a person is talking). And, looking at Wire captures, there are indeed places where payload size is not 20 bytes. The good portions of audio seem to have 20 bytes of payload data, but after done talking, the PSTN carrier is transmitting between 2, 4, or a bit more bytes. I suppose this is where the distortion is coming into the stream.
So, for some reason, Lanscape is not sending our callback those RTP packets that are not 20 bytes - so we have no chance of dropping them. Any idea why not?
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 1:59pm | IP Logged
|
|
|
It could be possible Lanscape engine has padded the Payload buffer bytes to 20? Or that we are just never sent these particular packets for whatever reason.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 11 2008 at 3:06pm | IP Logged
|
|
|
Juice,
We screwed up in the previous post. The values you want to use from the RAW_RTP_DATA structure to detect less than a full frame size of RTP are:
SampleBufferLengthInBytes
RtpPacketLengthInBytes
We just updated the dev reference to explain this better. Here is the new text:
SampleBufferLengthInBytes:
The number of bytes expected in the sample buffer. This value corresponds to the number of bytes per RTP payload as negotiated by SIP when the call was set up. For example, if the call was set up to use 20Ms frames of G729, then this value would represent the number of bytes in one full frame (20Ms) of G729 encoded audio. To obtain the actual number of RTP packet bytes received from the network, see the RtpPacketLengthInBytes member of this structure.
RtpPacketLengthInBytes:
The total number of bytes in the RTP packet. This represents the actual number of RTP packet bytes read from the network. This value is the sum of the RTP header length (RtpHeaderLengthInBytes) + received RTP payload bytes.
If (RtpPacketLengthInBytes != 20) for a G729 20Ms call, then the RTP packet is suspect.
That should work better…
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 3:32pm | IP Logged
|
|
|
No problem :)
We added the check for RtpHeaderLengthInBytes == 20. However, it was never 20, but normally 32. I think that is probably 20 bytes payload and the rest header bytes.
When we added a check for != 32 drop packet, the beeping went away! Yes. I see that bad packets range from 14 to 24 (using the header byte size as reference).
We can add this check to our build, but would be good if Lanscape could ignore malformed packets internally in engine. I assume there was some kind of ignoring going on with previous Lanscape build since the issue does not arise so greatly with that engine.
Ok, so to be clear, this value is only good for 20 ms G729 CODEC issue. We see that by default, at least, Lanscape engine is always sending out ptime = 20 ms. Does that correspond to the settings we chose for internal audio type for each line? Don't want to hard code some value that changes... The carrier side is not returning a ptime SDP header... perhaps this is part of the problem, maybe they have sort of variable width CODEC. Odd, will have to take this up with them. Perhaps after doing some Googling to see what is standard (so we can complain to them for doing this to us :))
We also heard some (different noise) with PCM data, so maybe they are doing the same thing there with different sized Packets. We will have to test that now.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 11 2008 at 4:02pm | IP Logged
|
|
|
Juice,
You >>>
We added the check for RtpHeaderLengthInBytes == 20. However, it was never 20, but normally 32. I think that is probably 20 bytes payload and the rest header bytes.
<<< Support
I think you mean a different structure variable (i.e. RtpPacketLengthInBytes).
RtpHeaderLengthInBytes: This should always be set to 12 for version 2.0 RTP packets.
SampleBufferLengthInBytes: This is the expected number of audio sample payalod bytes in the RTP packet. This does not include the size of the RTP header (12 bytes).
RtpPacketLengthInBytes: The absolute number of bytes read from the network for the RTP frame (RTP header + all sample bytes). This value should always be 32 bytes for complete 20Ms frame size G729 media. This is 12 bytes of RTP header and 20 bytes of encoded audio (G729) data.
So it is a no-brainer, you can do something like the following in your app. It will take care of all supported codecs and frame sizes:
Code:
If(RtpPacketLengthInBytes != (RtpHeaderLengthInBytes + SampleBufferLengthInBytes))
{
// dump the received RTP packet.
// Its not the right size!
}
.
.
.
|
|
|
You >>>
Ok, so to be clear, this value is only good for 20 ms G729 CODEC issue. We see that by default, at least, Lanscape engine is always sending out ptime = 20 ms. Does that correspond to the settings we chose for internal audio type for each line?
<<< Support
Yes exactly.
We really need to know what those “sub-sized” RTP packets are for and why is Cisco sending them from the IOS gateway.
Right now, the media engine will take sub-sized RTP frames and try to process them as full frames… and that will be where the garbage audio creeps in. Note also that no filtering of sub sized RTP frames ever existed in the media engine.
I think we may want to add a new event that at least would notify the application of this detection.
Keep posting with whatever additional information you find.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 11 2008 at 4:11pm | IP Logged
|
|
|
You're right, I meant RtpPacketLengthInBytes.. Copy & Paste error.
Yes, we have emailed the details of the variable sized payload of RTP for the G729 CODEC (might also be happening with other CODECs of course) to the carrier and expect to hear back from them. I suppose they will know what they are sending and why. To me, it looks like garbage. And the fact that it only happens during low audio/silence periods to me seems to support that. You would think, silence detection would simply send less often, not send reduced packets. Anyway, we will write back with what their response is as to why.
I don't know if you have tried to run these packets through the media engine to see what it sounds like, but it sounds completely different based on the two versions of the media engine. The old version simply seems to ignore it (or at least tolerates it) while the newest build will produce the audible distortion. Which is why I assumed that there was some check in place before. If not, I wonder why it sounds different now.
Anyways, I'l luse the check you suggested for now for a least dropping these packets until we figure out what they are there for.
Thanks.
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 12 2008 at 12:00pm | IP Logged
|
|
|
We received a response from the carrier:
"I see that the codec negotiated is G729, and the gateway has Comfort noise embedded. It is important that your equipments do support comfort noise otherwise, you are going to continue to get the garbled noise."
Any idea the best way to handle this comfort noise besides just dropping the packets? We're still looking into this, as we haven't heard of comfort noise before in this regard.
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 12 2008 at 2:48pm | IP Logged
|
|
|
Juice,
Since yesterday we have had some time to think regarding. RTP comfort noise (CN) was one of the possibilities we discussed here.
Comfort noise generally is used to lower bandwidth when no other speech is going on in the media channel. The comfort noise allows the media channel to “sound” as if it is not completely dead (complete silence) when no audio is traversing the media channel.
Without getting into to much detail, you should be able to drop the CN RTP packets without too huge of an impact on your sonic quality.
The one thing we think is a bit of a rub however is that it appears that the Cisco equipment your PSTN provider has deployed is using G729 annex B with comfort noise. You should probably post the SIP log for a connection to the PSTN so we can look at it. The VOIP Media Engine negotiates straight G729. Strictly speaking, if G729 annex B and comfort noise is not negotiated in the SIP call setup, it should not be used for the call. Hmmm…. We have to think….
Post any further info you may find.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 12 2008 at 5:01pm | IP Logged
|
|
|
Hi Support,
Thanks for the description, we also read up on it and figured that comfort noise would be a good thing to have (if it worked) as it makes the audio sound more natural (with some background noise, people are less likely to stop and ask if the other person is still on the line :)). However, for now, dropping the packets has at least make the audio quality good.
We notice that the same carrier IP/gateway is sometimes announcing annexb=no and sometimes annexb=yes but seems all the time our sending the comfort noise (not 100% certain, but all calls I tested before implementing the drop packet routine had this noise in them anyway).
Code:
>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#3, 297 Ms, To: 127.0.0.1:5060) >>>>
INVITE sip:18584370711@127.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>
Contact: <sip:marry.doe@127.0.0.2:5060>
Call-Id: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 INVITE
Max-Forwards: 70
Organization: CB66E23C-A0DD-4BDF-A05F-08C7F98E86B4
Content-Length: 236
User-Agent: LanScape VOIP Media Engine/5.12.7.21 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=marry.doe 271350593 271350593 IN IP4 127.0.0.2
s=LanScape
c=IN IP4 127.0.0.2
t=0 0
m=audio 8102 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=ptime:20
a=fmtp:101 0-15
<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#2, 375 Ms, From: 127.0.0.1:5060) <<<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>
Call-ID: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 INVITE
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#3, 8235 Ms, From: 127.0.0.1:5060) <<<<
SIP/2.0 183 Session Progress
To: <sip:18584370711@127.0.0.1>;tag=3411755373-379853
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
Contact: <sip:18584370711@127.0.0.1:5060>
Call-ID: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 INVITE
Content-Type: application/sdp
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
Content-Length: 213
v=0
o=prxnyc02 0 0 IN IP4 127.0.0.1
s=sip call
c=IN IP4 216.168.177.168
t=0 0
m=audio 29670 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#4, 1312 Ms, From: 127.0.0.1:5060) <<<<
SIP/2.0 200 OK
To: <sip:18584370711@127.0.0.1>;tag=3411755373-379853
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
Contact: <sip:18584370711@127.0.0.1:5060>
Call-ID: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 INVITE
Content-Type: application/sdp
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
Content-Length: 213
v=0
o=prxnyc02 0 0 IN IP4 127.0.0.1
s=sip call
c=IN IP4 216.168.177.168
t=0 0
m=audio 29670 RTP/AVP 18 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#4, 9609 Ms, To: 127.0.0.1:5060) >>>>
ACK sip:18584370711@127.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>;tag=3411755373-379853
Call-Id: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 ACK
Max-Forwards: 70
Route: <sip:18584370711@127.0.0.1>
User-Agent: LanScape VOIP Media Engine/5.12.7.21 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#7, 47 Ms, To: 127.0.0.1:5060) >>>>
BYE sip:18584370711@127.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102d560d
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>;tag=3411755373-379853
Call-Id: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925239 BYE
Max-Forwards: 70
User-Agent: LanScape VOIP Media Engine/5.12.7.21 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRxRx (#7, 125 Ms, From: 127.0.0.1:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102d560d
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>;tag=3411755373-379853
Call-ID: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925239 BYE
Content-Length: 0
|
|
|
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 12 2008 at 8:18pm | IP Logged
|
|
|
Juice,
Thanks for the SIP log. The annexb=no in the SIP should be all we need to see and guarantee that G729 or G729A is used instead of G729 annex B when the call is initiated by your media engine bridge/PSTN application. Maybe the Cisco guys have to go back to SIP school…. :)
Hmm… not sure what we should do about this…
We have made a note about supporting G729B in the media engine.
Any other info you post is appreciated.
Good job as always,
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 13 2008 at 11:43am | IP Logged
|
|
|
Hi support,
Yes, they indicate in this log that they are not trying annexb. However, other SIP dialogs come back saying annexb=yes. Regardless, seems they will send these comfort noise packets in either case (at least, from previous tests it appears that way).
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 13 2008 at 12:12pm | IP Logged
|
|
|
Juice,
Just thought of something. If you can, perform a test:
Modify the media engine INVITE that gets transmitted to the PSTN provider to add the “annexb=no” format descriptor to the SDP. For example:
Code:
>>>> TxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTxTx (#3, 297 Ms, To: 127.0.0.1:5060) >>>>
INVITE sip:18584370711@127.0.0.1 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.2:5060;rport;branch=z9hG4bK102ce1c2
From: TESTING <sip:marry.doe@127.0.0.2>;tag=102c9e34
To: <sip:18584370711@127.0.0.1>
Contact: <sip:marry.doe@127.0.0.2:5060>
Call-Id: 3654020a-205d-465c-b624-5851fe737584-00000df4@127.0.0.2
CSeq: 2925238 INVITE
Max-Forwards: 70
Organization: CB66E23C-A0DD-4BDF-A05F-08C7F98E86B4
Content-Length: 236
User-Agent: LanScape VOIP Media Engine/5.12.7.21 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=marry.doe 271350593 271350593 IN IP4 127.0.0.2
s=LanScape
c=IN IP4 127.0.0.2
t=0 0
m=audio 8102 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=ptime:20
a=fmtp:18 annexb=no
a=fmtp:101 0-15
|
|
|
This “should” force the other side to not use G729 annex B.
Its worth a try. If it fixes things, we will update the media engine right away.
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 13 2008 at 5:27pm | IP Logged
|
|
|
Hi Support
Adding that to SDP does seem to force the carrier gateway to also respond no. And it does not send the comfort noise packets afterwards. Excellent, would be awesome to have that added to the engine. Of course, we'll probably leave the check in for malformed packet sizes (for now) to prevent any issues in the future.
Thanks
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 14 2008 at 8:21am | IP Logged
|
|
|
Juice,
We reviewed the docs for “Cisco IOS Software Releases 12.2 T”. It appears that depending on the configuration of the Cisco software for the gateway, they will default to using G729 Annex B. From the Cisco docs:
Code:
Cisco implements support for multiple G729 codec versions by using a=fmtp and a=rtpmap attributes in the SDP body of outgoing INVITE requests. For the G729 codec, the value of a=fmtp is 18 (the IANA assigned static value), and the annexb value is either yes or no. The default for annexb is yes.
|
|
|
Here is the link:
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t11/feature/gu ide/ftcodec.html
If one side of the call initiates with “annexb=yes” and the “200 OK” response comes back with “annexb=no”, then the initiating side of the call is supposed to “dumb down” to using G729 or G729A which are bitstream compatible.
We will update the media engine to specifically state “annexb=no“ in INVITE requests and “200 OK” INVITE responses until we decide to fully support G729B. This way we will not have future issues.
Thanks,
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 14 2008 at 9:24am | IP Logged
|
|
|
Seeing we were on the subject, we decided to update the media engine immediately to support the annexb format descriptor. Below is the SIP log of a media engine soft phone calling another media engine soft phone through the LanScape SIP Centrex proxy server. This product change will be included in your next software update.
Code:
************* Log Opened (Feb 14 09:12:32) *************
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#3, 15156 Ms, To: 192.168.1.2:5060) >>>>
INVITE sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK0080a726
From: "Test Phone" <sip:333@ps>;tag=80926c;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Contact: <sip:333@192.168.1.2:5066>;x-inst="VGVzdCBDYWxsIERhdGE gZnJvbSB0aGUgVlBob25lIGFwcC4="
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410952 INVITE
Max-Forwards: 70
Organization: 2456E5FD-DC94-417D-BDF7-55A654EFB9E5
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 242
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=333 8400859 8400859 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 20002 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20
a=fmtp:101 0-16
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#3, 15172 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.2:5066;rport=5066;branch=z9hG4bK0080a726;received= 192.168.1.2
From: "Test Phone" <sip:333@ps>;tag=80926c;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410952 INVITE
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#4, 0 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.2:5066;rport=5066;branch=z9hG4bK0080a726;received= 192.168.1.2
From: "Test Phone" <sip:333@ps>;tag=80926c;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410952 INVITE
Proxy-Authenticate: Digest realm="ps", nonce="c3088e23419a6812f01fa4f05d3f41c3", opaque="b5c4535e98a73ea59a9e9e26072da90a"
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#4, 31 Ms, To: 192.168.1.2:5060) >>>>
ACK sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG 4bK0080a726
From: "Test Phone" <sip:333@ps>;tag=80926c;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410952 ACK
Max-Forwards: 70
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#5, 16 Ms, To: 192.168.1.2:5060) >>>>
INVITE sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK0080a755
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Contact: <sip:333@192.168.1.2:5066>;x-inst="VGVzdCBDYWxsIERhdGE gZnJvbSB0aGUgVlBob25lIGFwcC4="
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410999 INVITE
Max-Forwards: 70
Organization: 2456E5FD-DC94-417D-BDF7-55A654EFB9E5
Proxy-Authorization: Digest algorithm=md5,nonce="c3088e23419a6812f01fa4f05d3f41c3",opaqu e="b5c4535e98a73ea59a9e9e26072da90a",realm="ps",response="9b a822c42f355628f0745f34a154e8eb",uri="sip:111@ps",username="g uest"
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 242
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
v=0
o=333 8400906 8400906 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 20002 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20
a=fmtp:101 0-16
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#5, 46 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.2:5066;rport=5066;branch=z9hG4bK0080a755;received= 192.168.1.2
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410999 INVITE
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#6, 47 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG 4bK0080a755
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410999 INVITE
x-customheader-extension-111: "This is a modified transmitted SIP message."
x-phoneline: 0
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#7, 1032 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG 4bK0080a755
Record-Route: <sip:192.168.1.2>
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410999 INVITE
Contact: <sip:111@192.168.1.80:5094>
x-customheader-extension-111: "This is a modified transmitted SIP message."
x-phoneline: 0
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Allow: INVITE, ACK, OPTIONS, BYE, CANCEL, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 253
v=0
o=LanScape 2147483647 2147483647 IN IP4 192.168.1.2
s=LanScape
c=IN IP4 192.168.1.2
t=0 0
m=audio 16002 RTP/AVP 18 101
a=rtpmap:18 G729/8000/1
a=rtpmap:101 telephone-event/8000/1
a=sendrecv
a=fmtp:18 annexb=no
a=ptime:20
a=fmtp:101 0-16
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#6, 1094 Ms, To: 192.168.1.2:5060) >>>>
ACK sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG 4bK0080a755
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8410999 ACK
Max-Forwards: 70
Route: <sip:192.168.1.2>,<sip:111@192.168.1.80:5094>
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#7, 3187 Ms, To: 192.168.1.2:5060) >>>>
BYE sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK00805605
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8411000 BYE
Max-Forwards: 70
Route: <sip:192.168.1.2>,<sip:111@192.168.1.80:5094>
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#8, 3203 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 407 Proxy Authentication Required
Via: SIP/2.0/UDP 192.168.1.2:5066;rport=5066;branch=z9hG4bK00805605;received= 192.168.1.2
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8411000 BYE
Proxy-Authenticate: Digest realm="ps", nonce="c3088e23419a6812f01fa4f05d3f41c3", opaque="270de6af58a7c2957a4def547ccc7703"
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
>>>> TxTxTxTxTxTxTxTxTxTxTxTx (#8, 16 Ms, To: 192.168.1.2:5060) >>>>
BYE sip:111@ps SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:5066;rport;branch=z9hG4bK0080441b
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-Id: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8411001 BYE
Max-Forwards: 70
Proxy-Authorization: Digest algorithm=md5,nonce="c3088e23419a6812f01fa4f05d3f41c3",opaqu e="270de6af58a7c2957a4def547ccc7703",realm="ps",response="76 7e19beae775ee1154e015a5ed2bb62",uri="sip:111@ps",username="g uest"
Route: <sip:192.168.1.2>,<sip:111@192.168.1.80:5094>
User-Agent: LanScape VOIP Media Engine/5.12.8.1 (www.LanScapeCorp.com)
x-CustomHeader-Extension-333: "This is a modified transmitted SIP message."
x-PhoneLine: 0
Content-Length: 0
<<<< RxRxRxRxRxRxRxRxRxRxRxRx (#9, 15 Ms, From: 192.168.1.2:5060) <<<<
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:5066;received=192.168.1.2;rport=5066;branch=z9hG 4bK0080441b
From: "Test Phone" <sip:333@ps>;tag=80929b;x-UaId=xxxxx-yyyy-zzzzzz
To: <sip:111@ps>;tag=b93d544
Call-ID: 6758e409-816f-4b7b-8340-cba41f7fea13-00000568@192.168.1.2
CSeq: 8411001 BYE
x-customheader-extension-111: "This is a modified transmitted SIP message."
x-phoneline: 0
Server: LanScape Centrex Proxy/3.42.2.8 (www.LanScapeCorp.com)
Content-Length: 0
************* Log Closed (Feb 14 09:12:48) *************
|
|
|
Support
|
| Back to Top |
|
| |
juice
Vetran
Joined: December 05 2006
Location: United States
Posts: 139
|
| Posted: February 15 2008 at 1:57pm | IP Logged
|
|
|
Awesome. Thanks for the heads up :)
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: Audio Distortion
