[Sip] Different payload type offer-answer
Fuxbruner Amihay <Amihay_Fuxbruner@icomverse.com> Wed, 07 August 2002 10:44 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12175 for <sip-archive@odin.ietf.org>; Wed, 7 Aug 2002 06:44:44 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA02854 for sip-archive@odin.ietf.org; Wed, 7 Aug 2002 06:45:57 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01537; Wed, 7 Aug 2002 06:15:29 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA01506 for <sip@optimus.ietf.org>; Wed, 7 Aug 2002 06:15:26 -0400 (EDT)
Received: from il-tlv-smtpout2.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11684 for <sip@ietf.org>; Wed, 7 Aug 2002 06:14:10 -0400 (EDT)
Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout2.icomverse.com (8.11.6/8.11.6) with ESMTP id g77ADBp02672; Wed, 7 Aug 2002 13:13:11 +0300
Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id <PPSPKCSY>; Wed, 7 Aug 2002 13:13:18 +0300
Message-ID: <32B823C1CD4FD5119C0D0002A560F78E079BC364@ismail3.comverse.com>
From: Fuxbruner Amihay <Amihay_Fuxbruner@icomverse.com>
To: sip-implementors@cs.columbia.edu, sip@ietf.org
Cc: Neitman Ludmila <Ludmila_Neitman@icomverse.com>, Barth Matan <Matan_Barth@icomverse.com>
Date: Wed, 07 Aug 2002 13:13:16 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C23DFB.0BCFB9E6"
Subject: [Sip] Different payload type offer-answer
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Hi all, draft-ietf-mmusic-sdp-offer-answer-02 section 5.1 reads the following: However, for sendonly and sendrecv streams, the answer might indicate different payload type numbers for the same codecs, in which case, the offerer MUST send with the payload type numbers from the answer. How should the offerer react in case he can not change the payload type ? This looks strange since the call was established with initial media problems. Thanks, Amihay Fuxbruner System Engineering - Signaling R&D Comverse
- [Sip] Different payload type offer-answer Fuxbruner Amihay