The B2BUA being two UA, one acting as UAS and another as UAC.  So, UAC and
UAS sharing the same Call-ID is not a good idea.  For Call-ID the rules in
RFC 3261 holds good.  Since all UAs must generate unique Call-ID, dialogID
cant be shared.

8.1.1.4 Call-ID

   The Call-ID header field acts as a unique identifier to group
   together a series of messages.  It MUST be the same for all requests
   and responses sent by either UA in a dialog.  It SHOULD be the same
   in each registration from a UA.

   In a new request created by a UAC outside of any dialog, the Call-ID
   header field MUST be selected by the UAC as a globally unique
   identifier over space and time unless overridden by method-specific
   behavior.  All SIP UAs must have a means to guarantee that the Call-
   ID header fields they produce will not be inadvertently generated by
   any other UA.

For 3rd party call control, the Controller creates two calls and performs
like a B2BUA.  See RFC 3725.

See below for more answers.

Thanks,
Neel


> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:sip-implementors-
> [EMAIL PROTECTED] On Behalf Of varun
> Sent: Thursday, April 26, 2007 11:36 PM
> To: varun; Annadanesh Sankadal; [email protected]
> Subject: Re: [Sip-implementors] B2BUA Queries
> 
> Can somebody please answer this??
> 
> Thanks
> varun
> --- varun <[EMAIL PROTECTED]> wrote:
> 
> > So that means that a B2BUA modifies the dialog ID.
> > user A-> B2BUA...one dialog
> > B2BUA->B ..another dialog

The B2BUA should map the requests from User A to B2BUA to B2BUA to User B.
The responses from user B to B2BUA can be passed on to the other instance of
B2BUA.  There are multiple scenarios to consider.

A request could be originated from A could be just responded by B2BUA and
not forwarded to user B.  This breaks end to end message flows.

> >
> > So when response from User B is send to A, A gets
> > response on the same dialog ID or on a different
> > Dialog ID.

The dialogID should be mapped between two instances, so that subsequent
request are sent end to end.


> >
> > Also, can somebody explain 3rd party call control by
> > B2BUA?
> >
If you haven't done already, please refer to RFC 3725.

> > --- Annadanesh  Sankadal <[EMAIL PROTECTED]>
> > wrote:
> >
> > > 100 trying is a response..typed it by mistake..
> > >
> > > -danesh
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]
> > On
> > > Behalf Of Annadanesh
> > > Sankadal
> > > Sent: Thursday, April 26, 2007 9:20 PM
> > > To: 'varun'; [email protected]
> > > Subject: Re: [Sip-implementors] B2BUA Queries
> > >
> > > Hi,
> > >
> > > 1> I am not clear about the differences between a
> > > B2BUA and stateful proxy.Can somebody explain the
> > > difference?
> > >
> > > --- AFAIK, B2BUA  basically is used to hide the
> > > network topology.
> > >     It reformulates the requests it gets. If u
> > have
> > > 2 Endpoints ( say EP1
> > >     and EP2 ) and a B2BUA each of the endpoinds
> > will
> > > actually talk to B2BUA.
> > >
> > >     That means you will have 2 call-legs i.e
> > > EP1-->B2BUA and B2B--->EP2.
> > >
> > >
> > > 2>Can a stateful proxy generate requests on its
> > > own...what kind of requests?
> > >
> > > --- Yes..100 Trying is the classic example for
> > this.
> > > And also Cancel
> > > requests will be generated when it forks the call
> > to
> > > multiple location
> > >
> > > -danesh
> > >
> > > -----Original Message-----
> > > From: [EMAIL PROTECTED]
> > > [mailto:[EMAIL PROTECTED]
> > On
> > > Behalf Of varun
> > > Sent: Thursday, April 26, 2007 6:29 PM
> > > To: [email protected]
> > > Subject: [Sip-implementors] B2BUA Queries
> > >
> > > Hi,
> > > 1> I am not clear about the differences between a
> > > B2BUA and stateful proxy.Can somebody explain the
> > > difference?
> > >
> > > 2>Can a stateful proxy generate requests on its
> > > own...what kind of requests?
> > >
> > > 3> what is meant by third pary call control..any
> > > examples?
> > > How does a B2BUA support that!
> > >
> > > Thanks
> > > Naveen
> > >
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Tired of spam?  Yahoo! Mail has the best spam
> > > protection around
> > > http://mail.yahoo.com
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > [email protected]
> > >
> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> > >
> > >
> > >
> > > _______________________________________________
> > > Sip-implementors mailing list
> > > [email protected]
> > >
> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> > >
> > >
> > >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam?  Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> > _______________________________________________
> > Sip-implementors mailing list
> > [email protected]
> >
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
> >
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors


_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to