handling of 4xx responses by a B2BUA

Ours is a B2BUA. Currently if we are receiving the 4xx
response (for eg. 486 Busy Here) from the terminating called
party,then after ACKing the same we are sending the BYE to
originating calling party and dropping the connection
instead of proxying the 486 response to originating. Is it
correct way of doing it? Are B2BUA supposed to proxy error
responses? Any RFC specifying the behaviour of
B2BUA?regards,rishabh  
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

It really depends on your implementation.  If you are taking
care media 
and SDP processing and Leg 1 of the B2BUA already sent a 200
Ok response 
to the INVITE before sending the second leg INVITE out, then
it makes 
sense to send a BYE.    However, if you do not process SDP
and you let 
the SDP pass through  to the far end UAS, then synchronizing
your leg1 
and leg2 would be more appropriate.  There is no RFC
defining a 
B2BUA.    As long as each of the two legs composing the B2B
UA 
connection complies with RFC 3261, then you can pretty much
do whatever 
you like.

If you need a reference,  an implementation of a B2BUA is
available at 
http://www.opensipstack.
org.

Joegen

Rishabh Garg wrote:
> Ours is a B2BUA. Currently if we are receiving the 4xx
response (for eg. 486 Busy Here) from the terminating called
party,then after ACKing the same we are sending the BYE to
originating calling party and dropping the connection
instead of proxying the 486 response to originating. Is it
correct way of doing it? Are B2BUA supposed to proxy error
responses? Any RFC specifying the behaviour of
B2BUA?regards,rishabh  
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementorscs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
>
>   

_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

People keep asking questions about what a B2BUA is supposed
to do.
The answer is always the same:

There are no requirements on a B2BUA except that it must be
compliant as 
a UA on both sides. There are no specifications about how
one side 
relates to the other side.

It seems clear that people want some guidance here, but the
concept of 
B2BUA is too general for there to be any answers.

In order to have some meaningful specifications it is
necessary to more 
tightly specify the intended behavior - thus defining a
subtype of 
B2BUA. For instance there would be more luck in defining
what an SBC 
should do. And there is some work going on that. Similarly,
it makes 
sense to specify what a conference focus should do, and
there is work on 
that in XCON. If you are working on some sort of B2BUA other
than one of 
those, and you want help in defining its behavior, then you
may need to 
round up a group of people with similar interests and start
some work on it.

	Paul

Rishabh Garg wrote:
> Ours is a B2BUA. Currently if we are receiving the 4xx
response (for eg. 486 Busy Here) from the terminating called
party,then after ACKing the same we are sending the BYE to
originating calling party and dropping the connection
instead of proxying the 486 response to originating. Is it
correct way of doing it? Are B2BUA supposed to proxy error
responses? Any RFC specifying the behaviour of
B2BUA?regards,rishabh  
> _______________________________________________
> Sip-implementors mailing list
> Sip-implementorscs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors
> 
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors

   From: "Rishabh Garg" <rishabh_gargrediffmail.com>
   Ours is a B2BUA. Currently if we are receiving the 4xx
response
   (for eg. 486 Busy Here) from the terminating called
party,then
   after ACKing the same we are sending the BYE to
originating calling
   party and dropping the connection instead of proxying the
486
   response to originating. Is it correct way of doing it?

This seems strange, because the B2BUA can only send a BYE on
the
incoming dialog if it has previously send a 2xx response to
it,
despite that the outgoing dialog has not sent a 2xx
response.  Are you
sure you want to do this?

   Are B2BUA supposed to proxy error responses? Any RFC
specifying the
   behaviour of B2BUA?

See Paul's response. -- Beware that building a B2BUA is
difficult
because of questions like this, and since the processes for
extending
SIP do not guarantee that a B2BUA's behavior will remain
valid, it
requires continuing maintenance.

Dale
_______________________________________________
Sip-implementors mailing list
Sip-implementorscs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinf
o/sip-implementors