Hi,
inlines
Thanks
Gao
Hans Erik van Elburg <[email protected]>
2009-04-10 21:41
收件人
[email protected]
抄送
Paul Kyzivat <[email protected]>, [email protected],
[email protected]
主题
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
2009/4/10 <[email protected]>
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
Paul Kyzivat <[email protected]>
2009-04-10 21:02
收件人
[email protected]
抄送
[email protected], [email protected]
主题
Re: [Sipping] 答复: Re: 答复: Re: Question about Call Forwarding
Busy(CFB)
OK. Then I guess TISPAN will have to figure out how to deal with the
difficulties that their choices bring.
Thanks,
Palu
[email protected] wrote:
>
> 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
>
>
> Paul Kyzivat <[email protected]> 写于 2009-04-10 12:59:59:
>
> >
> >
> > [email protected] 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.
> >
> > > 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.
> >
> > 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 protected]>*
> > >
> > > 2009-04-09 21:32
> > >
> > >
> > > 收件人
> > > [email protected]
> > > 抄送
> > > [email protected]
> > > 主题
> > > Re: [Sipping] Question about Call Forwarding Busy(CFB)
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > [email protected] wrote:
> > > >
> > > > 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?
> > >
> > > 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
> > >
> > >
> > > --------------------------------------------------------
> > > 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.
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > _______________________________________________
> > > Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> > > This list is for NEW development of the application of SIP
> > > Use [email protected] for questions on current sip
> > > Use [email protected] for new developments of core SIP
>
> --------------------------------------------------------
> 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.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email protected] for questions on current sip
> Use [email protected] for new developments of core SIP
--------------------------------------------------------
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.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
--------------------------------------------------------
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.
_______________________________________________
Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email protected] for questions on current sip
Use [email protected] for new developments of core SIP
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.