Hide
Is some scenarios it is possible for the park server to receive a re-INVITE. When this happens ,the park server 200 OK's the re-INVITE and then terminates the call by sending a BYE request. The park server should be able to handle re-INVITEs without releasing the call. The following is an illustration of one specific scenario in which it is necessary for the Park Server to handle re-INVITEs:
When the park server receives an INVITE with an SDP offer advertising multiple codecs, it sends a 200 OK with an SDP answer advertising *all* the offered codecs - this behavior opens the door to asymmetric codecs. If the calling endpoint knows that it cannot handle asymmetric codecs, it should send a re-INVITE to preform the codec lock-down procedure described in RFC3264 section 10.2. The problem is that the park server cannot cope with such a re-INVITE and sends a BYE to terminate the call.
Please see attached trace that provides an example of the scenario described above.
Show
Is some scenarios it is possible for the park server to receive a re-INVITE. When this happens ,the park server 200 OK's the re-INVITE and then terminates the call by sending a BYE request. The park server should be able to handle re-INVITEs without releasing the call. The following is an illustration of one specific scenario in which it is necessary for the Park Server to handle re-INVITEs:
When the park server receives an INVITE with an SDP offer advertising multiple codecs, it sends a 200 OK with an SDP answer advertising *all* the offered codecs - this behavior opens the door to asymmetric codecs. If the calling endpoint knows that it cannot handle asymmetric codecs, it should send a re-INVITE to preform the codec lock-down procedure described in RFC3264 section 10.2. The problem is that the park server cannot cope with such a re-INVITE and sends a BYE to terminate the call.
Please see attached trace that provides an example of the scenario described above.
Bug
Open
Major
