The UAC is defective. Here UAS should terminate the session. It may
re-initiate offer/answer again by sending re-INVITE but this will lead
to same situation again.
There is no point for UAS to continuing the call with previous SDP
because there is no surety that UAC will be doing the same as it
What will happen if the UAS decide to continue the call?
Actually, the UAC may have some errors, such as select a wrong codec
outside the codec list of the SDP Offer. Will the continuing call cause
a mismatch of the stream?
Please also give reference about this beahvior? Thanks,
Alex Zhang
Of course, it will surely cause the mismatch in stream, because UAC
will start streaming in Codec3. Any way UAC is wrong, there is no
point in expecting UAS also to be wrong,
because call continuation in such a scenario is wrong from UAS point of view.
On 3/17/08, [EMAIL PROTECTED] [EMAIL
Thanks,
So, the UAS can not take for granted that the previous SDP is to be used
for both ways if it just ignores codec3 without terminating the session.
Right?
Alex Zhang
ESN: 6-554-8782
-Original Message-
From: Vikram Chhibber [mailto:[EMAIL PROTECTED]
Sent: Monday, March 17,
Madhav,
Thanks for your clarification. I also think your analysis is reasonable.
However, I am not sure if there is an explicit description about such
error handling in the exisitng RFCs. Otherwise, there would be an design
option of not terminating the session.
Thanks,
Alex Zhang
ESN:
One key factor on this problem is that: Will the UAC MUST change the
session attributes as its generated Answer right the asnwer is sent out?
I really don't see any subsequent message from UAS to notify the Codec 3
is not supported by UAS.
Alex Zhang
ESN: 6-554-8782
-Original
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of [EMAIL PROTECTED]
Sent: 12 March 2008 18:00
To: [EMAIL PROTECTED]
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Fallback between gateways?
From: Jim Risler [EMAIL
Hi Alex,
Generallym if the audio codec is non-understandable to the UAS, it can
accept the dialog which is trying to get established. But if the audio
codec mismatch happens, based on its implementation dependency, it tries
to terminate the session as it is unable to understand. In this case, in
[EMAIL PROTECTED] wrote:
Thanks,
So, the UAS can not take for granted that the previous SDP is to be used
for both ways if it just ignores codec3 without terminating the session.
Right?
Once you get outside the valid behavior specified by the standards you
can take nothing for granted.
From: Steve Langstaff [EMAIL PROTECTED]
Would sending a 408 Request Timeout response help nudge the client to
use 3263 mechanisms?
I don't think so -- RFC 3263 generates a series of network addresses,
but as soon as the sender can contact one of the addresses, the
remainder of the
From: Steve Langstaff [EMAIL PROTECTED]
Which says, to me, that a 408 response and a transaction layer timeout
must be treated the same.
Maybe I made 2+2=5?
I've always taken that to mean that if the transport layer failed to
transmit the message, it would pass an effective 408
El Lunes, 17 de Marzo de 2008, Steve Langstaff escribió:
I was reading this from RFC 3263:
Failure also occurs if the transaction layer times out without ever
having received any response, provisional or final (i.e., timer B or
timer F in RFC 3261 [1] fires). If a failure occurs,
12 matches
Mail list logo
