[Sip-implementors] 180 Ringing after 183 Session progress

[Miguel Oreilly]

Greetings,
I am wondering if the below scenario is valid or not.

<-- 183 (with SDP) then,
<-- 180 (without SDP)



Thanks in advance,


Miguel

[Iñaki Baz Castillo]

2009/8/6 Miguel Oreilly <miguel.oreilly at gmail.com>:
> Greetings,
> I am wondering if the below scenario is valid or not.
>
> <-- 183 (with SDP) then,
> <-- 180 (without SDP)

Yes it's.
However it depends in UAC behaviour on how to render it to the human
(it could choose to render the early-media comming from the same 183,
or it could choose to render internal ringing due to the 180).


--
I?aki Baz Castillo
<ibc at aliax.net>

[Olle E. Johansson]

6 aug 2009 kl. 12.07 skrev I?aki Baz Castillo:

> 2009/8/6 Miguel Oreilly <miguel.oreilly at gmail.com>:
>> Greetings,
>> I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
>
> Yes it's.
> However it depends in UAC behaviour on how to render it to the human
> (it could choose to render the early-media comming from the same 183,
> or it could choose to render internal ringing due to the 180).

I would suggest stopping the playback of audio when you receive the
180 with SDP and revert to the ringing tone. Users does not like
silence and sending an 180 would suggest that there's no more early
media to me.


/O

[Iñaki Baz Castillo]

2009/8/6 Vivek Batra <Vivek.Batra at matrixtelesol.com>:
> [Vivek] - With some ITSP's, 183 Session Progress is sent (with SDP) to play
> the music (something like, please wait while your call is on wait) when
> actual called party is busy. However, 180 Ringing is sent as soon as call
> has been placed to called party and called party is ringing.
> ITSP does not disconnect the media after sending 180 Ringing instead start
> playing Ring Back Tone (RBT) to caller. Hence, in either manner while caller
> disconnects the media or not on receipt of 180 Ringing (without SDP), RBT
> will be played to caller either locally (if caller honors 180 Ringing) or by
> remote server (if caller does not honors 180 Ringing).
> I believe in having a check in application to check whether any RTP stream
> is still there or not after receiving 180 Ringing (without SDP). If no RTP
> is coming, then only 180 Ringing should be honored to play RBT locally else
> RTP from ITSP should be played.

Other scenario:

Parallel forking to phone1 and phone2 (or gateways):
- phone1 replies 183 with early media.
- phone2 replies 180.
- UAC chooses and renders the early-media.
- phone1 rejects the call.
- UAC doesn't realize of it except if it checks that there is no more
RTP from that early dialog.
- If UAC checks it it could change to render internal ringing.

Note that, AFAIK, the 199 code would be useful in this case (it is
sent by the proxy when a branch has finished and would tell the UAC
that the branch of the 183 has terminated).
Unfortunatelly it's a new responde code (still a draft) which nobody implements.



--
I?aki Baz Castillo
<ibc at aliax.net>

[Abhishek Dhammawat]

Hi

The below is valid scenario.

Also RFC 3261 section 13.2.1 mentions

"The UAC MUST treat the first session description it receives as the answer,
and MUST ignore any session descriptions in subsequent responses to the initial INVITE."

regards
Abhishek Dhammawat
Aricent

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Miguel Oreilly
Sent: Thursday, August 06, 2009 3:12 PM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] 180 Ringing after 183 Session progress

Greetings,
I am wondering if the below scenario is valid or not.

<-- 183 (with SDP) then,
<-- 180 (without SDP)



Thanks in advance,


Miguel
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

[Iñaki Baz Castillo]

2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
> The below is valid scenario.
>
> Also RFC 3261 section 13.2.1 mentions
>
> "The UAC MUST treat the first session description it receives as the answer,
> and MUST ignore any session descriptions in subsequent responses to the initial INVITE."


This is fully incorrect in the case above since what you have pasted
is just referred to ONE (early) dialog.
If there is parallel forking, the UAC could receive various different
SDP from each early dialog. But inside a early-dialog, the SDP cannot
change.

--
I?aki Baz Castillo
<ibc at aliax.net>

[Olle E. Johansson]

6 aug 2009 kl. 12.53 skrev I?aki Baz Castillo:

> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
>> The below is valid scenario.
>>
>> Also RFC 3261 section 13.2.1 mentions
>>
>> "The UAC MUST treat the first session description it receives as
>> the answer,
>> and MUST ignore any session descriptions in subsequent responses to
>> the initial INVITE."
>
>
> This is fully incorrect in the case above since what you have pasted
> is just referred to ONE (early) dialog.
> If there is parallel forking, the UAC could receive various different
> SDP from each early dialog. But inside a early-dialog, the SDP cannot
> change.

Well, another device can send a 200 OK with a different SDP, but the
very same device that sent the 183 can not send a new SDP, unless it's
using UPDATE.

Or?

/O

[Abhishek Dhammawat]

Hi

I would request you not to remove the original question from the mail chain for better understanding of the issue I am putting the question by Miguel orielly again


"I am wondering if the below scenario is valid or not.

<-- 183 (with SDP) then,
<-- 180 (without SDP)


Thanks in advance,


Miguel"

The above question does not specify that 183 and 180 are received from single UAS or different. The answer mentioned in my response was considering the scenario when same UAS has sent 183 with SDP followed by 180 without SDP.

regards
Abhishek Dhammawat


-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of I?aki Baz Castillo
Sent: Thursday, August 06, 2009 4:23 PM
Cc: sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress

2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
> The below is valid scenario.
>
> Also RFC 3261 section 13.2.1 mentions
>
> "The UAC MUST treat the first session description it receives as the answer,
> and MUST ignore any session descriptions in subsequent responses to the initial INVITE."


This is fully incorrect in the case above since what you have pasted
is just referred to ONE (early) dialog.
If there is parallel forking, the UAC could receive various different
SDP from each early dialog. But inside a early-dialog, the SDP cannot
change.

--
I?aki Baz Castillo
<ibc at aliax.net>

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

[Iñaki Baz Castillo]

2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
> Hi
>
> I would request you not to remove the original question from the mail chain for better understanding of the issue I am putting the question by Miguel orielly again
>
>
> "I am wondering if the below scenario is valid or not.
>
> <-- 183 (with SDP) then,
> <-- 180 (without SDP)
>
>
> Thanks in advance,
>
>
> Miguel"
>
> The above question does not specify that 183 and 180 are received from single UAS or different. The answer mentioned in my response was considering the scenario when same UAS has sent 183 with SDP followed by 180 without SDP.

ok, but he doesn't say that there are the same early-dialog ;)

--
I?aki Baz Castillo
<ibc at aliax.net>

[Miguel Oreilly]

for clarification;
183 ( with SDP ) and 180 ( without SDP ) were coming from same UAS.


2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>

> Hi
>
> I would request you not to remove the original question from the mail chain
> for better understanding of the issue I am putting the question by Miguel
> orielly again
>
>
> "I am wondering if the below scenario is valid or not.
>
> <-- 183 (with SDP) then,
> <-- 180 (without SDP)
>
>
> Thanks in advance,
>
>
> Miguel"
>
> The above question does not specify that 183 and 180 are received from
> single UAS or different. The answer mentioned in my response was considering
> the scenario when same UAS has sent 183 with SDP followed by 180 without
> SDP.
>
> regards
> Abhishek Dhammawat
>
>
> -----Original Message-----
> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:
> sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of I?aki Baz
> Castillo
> Sent: Thursday, August 06, 2009 4:23 PM
> Cc: sip-implementors at lists.cs.columbia.edu
> Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress
>
> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
> > The below is valid scenario.
> >
> > Also RFC 3261 section 13.2.1 mentions
> >
> > "The UAC MUST treat the first session description it receives as the
> answer,
> > and MUST ignore any session descriptions in subsequent responses to the
> initial INVITE."
>
>
> This is fully incorrect in the case above since what you have pasted
> is just referred to ONE (early) dialog.
> If there is parallel forking, the UAC could receive various different
> SDP from each early dialog. But inside a early-dialog, the SDP cannot
> change.
>
> --
> I?aki Baz Castillo
> <ibc at aliax.net>
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
> for the use of the individual to whom it is addressed. It may contain
> privileged or confidential information and should not be circulated or used
> for any purpose other than for what it is intended. If you have received
> this message in error,please notify the originator immediately. If you are
> not the intended recipient, you are notified that you are strictly
> prohibited from using, copying, altering, or disclosing the contents of this
> message. Aricent accepts no responsibility for loss or damage arising from
> the use of the information transmitted by this email including damage from
> virus."
>
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

[Miguel Oreilly]

In addition to this;
Do you think there should be a RBT or no?
In the case that I am investigating there is no RBT.



2009/8/6 Miguel Oreilly <miguel.oreilly at gmail.com>

> for clarification;
> 183 ( with SDP ) and 180 ( without SDP ) were coming from same UAS.
>
>
>
> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>
>
>> Hi
>>
>> I would request you not to remove the original question from the mail
>> chain for better understanding of the issue I am putting the question by
>> Miguel orielly again
>>
>>
>> "I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
>>
>>
>> Thanks in advance,
>>
>>
>> Miguel"
>>
>> The above question does not specify that 183 and 180 are received from
>> single UAS or different. The answer mentioned in my response was considering
>> the scenario when same UAS has sent 183 with SDP followed by 180 without
>> SDP.
>>
>> regards
>> Abhishek Dhammawat
>>
>>
>> -----Original Message-----
>> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:
>> sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of I?aki Baz
>> Castillo
>> Sent: Thursday, August 06, 2009 4:23 PM
>> Cc: sip-implementors at lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress
>>
>> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
>> > The below is valid scenario.
>> >
>> > Also RFC 3261 section 13.2.1 mentions
>> >
>> > "The UAC MUST treat the first session description it receives as the
>> answer,
>> > and MUST ignore any session descriptions in subsequent responses to the
>> initial INVITE."
>>
>>
>> This is fully incorrect in the case above since what you have pasted
>> is just referred to ONE (early) dialog.
>> If there is parallel forking, the UAC could receive various different
>> SDP from each early dialog. But inside a early-dialog, the SDP cannot
>> change.
>>
>> --
>> I?aki Baz Castillo
>> <ibc at aliax.net>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended solely
>> for the use of the individual to whom it is addressed. It may contain
>> privileged or confidential information and should not be circulated or used
>> for any purpose other than for what it is intended. If you have received
>> this message in error,please notify the originator immediately. If you are
>> not the intended recipient, you are notified that you are strictly
>> prohibited from using, copying, altering, or disclosing the contents of this
>> message. Aricent accepts no responsibility for loss or damage arising from
>> the use of the information transmitted by this email including damage from
>> virus."
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>

[Abhishek Dhammawat]

Hi

In my opinion RBT(Ring Back Tone) should be played.

regards
Abhishek Dhammawat

________________________________
From: Miguel Oreilly [mailto:miguel.oreilly at gmail.com]
Sent: Thursday, August 06, 2009 5:20 PM
To: Abhishek Dhammawat
Cc: I?aki Baz Castillo; sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress

In addition to this;
Do you think there should be a RBT or no?
In the case that I am investigating there is no RBT.


2009/8/6 Miguel Oreilly <miguel.oreilly at gmail.com<mailto:miguel.oreilly at gmail.com>>
for clarification;
183 ( with SDP ) and 180 ( without SDP ) were coming from same UAS.


2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com<mailto:Abhishek.Dhammawat at aricent.com>>
Hi

I would request you not to remove the original question from the mail chain for better understanding of the issue I am putting the question by Miguel orielly again


"I am wondering if the below scenario is valid or not.

<-- 183 (with SDP) then,
<-- 180 (without SDP)


Thanks in advance,


Miguel"
The above question does not specify that 183 and 180 are received from single UAS or different. The answer mentioned in my response was considering the scenario when same UAS has sent 183 with SDP followed by 180 without SDP.

regards
Abhishek Dhammawat


-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu<mailto:sip-implementors-bounces at lists.cs.columbia.edu> [mailto:sip-implementors-bounces at lists.cs.columbia.edu<mailto:sip-implementors-bounces at lists.cs.columbia.edu>] On Behalf Of I?aki Baz Castillo
Sent: Thursday, August 06, 2009 4:23 PM
Cc: sip-implementors at lists.cs.columbia.edu<mailto:sip-implementors at lists.cs.columbia.edu>
Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress

2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com<mailto:Abhishek.Dhammawat at aricent.com>>:
> The below is valid scenario.
>
> Also RFC 3261 section 13.2.1 mentions
>
> "The UAC MUST treat the first session description it receives as the answer,
> and MUST ignore any session descriptions in subsequent responses to the initial INVITE."


This is fully incorrect in the case above since what you have pasted
is just referred to ONE (early) dialog.
If there is parallel forking, the UAC could receive various different
SDP from each early dialog. But inside a early-dialog, the SDP cannot
change.

--
I?aki Baz Castillo
<ibc at aliax.net<mailto:ibc at aliax.net>>

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu<mailto:Sip-implementors at lists.cs.columbia.edu>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu<mailto:Sip-implementors at lists.cs.columbia.edu>
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors



________________________________
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error,please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."

[Mikael Magnusson]

On Thu, Aug 06, 2009 at 05:27:10PM +0530, Abhishek Dhammawat wrote:
> Hi
>
> In my opinion RBT(Ring Back Tone) should be played.
>
> regards
> Abhishek Dhammawat
>

Since nobody has mentioned RFC 3960 I thought it would be appropriate to
quote a portion of section 3.2[1].

With this in mind, a UAC should develop its local policy regarding
local ringing generation. For example, a POTS ("Plain Old Telephone
Service")-like SIP User Agent (UA) could implement the following
local policy:

1. Unless a 180 (Ringing) response is received, never generate
local ringing.

2. If a 180 (Ringing) has been received but there are no incoming
media packets, generate local ringing.

3. If a 180 (Ringing) has been received and there are incoming
media packets, play them and do not generate local ringing.

Note that a 180 (Ringing) response means that the callee is
being alerted, and a UAS should send such a response if the
callee is being alerted, regardless of the status of the early
media session.

I think 3 above answers the original question about local ringtone
generation.

/Mikael

[1]http://tools.ietf.org/html/rfc3960#section-3.2

> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com<mailto:Abhishek.Dhammawat at aricent.com>>
> Hi
>
> I would request you not to remove the original question from the mail chain for better understanding of the issue I am putting the question by Miguel orielly again
>
>
> "I am wondering if the below scenario is valid or not.
>
> <-- 183 (with SDP) then,
> <-- 180 (without SDP)

[Paul Kyzivat]

I just saw this thread. Thanks Mikael for your response. Its the best
one available for this case, assuming (as the original poster has
confirmed) that this is all one dialog.

If there is early media flowing, you probably don't want to preempt it
with a generated ringback. But if there is no media flowing, then a
generated ringback would probably be a good idea.

But this rendering behavior is largely an implementation issue. If you
do it well then people will like your device. If you do it poorly, then
people won't. And there is plenty of room for innovation, especially
with devices having more capabilities. For instance, you might indicate
the alerting status visually if your device can do that. Or you could
mix a ringback with the incoming audio, though you might have difficulty
finding a way to do that which is acceptable to people.

Thanks,
Paul

Mikael Magnusson wrote:
> On Thu, Aug 06, 2009 at 05:27:10PM +0530, Abhishek Dhammawat wrote:
>> Hi
>>
>> In my opinion RBT(Ring Back Tone) should be played.
>>
>> regards
>> Abhishek Dhammawat
>>
>
> Since nobody has mentioned RFC 3960 I thought it would be appropriate to
> quote a portion of section 3.2[1].
>
> With this in mind, a UAC should develop its local policy regarding
> local ringing generation. For example, a POTS ("Plain Old Telephone
> Service")-like SIP User Agent (UA) could implement the following
> local policy:
>
> 1. Unless a 180 (Ringing) response is received, never generate
> local ringing.
>
> 2. If a 180 (Ringing) has been received but there are no incoming
> media packets, generate local ringing.
>
> 3. If a 180 (Ringing) has been received and there are incoming
> media packets, play them and do not generate local ringing.
>
> Note that a 180 (Ringing) response means that the callee is
> being alerted, and a UAS should send such a response if the
> callee is being alerted, regardless of the status of the early
> media session.
>
> I think 3 above answers the original question about local ringtone
> generation.
>
> /Mikael
>
> [1]http://tools.ietf.org/html/rfc3960#section-3.2
>
>> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com<mailto:Abhishek.Dhammawat at aricent.com>>
>> Hi
>>
>> I would request you not to remove the original question from the mail chain for better understanding of the issue I am putting the question by Miguel orielly again
>>
>>
>> "I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>

[T Satyanarayana-A12694]

The caller SHOULD play ring back tone in this case (since he detects he is getting no RTP packets from remote towards RBT).

Regards
Satya T

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Miguel Oreilly
Sent: Thursday, August 06, 2009 5:20 PM
To: Abhishek Dhammawat
Cc: sip-implementors at lists.cs.columbia.edu
Subject: Re: [Sip-implementors] 180 Ringing after 183 Session progress

In addition to this;
Do you think there should be a RBT or no?
In the case that I am investigating there is no RBT.



2009/8/6 Miguel Oreilly <miguel.oreilly at gmail.com>

> for clarification;
> 183 ( with SDP ) and 180 ( without SDP ) were coming from same UAS.
>
>
>
> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>
>
>> Hi
>>
>> I would request you not to remove the original question from the mail
>> chain for better understanding of the issue I am putting the question
>> by Miguel orielly again
>>
>>
>> "I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
>>
>>
>> Thanks in advance,
>>
>>
>> Miguel"
>>
>> The above question does not specify that 183 and 180 are received
>> from single UAS or different. The answer mentioned in my response was
>> considering the scenario when same UAS has sent 183 with SDP followed
>> by 180 without SDP.
>>
>> regards
>> Abhishek Dhammawat
>>
>>
>> -----Original Message-----
>> From: sip-implementors-bounces at lists.cs.columbia.edu [mailto:
>> sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of I?aki
>> Baz Castillo
>> Sent: Thursday, August 06, 2009 4:23 PM
>> Cc: sip-implementors at lists.cs.columbia.edu
>> Subject: Re: [Sip-implementors] 180 Ringing after 183 Session
>> progress
>>
>> 2009/8/6 Abhishek Dhammawat <Abhishek.Dhammawat at aricent.com>:
>> > The below is valid scenario.
>> >
>> > Also RFC 3261 section 13.2.1 mentions
>> >
>> > "The UAC MUST treat the first session description it receives as
>> > the
>> answer,
>> > and MUST ignore any session descriptions in subsequent responses to
>> > the
>> initial INVITE."
>>
>>
>> This is fully incorrect in the case above since what you have pasted
>> is just referred to ONE (early) dialog.
>> If there is parallel forking, the UAC could receive various different
>> SDP from each early dialog. But inside a early-dialog, the SDP cannot
>> change.
>>
>> --
>> I?aki Baz Castillo
>> <ibc at aliax.net>
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>> "DISCLAIMER: This message is proprietary to Aricent and is intended
>> solely for the use of the individual to whom it is addressed. It may
>> contain privileged or confidential information and should not be
>> circulated or used for any purpose other than for what it is
>> intended. If you have received this message in error,please notify
>> the originator immediately. If you are not the intended recipient,
>> you are notified that you are strictly prohibited from using,
>> copying, altering, or disclosing the contents of this message.
>> Aricent accepts no responsibility for loss or damage arising from the
>> use of the information transmitted by this email including damage from virus."
>>
>> _______________________________________________
>> Sip-implementors mailing list
>> Sip-implementors at lists.cs.columbia.edu
>> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>>
>
>

[Vivek Batra]

>> Greetings,
>> I am wondering if the below scenario is valid or not.
>>
>> <-- 183 (with SDP) then,
>> <-- 180 (without SDP)
>
> Yes it's.
> However it depends in UAC behaviour on how to render it to the human
> (it could choose to render the early-media comming from the same 183,
> or it could choose to render internal ringing due to the 180).

I would suggest stopping the playback of audio when you receive the
180 with SDP and revert to the ringing tone. Users does not like
silence and sending an 180 would suggest that there's no more early
media to me.

[Vivek] - With some ITSP's, 183 Session Progress is sent (with SDP) to play
the music (something like, please wait while your call is on wait) when
actual called party is busy. However, 180 Ringing is sent as soon as call
has been placed to called party and called party is ringing.
ITSP does not disconnect the media after sending 180 Ringing instead start
playing Ring Back Tone (RBT) to caller. Hence, in either manner while caller
disconnects the media or not on receipt of 180 Ringing (without SDP), RBT
will be played to caller either locally (if caller honors 180 Ringing) or by
remote server (if caller does not honors 180 Ringing).
I believe in having a check in application to check whether any RTP stream
is still there or not after receiving 180 Ringing (without SDP). If no RTP
is coming, then only 180 Ringing should be honored to play RBT locally else
RTP from ITSP should be played.



/O
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors



Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com

[Vivek Batra]

Hi

The below is valid scenario.

Also RFC 3261 section 13.2.1 mentions

"The UAC MUST treat the first session description it receives as the answer,
and MUST ignore any session descriptions in subsequent responses to the
initial INVITE."

[Vivek] - But that is not the case since 180 Ringing has no SDP answer in
the said issue.

regards
Abhishek Dhammawat
Aricent

-----Original Message-----
From: sip-implementors-bounces at lists.cs.columbia.edu
[mailto:sip-implementors-bounces at lists.cs.columbia.edu] On Behalf Of Miguel
Oreilly
Sent: Thursday, August 06, 2009 3:12 PM
To: sip-implementors at lists.cs.columbia.edu
Subject: [Sip-implementors] 180 Ringing after 183 Session progress

Greetings,
I am wondering if the below scenario is valid or not.

<-- 183 (with SDP) then,
<-- 180 (without SDP)



Thanks in advance,


Miguel
_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

"DISCLAIMER: This message is proprietary to Aricent and is intended solely
for the use of the individual to whom it is addressed. It may contain
privileged or confidential information and should not be circulated or used
for any purpose other than for what it is intended. If you have received
this message in error,please notify the originator immediately. If you are
not the intended recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this
message. Aricent accepts no responsibility for loss or damage arising from
the use of the information transmitted by this email including damage from
virus."

_______________________________________________
Sip-implementors mailing list
Sip-implementors at lists.cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


Email Scanned for Virus & Dangerous Content by : www.CleanMailGateway.com

[Olle E. Johansson]

6 aug 2009 kl. 12.49 skrev Vivek Batra:

>>> Greetings,
>>> I am wondering if the below scenario is valid or not.
>>>
>>> <-- 183 (with SDP) then,
>>> <-- 180 (without SDP)
>>
>> Yes it's.
>> However it depends in UAC behaviour on how to render it to the human
>> (it could choose to render the early-media comming from the same 183,
>> or it could choose to render internal ringing due to the 180).
>
> I would suggest stopping the playback of audio when you receive the
> 180 with SDP and revert to the ringing tone. Users does not like
> silence and sending an 180 would suggest that there's no more early
> media to me.
>
> [Vivek] - With some ITSP's, 183 Session Progress is sent (with SDP)
> to play
> the music (something like, please wait while your call is on wait)
> when
> actual called party is busy. However, 180 Ringing is sent as soon as
> call
> has been placed to called party and called party is ringing.
> ITSP does not disconnect the media after sending 180 Ringing instead
> start
> playing Ring Back Tone (RBT) to caller. Hence, in either manner
> while caller
> disconnects the media or not on receipt of 180 Ringing (without
> SDP), RBT
> will be played to caller either locally (if caller honors 180
> Ringing) or by
> remote server (if caller does not honors 180 Ringing).
> I believe in having a check in application to check whether any RTP
> stream
> is still there or not after receiving 180 Ringing (without SDP). If
> no RTP
> is coming, then only 180 Ringing should be honored to play RBT
> locally else
> RTP from ITSP should be played.
>
That sounds like a good pragmatic approach.

On a related topic. What should one do in this case?

<--- 183 with sdp from UA 1
(10 secs)
<--- 183 with sdp from UA 2
(5 secs)
<--- 180 ringing from UA 3
<--- 200 OK from UA 3

From testing, different devices do very different things.

/O :-)

[Iñaki Baz Castillo]

2009/8/6 Olle E. Johansson <oej at edvina.net>:
> On a related topic. What should one do in this case?
>
> <--- 183 with sdp from UA 1
> (10 secs)
> <--- 183 with sdp from UA 2
> (5 secs)
> <--- 180 ringing from UA 3
> <--- 200 OK from UA 3
>
> From testing, different devices do very different things.


That is not specified at all. If you inspect in different RFC's
talking about this issue (including RFC 3261) you'll find a lot of
MAY/COULD. XD


--
I?aki Baz Castillo
<ibc at aliax.net>

[Paul Kyzivat]

Olle E. Johansson wrote:
> 6 aug 2009 kl. 12.49 skrev Vivek Batra:
>
>>>> Greetings,
>>>> I am wondering if the below scenario is valid or not.
>>>>
>>>> <-- 183 (with SDP) then,
>>>> <-- 180 (without SDP)
>>> Yes it's.
>>> However it depends in UAC behaviour on how to render it to the human
>>> (it could choose to render the early-media comming from the same 183,
>>> or it could choose to render internal ringing due to the 180).
>> I would suggest stopping the playback of audio when you receive the
>> 180 with SDP and revert to the ringing tone. Users does not like
>> silence and sending an 180 would suggest that there's no more early
>> media to me.
>>
>> [Vivek] - With some ITSP's, 183 Session Progress is sent (with SDP)
>> to play
>> the music (something like, please wait while your call is on wait)
>> when
>> actual called party is busy. However, 180 Ringing is sent as soon as
>> call
>> has been placed to called party and called party is ringing.
>> ITSP does not disconnect the media after sending 180 Ringing instead
>> start
>> playing Ring Back Tone (RBT) to caller. Hence, in either manner
>> while caller
>> disconnects the media or not on receipt of 180 Ringing (without
>> SDP), RBT
>> will be played to caller either locally (if caller honors 180
>> Ringing) or by
>> remote server (if caller does not honors 180 Ringing).
>> I believe in having a check in application to check whether any RTP
>> stream
>> is still there or not after receiving 180 Ringing (without SDP). If
>> no RTP
>> is coming, then only 180 Ringing should be honored to play RBT
>> locally else
>> RTP from ITSP should be played.
>>
> That sounds like a good pragmatic approach.
>
> On a related topic. What should one do in this case?
>
> <--- 183 with sdp from UA 1
> (10 secs)
> <--- 183 with sdp from UA 2
> (5 secs)
> <--- 180 ringing from UA 3
> <--- 200 OK from UA 3

> From testing, different devices do very different things.

There are many different things that might make sense.
The main problem is that you are trying to multiplex three incoming
streams into one, and there is no perfect way to do it.

You could mix all the streams you are receiving. But that will most
likely be terrible. You can stick with one, ignoring the others, until
you stop receiving packets from it, then switch to another.

If your phone is capable, you might render a display showing all the
different calls you have, with buttons to switch the played audio
between them.

Obviously you want to switch to the one you get the 200 from eventually.
But it isn't necessarily obvious which of the streams you are receiving
is from UA3.

Thanks,
Paul

> /O :-)
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementors at lists.cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>