reality is that many endpoints are hardcoded to expect SDP in
> 2xx
> even if offer/answer is fully done. And, they end up killing the call if no
> SDP
> is present in 2xx.
>
> Neb
>
> On 1/20/2009 1:30 AM, Subbu Rajendran wrote:
> > Hi All,
> > Following is ex
Hi All,
Following is example call flow from RFC 3311 (SIP UPDATE Method). Is SDP a
must in the 200 OK for INVITE in this case? If it is required, then 200 OK
should contain 'answer 3'. Is this a legal behavior as answer in 200 OK for
INVITE ('answer 3') is not based on the offer in the INVITE ('off
atement is proved to be right?
Thanks
Subbu
On Thu, Oct 30, 2008 at 8:30 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>
>
> Subbu Rajendran wrote:
>
>> Hi,
>> Thanks for your responses.
>>
>> In my opinion, there are three options to handle this Re-INVITE
&g
e ignored and be processed as
call being put on hold?
Thanks,
Subbu
On Fri, Oct 24, 2008 at 8:26 AM, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
> You are asking two different questions. More inline.
>
> Subbu Rajendran wrote:
>
>> Hi,
>> SIP RFC 2543 uses c=0.0.0.0 met
Hi,
SIP RFC 2543 uses c=0.0.0.0 method to put a call on hold. RFC 3264 has
introduced a=sendonly/recvonly/inactive/sendrecv attributes that can be used
put media to one way, hold and 2-way. However what should be the precedence
to be followed? Consider the case below
A Re-INVITE with SDP
v=0
o=use
.
On 11/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>From: "Subbu Rajendran" <[EMAIL PROTECTED]>
>
>We have a media gate way which establishes a SIP call between 2 SIP end
>points.
>The gateway supports only the G711 codec and the SIP
Hi,
We have a media gate way which establishes a SIP call between 2 SIP end
points.
The gateway supports only the G711 codec and the SIP end points support G711
and G723 codecs.
The negotiation happens for codec G711.
Now when the actual traffic flows happens from the end points the codec used
i
