From: "Attila Sipos" <[EMAIL PROTECTED]>
There is even an IETF draft which discusses
the problems with UAs inappropriately sending
6xx responses.
Title: 6xx-Class Responses Considered Harmful in the
Session Initiation Protocol (SIP)
Author(s)
o Iñaki Baz Castillo [06/03/08 14:46]:
>> It may well be that the user at that one extension noticed the caller id
>> was that nasty bill collector that he doesn't want to talk to. So he
>> pushed the "reject this call totally" button, and that resulted in the
>> 6xx response. Not sending the cal
El Tuesday 03 June 2008 20:29:51 Sanjay Sinha (sanjsinh) escribió:
> So it does not make sense for the proxy to try to create another leg for
> that call, maybe to voicemail since that will fail as well because no
> account for that user exists on the VM system
Yes, it makes sense, but RFC3261 def
Victor Pascual Ávila wrote:
> On 6/3/08, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
>> The BLISS WG is grappling with this issue. You should visit over there.
>
> Would you point us to that discussion? I couldn't find it.
Look for the thread with subject: [BLISS] Rejection conditions for ACH
And
t; Also, how does that UA know the BOSS is totally gone?
> The BOSS could've gone home and registered a different UA from home.
>
> Regards,
>
> Attila
>
>
> -Original Message-----
> From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED]
> Sent: 03 June 2008 12:15
On 6/3/08, Paul Kyzivat <[EMAIL PROTECTED]> wrote:
> The BLISS WG is grappling with this issue. You should visit over there.
Would you point us to that discussion? I couldn't find it.
Cheers,
--
Victor Pascual Ávila
___
Sip-implementors mailing list
S
lf Of Bogdan-Andrei Iancu
>Sent: Tuesday, June 03, 2008 1:12 PM
>To: Attila Sipos
>Cc: sip-implementors@lists.cs.columbia.edu
>Subject: Re: [Sip-implementors] Why does 6XX break a serial forking?
>
>Well, here is the first problem - how can a client(like
>device) know th
gone home and registered a different UA
>> from home.
>>
>> Regards,
>>
>> Attila
>>
>>
>> -----Original Message-
>> From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED]
>> Sent: 03 June 2008 12:15
>> To: Attila Sipos
>> Cc: I
is better than having to replace all UAs.
> Regards,
>
> Attila
>
>
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos
> Sent: 03 June 2008 13:06
> To: Bogdan-Andrei Iancu
> Cc: sip-implementors@lists.cs.columbia.edu
&g
could've gone home and registered a different UA
> from home.
>
> Regards,
>
> Attila
>
>
> -Original Message-
> From: Bogdan-Andrei Iancu [mailto:[EMAIL PROTECTED]
> Sent: 03 June 2008 12:15
> To: Attila Sipos
> Cc: Iñaki Baz Castillo; sip-implementors@lists
ge-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos
Sent: 03 June 2008 13:06
To: Bogdan-Andrei Iancu
Cc: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why does 6XX break a serial forking?
What do you mean by "may reply with 6xx if BOSS
El Tuesday 03 June 2008 14:31:23 Paul Kyzivat escribió:
> I can't decide where to reply in this thread, so I'll just do it here.
> (I've read a bunch of replies.)
>
> There definitely are problems with 6xx - partly defintional and partly
> inappropriate use. But IMO there is need of a way to expres
I can't decide where to reply in this thread, so I'll just do it here.
(I've read a bunch of replies.)
There definitely are problems with 6xx - partly defintional and partly
inappropriate use. But IMO there is need of a way to express stronger
rejections than is possible with the existing 4xx r
mailto:[EMAIL PROTECTED]
Sent: 03 June 2008 12:15
To: Attila Sipos
Cc: Iñaki Baz Castillo; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why does 6XX break a serial forking?
Hi,
What I think Iñaki tries to underline is the fact that the UAS has the
knowledge about the des
Hi,
What I think Iñaki tries to underline is the fact that the UAS has the
knowledge about the destination user from the current branch. But a mid
proxy may decide to serial fork the call to a new destination that
points to a totally different user - and is this case the 6xx is not
relevant as
igure or fix the UAs.
(Not always possible I know)
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
Castillo
Sent: 03 June 2008 10:05
To: sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why does 6XX break a
El Tuesday 03 June 2008 10:22:19 Attila Sipos escribió:
> >>6XX behaviour is really painful.
> >>I realy wonder why they break serail forking:
>
> To me, 6xx means the user you're trying to reach doesn't exist anywhere
> or won't accept your call anywhere or can't accept your call anywhere.
> So, i
El Tuesday 03 June 2008 10:47:00 Attila Sipos escribió:
> There is even an IETF draft which discusses
> the problems with UAs inappropriately sending
> 6xx responses.
>
>
> Title : 6xx-Class Responses Considered Harmful in the Session
> Initiation
> Protocol (SIP) Author(s) :
d so one needs to be created.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Attila Sipos
Sent: 03 June 2008 09:22
To: Iñaki Baz Castillo; sip-implementors@lists.cs.columbia.edu
Subject: Re: [Sip-implementors] Why does 6XX break a serial forking?
>&
y be a 4xx (but that's another issue).
Regards,
Attila
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Iñaki Baz
Castillo
Sent: 03 June 2008 08:41
To: sip-implementors@lists.cs.columbia.edu
Subject: [Sip-implementors] Why does 6XX break a serial f
Hi, IMHO 6XX behaviour is really painful. I realy wonder why they break serail
forking:
* Cool behaviour (with no 6XX):
- A calls B via their proxy.
- Proxy does parallel forking and 4 instances of B ring.
- All of them reply a 4XX (Busy, Not available...).
- Then the proxy generates a new branch
21 matches
Mail list logo
