Hi Umesh,

Since the provisional responses indicated here are reliable, the endpoints 
will be completing the PRACK-200 OK txns before sending failure response. 
one solution to this problem is when B2B  is trying with CALLEE2, it can 
send INVITE without Offer, get CALLEE2's Offer in 180 response, forward it 
to CALLER as UDATE with Offer (after interworking SDP) 
Once B2B receives the 200 OK of UPDATE with Answer , forward it to CALLEE2 
as PRACK with Answer.

So sending INVITE to CALLEE2 with or without SDP should be based on 
whether Answer is already forwarded to CALLER or not.

rgds,
Prince




Umesh <[EMAIL PROTECTED]> 
Sent by: [EMAIL PROTECTED]
11/08/2006 11:23 AM


To
[email protected]
cc

Subject
[Sip-implementors]  Clarification on  offer/answer







Hello All, 
        We have a B2BUA server which needs to support a particular call
flow.
The initial set up call flow is as shown

 
CALLER                  B2BUA                    CALLEE1         CALLEE2
|--------INVITE(SDP1)-->|                       |               |

|                       |-------INVITE(SDP1)--->|               |
|                       |<--------180(SDP2)-----|               |
|<-------180(SDP2) -----|                       |               |
|                       |<---------4xx ---------|               |
|                       |----------ACK----------|               |
|                       |-------INVITE(SDP1)------------------->|
|                       |<------180(SDP3)-----------------------|
|                       |                                       |


The flow here is of sequential routing wherein if one user is not 
responding
then the next number configured has to be tried until one person answers.
But as you can see the issue with the flow is that the 180 with SDP3 
cannot
be forwarded to the caller directly.
As per rules of RFC 3261,3262 as I understand when a reliable provisional
response contains a session description, and is the first to do so, then
that session description is the answer to the offer in the INVITE request.
SDP should not be included in the subsequent 1xx-rel once offer/answer has
been completed. 

Due to this we cannot refresh the SDP to the caller. Even use of UPDATE
would result in a race condition.

Please let me know if there is a solution to update the SDP( SDP3) on the
caller side. Is there any other way of handling this situation?

Thanks and Regards,
Umesh


****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender 
by
phone or email immediately and delete it!


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



***********************  FSS- Confidential   ***********************
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for 
the use of 
the individual to whom it is addressed. It may contain privileged or 
confidential information and should not be 
circulated or used for any purpose other than for what it is intended. If you 
have received this message in error, 
please notify the originator immediately. If you are not the intended 
recipient, you are notified that you are strictly
prohibited from using, copying, altering, or disclosing the contents of this 
message. Aricent accepts no responsibility for 
loss or damage arising from the use of the information transmitted by this 
email including damage from virus."
_______________________________________________
Sip-implementors mailing list
[email protected]
https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors

Reply via email to