On 7/1/2011 5:12 PM, Kevin P. Fleming wrote:
> On 07/01/2011 02:24 PM, Worley, Dale R (Dale) wrote:
>>> From: Johnson, Michael A [michael.a.john...@team.telstra.com]
>>>
>>> The PBX (Mitel) that sends the re-invite without SDP, that then
>>> accepts the offered G.729 codec from the ISP, despite not being able
>>> support the codec is the device I believe is as fault. The
>>> manufacturer however disagrees.
>>
>> You're still not being clear, but it's clear enough that I can
>> understand what you're talking about. You are saying:
>>
>> The PBX sends an re-INVITE without SDP.
>>
>> The ISP sends a 200 response with SDP.
>
> If I'm following correctly, this offer includes G.729 and G.711.
>
>> The PBX "accepts" this response (in some manner that you don't
>> describe) and sends ACK.
>
> The PBX includes an SDP answer in this ACK (as it must), but incorrectly
> (because of its own limitations) includes G.729 in the answer.
>
>>
>> You consider this to be a fault on the part of the PBX, but you
>> don't specify why.
>>
>> I believe your misunderstanding is in regard to the PBX sending the
>> ACK. The PBX does not "accept" the 200 response. It receives the 200
>> response and *must* then send an ACK. There is no way for it to
>> "reject" the response. (This has been discussed in many contexts,
>> which I'm too lazy to look up right now.)
>
> I would think that if the PBX only included G.711 in its SDP answer
> (included in the ACK), all would be well.
>
That would seem to be the case.
The PBX is not "wrong" it what it is doing, but it is *stupid* and
counterproductive.
Having accepted the the offer, it is generally obligated to accept or
ignore the incoming packets. It is not obligated to send any, even if
the stream is sendonly or sendrecv. It is not obligated to play the
received packets out to its user. (It can't if it doesn't support the
codec.)
(I guess in this case it is being a music on hold server, and so would
otherwise send media.)
This is a quality of implementation issue, rather than a protocol issue.
Presumably what you are complaining about is that you want to hear music
on hold, and you are getting silence instead. (Is that right?)
Presumably the customers of this PBX should be annoyed that their
callers aren't getting music on hold. I guess they are complaining to
the SP, and now the question is: who should fix this. Right?
Obviously there are a number of fixes:
- the PBX could include an offer in its invite, with the codecs
it actually supports
- the PBX could, as mentioned in this thread, return an answer that
only includes G.711, since that is all it supports in this context.
- the SP could somehow infer that it should only offer G.711, even
though it also supports G.729.
While the latter would fix the problem, it would lead to other problems.
How would it decide to do this? I guess it could restrict its offer to
the codec in use prior to the reinvite. (I've lost track, but I thought
the problem was that G.729 was in use for the active call, but isn't
supported by the MOH server. If so, that isn't a solution.)
The problem is that doing so is only a good thing in this one particular
case. There are other call flows that start out the same, that will
*break* if all the supported codecs aren't returned in the offer.
IMO, based on my limited understanding of this case, the PBX has nobody
but itself to blame for the MOH not working.
Thanks,
Paul
_______________________________________________
Sip-implementors mailing list
Sip-implementors@lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
