Codec предпочтение в глотка переговоров (SDP)

Question

чей кодек получает предпочтение в следующем сценарии

Предполагая, что Caller посылает INVITE SDP предпочтение:

1) Кодек A 2) Codec B

Теперь вызываемая сторона отправляет 200 OK SDP с предпочтением:

1) кодек B 2) Codec A

Будет C приоритет кодека aller получает предпочтение (Codec A получает согласование), или кодек Callee получает предпочтение (Codec B становится предметом переговоров).

Также будет отправлено Re-invite для блокировки кодека?

Answer 1

Из моего многолетнего опыта, что я видел, это 200 OK от вызываемого абонента, имеющего выбранный SDP в 200 OK. Таким образом, избиратель выбирает.

Из SDP предложение ответ ЗП .. https://www.ietf.org/rfc/rfc3264.txt

В этой модели один из участников сеанса генерирует сообщение SDP, что представляет собой предложение - набор медиа-потоков и кодеки оферентом пожелания для использования вместе с IP-адресами и портами оферент хотел бы использовать для приема носителя. Предложение передано другому участнику, названному ответчиком. Ответчик генерирует ответ, который представляет собой сообщение SDP, которое отвечает на предложение , предоставленное оферентом. Ответ имеет подходящий носитель поток для каждого потока в предложении, указывающий, принят ли поток , а также кодеки, которые будут использоваться, и адреса и порты IP-адреса и портов, которые респондент хочет использовать для приема медиа.

Далее ...

После того, как запросчик послал предложение, он должен быть готов получить носитель для любых RecvOnly потоков, описываемых этим предложением. Он ДОЛЖЕН быть подготовлен для отправки и приема медиа для любых потоков sendrecv в предложении и отправки медиа для любых потоков отправления в предложении (курс , он не может фактически отправить, пока партнер не даст ответ с необходимым адресом и информация о порту). В случае RTP, , даже если он может получать носитель до получения ответа, он будет не сможет отправлять отчеты приемника RTCP до получения ответа.

Answer 2

Согласно RFC4317 (во втором примере), согласование кодека еще не закончено. Второе предложение должно предоставляться вызывающим абонентом и блокировать кодек, например SDP, в другом запросе ACK. Повторное приглашение не требуется.

RFC4317:

"Alice can support PCMU, PCMA, and iLBC codecs, but not more than one 
    at the same time. Alice offers all three to maximize chances of a 
    successful exchange, and Bob accepts two of them. An audio-only 
    session is established in the initial exchange between Alice and Bob, 
    using either PCMU or PCMA codecs (payload type in RTP packet tells 
    which is being used). Since Alice only supports one audio codec at a 
    time, a second offer is made with just that one codec, to limit the 
    codec choice to just one." 

https://tools.ietf.org/html/rfc4317

Но все SIP платформ, к сожалению, не подчиняются этому поведению, по крайней мере, в одном я использую прямо сейчас. Это зависит от того, какую платформу SIP/IPPBX вы используете.