Let me retype Shinji's examples since there are some minor typos in
them:
O1 (A)
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000
A1 (B)
m=audio 49170 RTP/AVP 0 4
a=rtpmap:0 PCMU/8000
a=rtpmap:4 G723/8000 <- "implicit-recvonly"
This may result in asymetric operation (if A chooses
Hi Paul,
comment inline.
Paul Kyzivat
>OKUMURA Shinji wrote:
>> Hi Mr. Kyzivat,
>
>Please, lets not be formal. Call me Paul. :-)
>
>> If the direction of the answer is "recvonly" or "inactive", it is
>> no problem that the answerer adds new codec. But if the direction
>> is "sendrecv" ("sendonly
according rfc3264, the answer maybe same or different as the previous
answer.
rfc3264:
The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous
OKUMURA Shinji wrote:
> Hi Mr. Kyzivat,
Please, lets not be formal. Call me Paul. :-)
> If the direction of the answer is "recvonly" or "inactive", it is
> no problem that the answerer adds new codec. But if the direction
> is "sendrecv" ("sendonly" is certainly not allowed), the added
> codec
Title: Samsung Enterprise Portal mySingle
Its a session refresh re-Invite and you should respond with the
same answer...
Thanks,
Neeraj Jain
--- Original Message ---Sender : ???Date : Aug 19, 2009 16:28 (GMT+09:00)Title : [SIPForum-discussion] how to response the offer
Dear Al
Hi Mr. Kyzivat,
If the direction of the answer is "recvonly" or "inactive", it is
no problem that the answerer adds new codec. But if the direction
is "sendrecv" ("sendonly" is certainly not allowed), the added
codec is "implicit-recvonly".
The offerer MAY send the added codec to the answerer. Bu
