Just check the tag in the 180's. The 180s might be of sum other UAS(typical
forking scenario). Also if you have received 2xx then you can very well
ignore 1xx msg.
On Thu, Jul 22, 2010 at 1:07 AM, WORLEY, Dale R (Dale) wrote:
>
> From: sip-implementors-bou
I would first examine the SDP. A valid scenario for this is if the SDP
should change for some reason. We have a scenario similar to this where
a Nextone receives multiple 1XX messages on the B side with different
SDP information. It will then send it out to the A leg and the only
difference
[Sip-implementors] retransmission of 180Ringing with require:
100rel
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Peter
An incoming call is first ringing on a call center queue:
The UAS is se
From: sip-implementors-boun...@lists.cs.columbia.edu
[sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Peter
An incoming call is first ringing on a call center queue:
The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC
res
the UAS cannot send CANCEL request. The UAC can only send CANCEL to
terminate. After receiving 500 final response from UAS, UACsends ACK and
after the timer expiry, Invite transaction will be terminated.
On Wed, Jul 21, 2010 at 3:13 PM, Md Faruk Apel Chowdhury <
mdchowdh...@etisalat.ae> wrote:
>
yes yes in that case it shud send PRACK. I am sorry in the first mail it was
the same rseq. Apologies for ignoring.
On Wed, Jul 21, 2010 at 2:57 PM, Iñaki Baz Castillo wrote:
> 2010/7/21 $...@r\/|>r!`/@ :
>
> > For UAC behavior section 4 says
> > " Handling of subsequent reliable provisional res
2010/7/21 Md Faruk Apel Chowdhury :
>
> Appreciate if anybody could explain the following scenario with RFC
Please, to open a new topic create a new mail from scratch with a new
subject instead of pressing "Reply" on any existing thread. If not,
your mail will hold in the same thread (as it's the
Appreciate if anybody could explain the following scenario with RFC
User A sends INVITE to B, continuous ring is going to B. B does not answer. In
that case who will terminate the call.
In my testing, B is sending 500 and call is getting terminated. Is it Ok as per
RFC. Or Softswitch(UAS) mu
That's what I thought
Best Regards,
Peter
-Oorspronkelijk bericht-
Van: Iñaki Baz Castillo [mailto:i...@aliax.net]
Verzonden: woensdag 21 juli 2010 11:27
Aan: $...@r\/|>r!`/@
CC: Peter Nijhuis; sip-implementors@lists.cs.columbia.edu
Onderwerp: Re: [Sip-implementors] retransmi
=
Van: $...@r\/|>r!`/@ [mailto:sarvpriyagu...@gmail.com]
Verzonden: woensdag 21 juli 2010 10:42
Aan: Peter Nijhuis
CC: sip-implementors@lists.cs.columbia.edu
Onderwerp: Re: [Sip-implementors] retransmission
2010/7/21 $...@r\/|>r!`/@ :
> For UAC behavior section 4 says
> " Handling of subsequent reliable provisional responses for the same initial
> request follows the same rules as above, with the following difference:
> reliable provisional responses are guaranteed to be in order. As a result,
> if t
Hi Peter,
RFC 3262 for UAS section 3 clearly says
"After the first reliable provisional response for a request has been
acknowledged,
the UAS MAY send additional reliable provisional responses. The UAS MUST NOT
send a second reliable provisional response until the first is acknowledged.
After the
Hello All,
I'm facing the following problem:
An incoming call is first ringing on a call center queue:
The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC
responds with a PRACK and the UAS again with an 200 OK.
Then the call is actually ringing on a UA (IP hardphone)
The UAS
Hello All,
I'm facing the following problem:
An incoming call is first ringing on a call center queue:
The UAS is sending a 180 Ringing with SDP and a require: 100rel, the UAC
responds with a PRACK and the UAS again with an 200 OK.
Then the call is actually ringing on a UA (IP hardpho
14 matches
Mail list logo
