Subject: [Sipping] Question about Call Forwarding Busy(CFB)

From: [email-masked]
Date: Thu, 9 Apr 2009 19:25:22 +0800

Use case: A call B(Busy), AS forward the call to C.

By TISPAN standard(current 3GPP 24.404), AS would send INVITE to C. And 
this INVITE contain A's initial Offer.

But if considering precondition, B would has Offer/Answer with A. 
Now, should the INVITE(by AS) contain A's initial Offer or not?  Or is 
there standard define it?

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Thu, 9 Apr 2009 14:30:16 +0200

Why would it change the SDP? The diversion does not alter A's desire for
establishing a communication with certain media.

/Hans Erik van Elburg

On Thu, Apr 9, 2009 at 1:25 PM, <[email-masked]> wrote:

> _______________________________________________
> Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Apr 2009 09:32:18 -0400

> there standard define it?

Are you assuming that the AS is acting as a proxy? Or as a B2BUA?

Assuming its a proxy:

If B is busy, then I would expect that there was no answer from B. 
Rather just an immediate 486 response. This would never reach A and so 
there is no issue.

If for some reason B did send an answer in a provisional response before 
signaling busy, then that would establish an early dialog with to-tag B.
Then later there will be a 486 response, intercepted by the AS, and not 
forwarded to A.

And then a copy of the original INVITE will be sent by the AS to C. When 
C responds with an answer, it will be with to-tag C. Hence A will see 
this as a new early (or final) dialog.

A must negotiate the preconditions independently in the two dialogs.

	Thanks,
	Paul

---

From: [email-masked]
Date: Fri, 10 Apr 2009 08:39:10 +0800

Hi,

Thanks for your answer.

Using forking, Offer/Answer would be in two different dialogs. So, it has 
no such problem. But the TISPAN's standard using B2BUA mode for Call 
Forwarding.

As:

if A-C's negotiate still in the original dialog(having done A-B's 
negotiate), then it is B2BUA mode:

1. if the INVITE to C has Offer, there would be using C's Answer as Offer 
send to A, usually using UPDATE.

                 |---->Offer(1)
                 |<----Answer(2)
 Offer(3) <----|
Answer(4) ---->|

Then we would have to judge whether the Answer(4) should be intercept or 
transfer. If it should be transfered, then its the begin of next loop as 
the current one.

2. if the INVITE to C has no Offer, then C's Offer would has different 
stream as A's original desire. It is also a well known problem.

So. I want to know how you considering the problems. Thanks.

Gao

Paul Kyzivat <[email-masked]> 
2009-04-09 21:32

收件人
[email-masked]
抄送
[email-masked]
主题
Re: [Sipping] Question about Call Forwarding Busy(CFB)

Assuming its a proxy:

                 Thanks,
                 Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Apr 2009 00:59:59 -0400

[email-masked] wrote:
> 
> Hi,
> 
> Thanks for your answer.
> 
> Using forking, Offer/Answer would be in two different dialogs. So, it 
> has no such problem. But the TISPAN's standard using B2BUA mode for Call 
> Forwarding.

Oh. Then the game may be different.

> 1. if the INVITE to C has Offer, there would be using C's Answer as 
> Offer send to A, usually using UPDATE.
> 
> 
>                    |---->Offer(1)
>                  |<----Answer(2)
>  Offer(3) <----|
> Answer(4) ---->|
> 

I think it is very difficult to make this work. There are often
problems, even without preconditions. Preconditions don't make it any
simpler.

IMO the answer is: if it hurts, don't do it.
Even if the AS wants to act as a B2BUA, the AS can still establish
multiple dialogs back to A, so the issue of sorting this out is left to
A. Unless you are trying to deal with UAs that are unable to do that.

Unless the B2BUA also terminates the media it may be impossible to
resolve all the problems.

	Paul

> Gao
> 
> 
> 
> 
> *Paul Kyzivat <[email-masked]>*
> 
> 2009-04-09 21:32
> 
> 	
> 收件人
> 	[email-masked]
> 抄送
> 	[email-masked]
> 主题
> ------------------------------------------------------------------------
>

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 10 Apr 2009 11:52:56 +0200

Exactly, why make things complicated when you can leave it up to the UA as
it has to deal with this anyway. A B2BUA can very well behave as if it where
almost a proxy.

/Hans Erik van Elburg

2009/4/10 Paul Kyzivat <[email-masked]>

> A.

---

From: [email-masked]
Date: Fri, 10 Apr 2009 20:16:34 +0800

Yes.

But in fact, the way you think too complex is not I suggested. It is 
suggested by TISPAN(current in 3GPP) in its standard about call 
forwarding.

Thanks 

Gao

Hans Erik van Elburg <[email-masked]> 
2009-04-10 17:52

收件人
Paul Kyzivat <[email-masked]>
抄送
[email-masked], [email-masked]
主题
Re: [Sipping] 答复: Re: Question about Call Forwarding Busy(CFB)

Exactly, why make things complicated when you can leave it up to the UA as 
it has to deal with this anyway. A B2BUA can very well behave as if it 
where almost a proxy.

/Hans Erik van Elburg

---

From: [email-masked]
Date: Fri, 10 Apr 2009 20:47:28 +0800

To Paul

Yes.

But there has been the emergence of the practical problem while 
interworking of equipment from different corporation.

To solve the call forwarding problem, we has two base choice: Forking and 
no Forking.

Currently, TISPAN using no Forking way(in fact, B2BUA way).

Then, if 3GPP want to using Forking way to replace the current no Forking 
way, it should rewrite "3GPP TS 24.404".

Or if 3GPP want to along the no Forking way, then it should resolve the 
interworking problem arosed by "INVITE with/without SDP problem".

Thanks

Gao

To Christer 

As you are the rustler of 3GPP, can you talk about this topic too.

Thanks 

Gao

> > ZTE Information Security Notice: The information contained in this
> mail is solely property of the sender's organization. This mail 
> communication is confidential. Recipients named above are obligated 
> to maintain secrecy and are not permitted to disclose the contents 
> of this communication to others.
> > This email and any files transmitted with it are confidential and 
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please 
> notify the originator of the message. Any views expressed in this 
> message are those of the individual sender.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 10 Apr 2009 09:02:04 -0400

OK. Then I guess TISPAN will have to figure out how to deal with the
difficulties that their choices bring.

	Thanks,
	Palu

[email-masked] wrote:
> To solve the call forwarding problem, we has two base choice: Forking 
> and no Forking.
> 
> Then, if 3GPP want to using Forking way to replace the current no 
> Forking way, it should rewrite "3GPP TS 24.404".
>

---

From: [email-masked]
Date: Fri, 10 Apr 2009 21:17:34 +0800

Yes, I think so too.

We has decided to propose this problem to 3GPP and TISPAN in next meeting. 
And we want to know is there any other corporations or individuals want to 
consider this probelm. We can talk it in the coming meeting.

Thanks 
Gao

2009-04-10 21:02

收件人
[email-masked]
抄送
[email-masked], [email-masked]
主题
Re: [Sipping] 答复: Re:  答复: Re:  Question about Call Forwarding 
Busy(CFB)

                 Thanks,
                 Palu

[email-masked] wrote:
>  > > has no such problem. But the TISPAN's standard using B2BUA mode for 

> Call
>  > >  > By TISPAN standard(current 3GPP 24.404), AS would send INVITE to 

> C. And
>  > > And then a copy of the original INVITE will be sent by the AS to C. 

> When
>  > > This message has been scanned for viruses and Spam by ZTE Anti-Spam 

> system.
> ZTE Information Security Notice: The information contained in this mail 
is solely property of the sender's organization. This mail communication 
is confidential. Recipients named above are obligated to maintain secrecy 
and are not permitted to disclose the contents of this communication to 
others.
> This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error please notify the 
originator of the message. Any views expressed in this message are those 
of the individual sender.

---

From: Hans Erik van Elburg <[email-masked]>
Date: Fri, 10 Apr 2009 15:41:13 +0200

Discussing 3GPP/TISPAN specs seems little off topic here. I'd just like to
say that the 3GPP/TISPAN specification does not imply this. It seems merely
a problem with your interpretation of that specification.

BR,
/Hans Erik van Elburg

2009/4/10 <[email-masked]>

> [email-masked], [email-masked]  主题
> Re: [Sipping] 答复: Re:  答复: Re:  Question about Call Forwarding Busy(CFB)
>
>
>
>
> is solely property of the sender's organization. This mail communication is
> confidential. Recipients named above are obligated to maintain secrecy and
> are not permitted to disclose the contents of this communication to others.
> originator of the message. Any views expressed in this message are those of
> the individual sender.

---

From: [email-masked]
Date: Fri, 10 Apr 2009 21:47:48 +0800

Hi,

inlines

Thanks 

Gao

2009-04-10 21:41

收件人
[email-masked]
抄送
Paul Kyzivat <[email-masked]>, [email-masked], 
[email-masked]
主题
Re: [Sipping] 答复: Re: 答复: Re: 答复: Re: Question about Call Forwarding 
Busy(CFB)

Discussing 3GPP/TISPAN specs seems little off topic here.

[Gao] Yes. So, I do not want to get the final answer here.
I just want to know is there anyone else has such problem.

I'd just like to say that the 3GPP/TISPAN specification does not imply 
this. It seems merely a problem with your interpretation of that 
specification.

[Gao] 3GPP/TISPAN specification did not talk this intensive. So, arosing 
the interworking problem.
And what do you think about this problem of "AS's INVITE to with or 
without SDP, while A-B has Offer/Answer pairs"?

BR,
/Hans Erik van Elburg

Yes, I think so too. 

Thanks 
Gao 

收件人
[email-masked] 
抄送

                Thanks,
                Palu

system.

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is 
solely property of the sender's organization. This mail communication is 
confidential. Recipients named above are obligated to maintain secrecy and 
are not permitted to disclose the contents of this communication to 
others.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the originator of 
the message. Any views expressed in this message are those of the 
individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam 
system.

---

From: [email-masked]
Date: Fri, 10 Apr 2009 22:04:01 +0800

I am surprised why you think it is problem of interprettion.

This standard doc do use B2BUA way, the there are only two choice about 
INVITE to C:

1. With SDP.

2. Without SDP.

Using no-precondition, the standard doc chooses 1.

Then what about precondition? This standard doc did not talk this 
intensively.

And if it choose 1, it would have the problem memtioned.

Gao.

收件人
[email-masked]
抄送

Discussing 3GPP/TISPAN specs seems little off topic here. I'd just like to 
say that the 3GPP/TISPAN specification does not imply this. It seems 
merely a problem with your interpretation of that specification.

BR,
/Hans Erik van Elburg

Yes, I think so too. 

Thanks 
Gao 

收件人
[email-masked] 
抄送

                Thanks,
                Palu

system.