Thanks Gents, I'm sorry my terminology has caused confusion. However The responses received have clarified things for me. Seems the vendor is not in violation of the standard, just not implementing the solution well. I'll try another tack to get the way they handle the codec negotiation modified.
I appreciate your patience & assistance. -----Original Message----- From: Worley, Dale R (Dale) [mailto:dwor...@avaya.com] Sent: Saturday, 2 July 2011 5:25 AM To: Johnson, Michael A; sip-implementors@lists.cs.columbia.edu Subject: RE: Re-Invite codec renegotiation. > 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. The PBX "accepts" this response (in some manner that you don't describe) and sends ACK. 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.) At this point, the PBX has a number of available choices: - Leave the signaling in the current state, but not send/receive RTP. - Send a BYE to terminate the dialog. - Send a re-INVITE with SDP offering a codec that it can support, and hope that the ISP accepts it. - Send a separate INVITE-with-Replaces directed to the dialog at the ISP, offering the codecs that it is willing to use. The ISP could reject the INVITE-with-Replaces, but in most cases, this INVITE has a higher chance of succeeding than a re-INVITE. Note that only the first two are guaranteed to succeed (from a SIP signaling point of view), but only the last two (if they succeed) will result in a working media connection. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
