Hello Uttam ,
This scenario does not really work very well ..
If you do lot of complicated signaling with UPDATE , the best user experience 
you can get is a voice path with lots of clipping. Check out section 3.1 in RFC 
3960 for details.
There is an interesting topic going on this and other early media related 
issues on the SIPPING WG with a subject "Some thoughts on fixing early media" 
.. You may want to check that out as well...
HTH ,
Regards ,
Sayan


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Uttam Kumar 
Sarkar
Sent: Thursday, July 20, 2006 6:10 PM
To: [EMAIL PROTECTED]; Markus Hofmann
Cc: [EMAIL PROTECTED]; Manpreet Singh; [email protected]
Subject: Re: [Sip-implementors] [SIPForum-discussion] Offer in a 200OKforInvite 
transaction.


How about the forking case when B2BUA is forking the INVITE to multiple 
contacts of B. Each of then ( PhB1, PhB2 and PhB3) sent 183 with SDP. Of course 
those 3 SDP ( received in the order SDP_B1, SDP_B2 and SDP_B3)would be from 3 
different dialog. Now PhB3 sends 200 OK with SDP.
How the B2BUA is going act on receiving different answers?

                 |-----------
PhA------------->|   B2BUA  |---------->PhB1
                 |          |---------->PhB2
                 |          |---------->PhB3
                 ------------


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Somesh S Shanbhag
Sent: Thursday, July 20, 2006 8:17 AM
To: Markus Hofmann
Cc: [email protected]; Manpreet Singh; [EMAIL PROTECTED]
Subject: Re: [Sip-implementors] [SIPForum-discussion] Offer in a 200OK 
forInvite transaction.


Hi Markus,

I think the expected behavior from UAS is it MUST not include two different 
SDP's in 18x(non-reliable) and 200 responses.

But if it does that also section 13.2.1 of RFC 3261 mentions UAC to ignore the 
answer in 200 when it has received the answer in 18x (non-reliable).

Thanks
Somesh S. Shanbhag

Markus Hofmann <[EMAIL PROTECTED]> wrote: Hi Somesh,

I have question related to this.

What is the right behaviour (sending out INVITE with SDP offer) if SDP in 18x 
(non-reliable) and 2xx are different? Sending ACK / BYE? Ignoring 2xx SDP?

Regards
Markus

Somesh S Shanbhag wrote:
> Hi Manpreet,
>  
>   RFC 3261 section 13.2.1 has the following clause ...
>  
>   "
>  
> If the initial offer is in an INVITE, the answer MUST be in a reliable
> non-failure message from UAS back to UAC which is correlated to that
> INVITE.  For this specification, that is only the final 2xx response
> to that INVITE.  That same exact answer MAY also be placed in any
> provisional responses sent prior to the answer.  The UAC MUST treat
> the first session description it receives as the answer, and MUST
> ignore any session descriptions in subsequent responses to the initial
> INVITE "
>
> So, UAC MUST treat 183 session progress as the answer and shall ignore
> in subsequent responses to INVITE.
>
> Hope this helps
> Thanks
> Somesh S. Shanbhag
>
>  
>
> Manpreet Singh  wrote:              For the INVITE   transaction where the 
> offer was sent in an INVITE and the answer coming back in   183, would it be 
> valid to send a new offer in the 200OK? So the question is   whether the 
> 200OK can be used to send a "new" Offer ( different from the answer   in 183 
> ) for the INVITE transaction once 183 has completed the offer/answer   part 
> of that transaction. Only UPDATE can be used for early dialog changes as   
> per my understanding and a 200OK still constitutes early dialog so it wont   
> be valid to send a new offer in 200OK? Although 200OK can carry the same SDP 
> as   183 which would mean nothing or would not be considered as early dialog 
> change   in capability.
>   
>   Please correct me if   I am wrong.
>   
>   Thanks
>   
>   Manpreet  
> _______________________________________________
> discussion mailing list
> [EMAIL PROTECTED]
> http://sipforum.org/mailman/listinfo/discussion
>
>
>
> -----------------------------------------
> SIMPLICITY IS THE BEAUTY.
> BE NATURAL LIVE NATURAL.
> -----------------------------------------
> Somesh S. Shanbhag
> Focus Area - VoIP Team (FA-VoIP)
> Mascon Global Communication Technologies Enterprise of Mascon Global
> Limited #59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070
> Karnataka INDIA
> Website: http://www.mgl.com/
> -----------------------------------------
>   
> ---------------------------------
> Do you Yahoo!?
>  Get on board. You're invited to try the new Yahoo! Mail Beta.
> _______________________________________________
> Sip-implementors mailing list [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors



-----------------------------------------
SIMPLICITY IS THE BEAUTY.
BE NATURAL LIVE NATURAL.
-----------------------------------------
Somesh S. Shanbhag
Focus Area - VoIP Team (FA-VoIP)
Mascon Global Communication Technologies Enterprise of Mascon Global Limited 
#59/2, 100Ft Ring Road Banashankari II stage Bangalore-560070 Karnataka INDIA
Website: http://www.mgl.com/
-----------------------------------------
        
---------------------------------
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates 
starting at 1ยข/min.
_______________________________________________
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


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message and 
any attachments.

WARNING: Computer viruses can be transmitted via email. The recipient should 
check this email and any attachments for the presence of viruses. The company 
accepts no liability for any damage caused by any virus transmitted by this 
email.

www.wipro.com

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

Reply via email to