Re: [Sip-implementors] [Sip] Re: sip transcation query

Rayees Khan Thu, 12 Jan 2006 07:24:38 -0800

I think it is because of the state machine defined in Figure 7 of RFC 3261 for a UAS.
As far as definition of final response is considered RFC 3261 is quite clear in terms of definition of that.

Final Response: A response that terminates a SIP transaction, as
         opposed to a provisional response that does not.  All 2xx, 3xx,
         4xx, 5xx and 6xx responses are final.

regards
Rayees

[EMAIL PROTECTED] wrote: -----

To: VikramB <[EMAIL PROTECTED]>, vimal srivastava <[EMAIL PROTECTED]>
From: Manpreet Singh <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
Date: 01/12/2006 01:25PM
cc: [email protected]
Subject: Re: [Sip-implementors] [Sip] Re: sip transcation query

Vikram

I think you meant any final response should complete the transaction right?
Non-200 reponses are not final responses so that's why any non-200 responses
donot complete the transaction and hence all messages are still part of the
same transaction till the finall 2xx response is received.

M

-----Original Message-----
From: VikramB [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 12, 2006 7:47 AM
To: vimal srivastava; [email protected]
Cc: [email protected]
Subject: [Sip] Re: [Sip-implementors] sip transcation query

Thanks for the response ,
But i am bit confused now !
AFIK any final resopnse should terminate the session, then how came after
non-2xx response the ACK still can be part of the same transcation !!

vikram

----- Original Message -----
From: "vimal srivastava" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>;
Cc:
Sent: Tuesday, January 10, 2006 2:25 PM
Subject: RE: [Sip-implementors] sip transcation query

> Hi
> Actually if we look at the intent of ACK in case of 2xx response things
> become similar.
> the ACK for 2xx resonse may carry SDP and it will un-necessarily congest
> the network if it is sent thru all the proxies which are handling the
> messaging statefully. Ack is usually exchanged directly
> purpose of ACK is also to tell the end UAS that the originator has
> received 200 message (which has SDP) so that conversation can begin. so
> this signfies the need of ACK.
>
> in case of non-2xx final response, intent of ACK just to ackknowledge the
> previous node that i have received the non-2xx response. and if ACK is not

> received retransmit the non-2xx final response. if ACK is not sent then
> there is no way to tell the pevious node that final response is received.
>
> This is not needed in case of 2xx response becos, if 2xx is lost in
> between, UAC will not send ACK to the UAS and UAS will re-transmit 2xx
> response again.
> ACK for 2xx is exchanged directly (normally) between UAC and UAS so it
> does not congest the network.
> now if for non-2xx we leave the responsiblity of delivery to UAC (the way
> it makes sure for 2xx), then even if non-2xx is lost at some intermediate
> node, UAS will send non-2xx again and will traverse thru all the nodes
> which is not neded. so by using hop-by-hop reliablity mechanism, some
> network traffic is saved.
>
> UAS must know if 2xx is received at UAC or not because its
> acknolwedegement of SDP exchanged , else processing at UAS stops
> (convesation would not beging)
> for non-2xx response UAS does not care. it does not stop any processing
> for UAS
>
> so in essence:
> for non-2xx final response (for invite) reliability is ensured hop-by-hope

> and
> for 2xx final response (for invite) reliablity is ensured end to end.
>
>
>
> cheers
> v.
>
>
>
> From: "VikramB" <[EMAIL PROTECTED]>
> To:
> CC: [email protected]
> Subject: [Sip-implementors] sip transcation query
> Date: Tue, 10 Jan 2006 09:20:06 +0530
>
> Hello All,
> In rfc 3261 section 6 Definition
>
> SIP Transaction :
> ....
> .....
> If the request is INVITE and the final
> response is a non-2xx, the transaction also
> includes an ACK to the response. The ACK for a 2xx response to
> an INVITE request is a separate transaction.
>
> My query is why ACK is considered as a part of same transaction when in
> case of non-2xx response.?
>
>
>
> regards
>
> VIkram
> _______________________________________________
> Sip-implementors mailing list
> [email protected]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
>
>

_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip

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

*****FSS-Private *****" DISCLAIMER: This message is proprietary to Flextronics Software Systems Limited (FSS) 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. FSS 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

Re: [Sip-implementors] [Sip] Re: sip transcation query

Reply via email to