Hello,
Hi Gang
Parallel forking situation.
A => B
A => C
A invites with g711,g722 which is forked to B and C
B reports ringing by sending 183 + SDP g711
C report 180 ringing.
C establishes connection 200 OK + SDP g722
https://www.rfc-editor.org/rfc/rfc3261.html#page-78
o If the initial offer is in an INVITE, the answer MUST be in a
reliable non-failure message from UAS back to UAC which is
correlated to that INVITE. For this specification, that is
only the final 2xx response to that INVITE. That same exact
answer MAY also be placed in any provisional responses sent
prior to the answer. The UAC MUST treat the first session
description it receives as the answer, and MUST ignore any
session descriptions in subsequent responses to the initial
INVITE.
Now we run into the situation in which A received the 183 g711 and
being RFC compliant, dropped the 2nd SDP from the 200 OK.
=> No audio!
Has anyone encountered this situation and found a nice solution? Like
generating an UPDATE or RE-INVITE towards A to change the codec in
an RFC compliant way after the call is established?
Or is the only solution to remove all codecs except the required g711a
one when more than one contact are registered on an AOR?
this is a common scenario and the UAC (the phone) should be able to cope with it.
By parallel forking, there will be two different To-tags, so practically during the call setup, the UAC has to maintain two different (early-state) dialogs, when one is answered with 200ok, the other one is cancelled.
If the UAC that you use doesn't support parallel forking by downstream proxies, then either you replace it with a capable one; configure it with a single codec; as you suggested, strip codecs on proxy leaving a single option; or route first via a transcoding system.
Cheers, Daniel
-- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com